1. Home
2. Blog
3. The Agile Testing Manifesto

At one of my trainings someone asked me a question, "How can testers survive in an Agile environment?" The training, by the way, was dedicated to quite a different topic, but the issue seemed to be very sensitive. I think we can find some answers to that question in "The Testing Manifesto" compiled by coaches Karen Greaves and Samantha Laing by analogy to the famous Agile Manifesto.

 

 

That sounds cool, but needs some further explanation. You can find more details in the book "Growing Agile" by Greaves and Laing. Agile testing is not just the same traditional testing but in sprints. The Agile approach must completely change the way the team thinks.

 

We value testing throughout over testing at the end.

 

Traditionally people view testing as a phase that happens at the end of development. In contrast, in agile, testing is not a phase but an activity that needs to happen, along with coding, documentation and everything else.

 

If task boards have a separate column for testing, it’s a sure sign that testing is still being thought of as a phase, and the testers' activity is still separated from the work of the remaining team.

 

Agile coaches Karen Greaves and Samantha Laing recommend a different approach: testing tasks should go through the same phases as all other tasks – "To Do", "In Process", "Done."

 

If you want to add another column for the task verification stage, that's an excellent idea! The purpose of such column is that every task should be reviewed by some other member of your team straight after it is done. Peer reviews, even small ones, can be conducted for code, documentation, and test cases.

 

We value preventing bugs over finding bugs.

 

"The greatest victory is that which requires no battle" – this ancient wisdom is assigned to the Chinese military strategist Sun Tzu. The same is true about bugs: preventing bugs is better than finding and correcting bugs.

 

How can you prevent bugs? You should do that as early as possible. Most bugs occur at the requirements phase.

 

Usually it happens like this: people make assumptions about requirements and implement those assumptions before clarifying. The assumptions are only clarified once the software is tested, and the bug is then found. It would be much more productive to clarify assumptions before anyone wrote a single line of code, and to make sure everyone from the customer to the developer and the tester have exactly the same understanding of how something should work. So, the best way to prevent bugs is to ask questions, especially stupid questions that everyone thinks the answer to is obvious.

 

The authors of "Growing Agile" discuss the following example. A team needed to create a report showing the average sales data for the last six months. Everyone thought they understood the requirement perfectly, and it didn’t need much discussion.

 

Then Greaves and Laing decided to ask a few questions:

 

• If I run the report on 1 February is data from February included or not? What about if I run the report on 29 February?
• How exactly should the average calculated, as monthly average, or the average over the six months?
• Does the average need to be stored or is it calculated on the fly?
• Does the report need to be stored, or will it only be created when someone selects it?
• What field in the database is the average calculated from?
• Who would be using the report and why did they need it?

It soon became very clear that no one had considered these items before starting the implementation, and that more information was needed before they could build the report. Imagine the rework and bugs that could be created if you built this without the answers to these questions…

 

We value testing understanding over checking functionality.

 

Testers who think their job is to check a product compliance with specification often don’t like agile. But the only thing they are formally checking is how closely the developers followed the specification. This actually says nothing about the quality of a product, or if it is fit for purpose.

 

If the tester's work were just that, then all testing tasks could be automated, and there would be no need of human beings in the process. Besides, computers do such tasks much better and quicker, they don’t get bored or tired or distracted. With agile testing simple checking should be automated so that testers can be freed up to do the kind of work computers can’t do, for example exploratory testing or usability testing.

 

In agile, testers need to become customer advocates; they must deeply understand who their users are and what they are trying to achieve with the product. Testers should be the representatives of that customer in every design decision, ensuring that the feature meets the customers' actual needs, not just the specification, or even what they asked for.

 

When a customer asks for a feature, ask them: “How will you know if that works?” This can help understand the real result the customer is looking for.

  

To be continued.