Why you should resist overlaying traditional testing processes onto a sprint
Posted by Matt Archer on January 16, 2013
|This post is part of the tips for manual testers working in an agile environment series. A series of posts inspired by the topics covered in the Techniques for Agile Manual Testers course that is currently available to take in London (via the Ministry of Testing) and in Copenhagen (via PrettyGoodTesting).
Agile projects rarely complete something in a single sitting, instead opting to progressively elaborate their understanding of the software and the software itself over time. It is useful to remember this aspect of agile when deciding how to perform our testing tasks.
It is not uncommon for testing to be organised around a planning-specifying-executing-reporting-maintaining pipeline, but this carries the risk of achieving failure for any project, agile included. In addition, testers who overlay this approach to testing onto a sprint carry the risk of feeling at odds with the rest of the team, to the point that even the most test-sympathetic teams can feel like a challenge.
A way to overcome this problem is to progressively elaborate our testing in the same way that the team evolves the software. This doesn’t preclude an element of upfront test planning within a sprint or early test ideas, but be mindful that some aspects of the solution are yet to be decided and those aspects already decided may change.
This turns questioning into an finely-balanced art. Early questions are to be encouraged, but demanding a complete specification is unlikely to allow your team to work in the agile way it desires.
If you have a comment or question about this particular tip, please do not hesitate to Leave a Reply. A complete list of tips is listed below.