Why Agile Testing

I recently had a couple of weeks with a few activities related to “Agile Testing”. “Agile Testing” for those not familiar with it is the name we give to the set of thinking guidelines, principles and practices that help run the testing aspects of product development/maintenance in a more effective way under an Agile delivery approach.

A question that came up while presenting the concepts today at a client was “What’s broken? Why do we need this?”. While my presentation covered some of the rationale the question made even more clear (not that I needed any convincing…) that the guided evolutionary approach to improvement is a winner. If they don’t yet feel the need/pain there is a lower chance they will do something about it.

The question comes up - why don’t they feel the pain? Or alternatively, maybe they feel the pain but don’t associate it with the need for “Agile Testing”.

So I wanted to briefly touch on a few questions/indications that you might need to pull ideas from “Agile Testing” as your next improvement step.

• You applied WIP Limits and testing is becoming a bottleneck. Not once or twice, but quite consistently.
• You agreed to include test automation as part of the “Definition of Done” and you are seeing a queue building up meaning the automation is slowing the entire process down, creating significant slack for the people NOT doing automation.
• You find a lot of defects which send you to rework technical design due to lack of mutual understanding of the functional requirements / stories, or you find yourself leaving things ugly since there is no time to do the rework - earning you some customer feedback that you are not really providing high quality deliverables.
• You are not able to run a very granular flow - everyone claims smaller stories are not useful since the overhead to deliver them to testing and test them is so high. Let’s just keep using bigger items and deliver to testing not more than every 1-2 weeks.
• People feel that the test automation approach you have now doesn’t cut it. The total cost of ownership / lifetime costs are very high, and even though people understand the need to have automated coverage in order to integrate often, they are very frustrated by the costs.
• Testers are confused. Do they need to be automation specialists? Domain experts? Technical experts? Supermen? In this Agile Whole Team approach where there is flexibility and collective ownership - what is their unique value? what should they focus on?