Why agile testers should use self-generated maps to help organise their testing
Posted by Matt Archer on February 18, 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).
To help organise our testing, we frequently divide software into parts. These individual parts can then become the focus for different activities, including test planning, designing, executing and reporting.
Traditional processes tend to dictate that testers should rely on artefacts created by other people to provide a map of the software and its different parts. A common example is to use a functional specification as a guide to partitioning the software’s capabilities.
Whilst this type of information is useful, relying solely on models and specifications created by other people to guide our testing carries the risk of limiting our work to what others have committed to file. A risk that becomes even more prevalent when you consider that agile teams value working software over comprehensive documentation.
In the absence of a provided structure, there is the temptation to wonder chaotically through the system looking for bugs. To do this is to overlook our ability to create our own abstractions of the system.
You can create your own maps using any tool or format. My only tip is not to be afraid of creating multiple maps or even temporary ones. Their goal is to help you consciously decide where to focus your testing next based upon everything you have learnt so far. Whichever maps help you with this task, are the maps for you.
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.