Every Tester needs to be an Agile Tester

My wife is one of the smartest people I know.  The only dumb thing she ever did was marry me .  She’s also a superb project manager, orchestrating operations that are often way too complex for me to understand.

A couple of weeks ago she was listening to a podcast about Agile project management.  After the session we talked about Agile and how we are seeing it all over the place now.  We also noted that up to now she hasn’t used Agile on any of her company’s projects.

This made me realize that some organizations today are still missing out on the Agile revolution/party/”clown-filled-parade” taking place around them.  And maybe more importantly, that some managers are misinterpreting Agile altogether and incorrectly thinking that adopting Agile principles is too complex and difficult for them and/or their teams.

Some people are taking Agile to unforeseen (and strange) places

Not everyone missed climbing on the “Agile Bandwagon”.  On the contrary, sometimes I feel like some people are taking Agile a little further than originally intended.

For example, I heard about a restaurant where they define everything from their menus, to the way the tables are arranged, and even how the waiters are dressed, based on an Agile approach.

Based on the feedback they get from their customers, they make incremental changes on a weekly basis. The team even carries out retrospective sessions where everyone (workers and external providers) can raise their concerns and ideas.

They claim that this Agile approach helps them meet the changing needs of their customers at all times.  Still, to me it sounds a little strange, but as long as it works for them who am I to complaint!

Another story I heard was about an Agile coach who was organising (managing?) his house and kids using Scrum, Kan-Ban boards, and weekly retrospectives.

I did not get into the details of the operation, but to me this specific case crosses some parenting red lines that I’d prefer were left untouched formal structures of this type.  Then again, each of us has his or her parenting methods, so who am I to criticise this one in particular.

Applying Agile to every type of testing

Agile testing is not trivial – I even wrote about it here – but it is not rocket science either.

So that we are all on the same page, let’s review the 10 Principles of Agile Testing proposed by L. Crispin and J. Gregory in their book:

- Provide continuous feedback.
- Deliver value to the customer.
- Enable face to face communication.
- Have courage.
- Keep it simple.
- Practice continuous improvement.
- Respond to change.
- Self-organize.
- Focus on people.
- Enjoy (this one is optional…)

When you look at these principles, it is easy to see that regardless of the methodology (or lack of methodology!) followed by your development team you can still choose to manage your testing process and team based on an Agile approach.

To be a little more concrete let’s focus on a handful of these principles.

 1.  Deliver value to the customer

This one is, in my opinion, the most important point: The focus of the Agile tester is on delivering value to his customers – or better said, to the people he is working to serve.

Wait a minute…  SERVE???  Yes, testing is best defined as a service - a service that provides visibility into the status of the product under development and the process being used to develop it.

If this is the case, then who is this service for? Who are its customers??

Of course in the end the customer is the “End-User”.  All the company’s work is for the end user.  But our specific service (testing and visibility) is first and foremost for our internal customers:  the development team, the product management team, the company’s executive team, etc.

A good (Agile) tester should always know who his customers are and what they’re looking to gain from the testing service.

If your development team is currently working on a specific and dangerous feature, and the best testing value is to provide them feedback on it (instead of running a regression load test), then go and test the feature and provide them the feedback (and the value) they require.

If your executive team needs to get visibility into the process (for example, the number of bugs being volleyed back and forth between the QA and the development teams) then make sure to provide the information and the value.

If in order for the product to be delivered on time you need to run the load tests NOW (because there won’t be enough time to fix bugs later) then make sure to run those tests and provide the value.

In short, when you work based on Agile Testing you need to understand your customers and their needs, and run the tests that best provides the value they require.

2.  Respond to change

Can you predict the future?  I guess not.

Are you able to plan what you and your team will be doing 7 months from now?  Unless you replied YES to the question above then I think the answer will also be NO.

If this is the case, why do you try planning ahead your testing schedules in detail four, seven or twelve months in advance?

It is good to have a list of operations and tests that need to be done (e.g. tests for each feature, regression testing, load testing, Alpha, Beta, etc). You should also have constraints for this tasks-list, and using these constraints have a general idea of what tests and operations should be done around specific timelines.

But trying to schedule the work of each member of your team on a weekly (or daily?!) basis many months in advance is not only useless but in many ways also absurd.

It’s better to have the ability to respond to change, to be flexible and to accommodate (embrace!) the changing reality of your project.

For example when a feature is introduced late, or when part of the development takes longer to achieve, then make sure you have the capacity to adapt and schedule your work based on these changes.

3.  Keep it simple

There are always a number of ways to carry out any operation.  If so, why not stick to the simplest?

This principle should be written on the walls of QA managers and testers offices who always respond to requests to change their work plans (see point 2!) with the phrase: “you don’t understand, it’s more complicated than you think…”

IS IT REALLY SO COMPLICATED???  Or are we making it more complicated because we don’t know how to be flexible?

I suggest you try it next time someone comes to you with a simple idea that can make a big change.  Instead of explaining why it is flawed, take the main points of this idea and look for simple ways to implement them.

The principle of keeping things simple usually starts with simplifying your mind-set.

It’s not enough to respond to change and to keep things simple.  As an (Agile) tester you should constantly learn from your experience, and change your ways based on the positive and negative results of your actions.

The best way to do this is by collecting inputs from your team and your customers (both internal and external).

In practice this is as simple as setting up a weekly or bi-weekly retrospective session – 10 to 15 minutes where everyone can share their ideas and concerns.

If you work with flexibiliy and responding to change (again, see point 2!), you will be able to implement  and validate these improvements right away

Agile is an approach and not a methodology

If you’ve made it all the way here and didn’t stop reading around point two then you already deserve my professional respect

I also hope you realize that Agile, in general, and Agile Testing, in particular, is not really a methodology, but an approach to managing the process of your testing team.

As such, you can use this approach regardless of, or even in accordance with, any approach (or methodology) used by your development team (customers) and your product management team (customers) to manage the project.

What do you think?  Ready to give it a try???

(*Images by FreeDigitalPhotos.net)