Matt Archer's Blog

  • New Book

    I'm working on a new book. View the home page for the 'Tips for manual testers working in an agile environment' book
  • Enter your email address to receive notifications of new posts by email.

  • Subscribe

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.

Why agile testers should use self-generated maps to help organise their testing

2 Responses to “Why agile testers should use self-generated maps to help organise their testing”

  1. Mantas said

    Hi Matt,

    I am very interested in this topic and thank you for your post. It’s really useful. I have some questions for you about Story maps.

    I am creating story maps by my own strategy and I haven’t read about it anywhere, so sometimes I have some difficulties by using it. As requirements are changing very fast, the story map (from use cases) is on the wall made from paper and its not so easy track the test coverage.Its great to have a general view, but when I have to retest the same functionality, I often Have to change Use case diagram views. It would be better to use a simple tool like XMind, but then it not I can’t normally see the all view like on the wall.

    Do you have an example or could you explain more in details how you are creating and maintain these story maps? Test coverage? Do you use just tools or maybe you are putting sticks, use cases, ideas on the wall or white board?

    I would really be thankful to hear about this method more in detail 🙂

  2. This is good advice. I’ve often used this technique to draw hybrid architectural / process flow diagrams for the things I am testing. Both architects and user journey people recoil in horror at the funny look of these diagrams, but they are useful in isolating each stage in journey, each integration point and each separable section of logic or functionality. You can then ask yourself questions like what would happen if this bit broke, how can I break it, what will happen to the upstream/downstream items if this bit breaks and so and so forth. Diagrams like these are also useful in statically testing the logical flow of the design and useful in proving your own understanding and expertise in the system.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s