A Coach Guide to Agile Testing

A Coach’s Guide to Agile Testing is part of the nice series proposed to Agile coaches by Samantha Laing and Karen Greaves. This book provides a complete plan to run a workshop where members of a Scrum team can understand and learn the concepts behind Agile Testing.

As the rest of the series, this book uses the “Training from the BACK of the room (TFTBOTR)” approach that splits each session in four “C” parts: Connections, Concepts, Concrete Practice and Conclusion. The main message of the book is that software testing is an activity not a phase. The book also introduces the Agile Testing Quadrants and how to get started with test automation, something that you cannot avoid if you want to test in an Agile way. The book provides also an interesting chapter on how software testers can contribute in Scrum meetings.

I will recommend this book to every coach and scrummaster that needs to break the traditional silo organization between software developers and testers. Software testers will also find valuable information on how they can integrate themselves in teams that are adopting an Agile approach.

Reference: Growing Agile: A Coach’s Guide to Agile Testing, Samantha Laing and Karen Greaves, http://leanpub.com/AgileTesting

Quotes

If a team believes they are agile, but nothing has changed about the way they test, then there is still much to learn. We teach 5 key principles that explain why agile testing is fundamentally different to traditional testing.

Traditionally people view testing as a phase that happens at the end of development. In agile most have changed it that the chunk of development done is smaller, but the testing still happens last. Nothing has fundamentally changed about how testing is done. One way to see if this is the case is to ask people about their taskboards. If taskboards have a separate column for testing, it’s a sure sign that testing is still being thought of as a phase.

Traditional testers often don’t like agile because without detailed specification documents they are suddenly unable to do their jobs. This is because they consider their job being to compare the working system to the specification, and report where there are discrepancies. If you think about this for a second, the only thing they are checking is how closely the developers followed the specification. This actually says nothing about the quality of a product, or more importantly if it is fit for purpose.

We call this work ‘checking’. You know what’s really good at checking? Computers! Checking that 1 + 1 = 2 is easy work for computers to do, and they will get it right every single time. 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. Things like exploratory testing or usability testing.

In agile, testers need to become customer advocates. They need to deeply understand who their users are and what they are trying to achieve with the product. They should be the representative 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 user asks for a feature, ask them: “How would you test that?” or “How will you know if that works?”. This can help understand the real result the customer is looking for. Translating that into acceptance criteria for the team can ensure the product does the right thing.

Testers like to break stuff. Yes that’s a generalisation, but it is certainly true for the majority of testers we meet. The problem with this mindset is that it creates a divide between the developers and testers. Developers build it, then testers try to break it. See how this reinforces the other traditional mindsets like testing as a phase. When this gets really extreme some strange stuff happens, like testers telling developers how they will test the product. We like to share the following story.