Evolution of a model

I've been meaning to share some examples of visual test coverage models using mind maps and how these may evolve over time. This example is from a group of testers working on a training project that I've blogged about previously. It is a tidy demonstration of the rapid learning that is common in software testing and clearly illustrates how a model changes over time.

The first version of the model was directed by what the Test Manager told the team was important to test. Though the team had access to the application, there was a limited testing time frame and they did not stray far from the functionality mentioned in their initial briefing. Test ideas within the model were grouped into sessions with a specific charter, which are represented as pale gray boxes.

The team working on this piece of function included three testers who each executed a session. Every tester found at least one bug in their first session. They decided to reflect this against their model by colouring the completed sessions in red.

Before executing their second session, the group re-evaluated. Their first set of sessions had exposed them to a wider variety of function than the Test Manager had mentioned. They questioned whether other aspects of the application under test were also important, and whether the focus of testing should change accordingly. As a result, the left hand side of the model started to expand and, after discussion with the Test Manager, the priorities for their second set of sessions changed. To be clear about where their focus was, the team updated their model to show priority by adding numbering.

At the same time the wider project team adopted a common colour scheme for reporting, so that the Test Manager could expect models from different teams to adopt the same conventions. As a result, completed sessions were marked in green regardless of whether bugs had been discovered.

After the third set of sessions things changed again. The testers felt comfortable with the application, which had been new to them at the start of the process, and started questioning the Test Manager on the applicability of their originally proposed scope. As a result, the right hand side of the diagram became significantly simpler.

In addition, scope added during exploration was refined into succinct and understood coverage. At the end of these sessions testing against the left hand side of the model was complete.

Once all of the scoped sessions had been completed, the model looked quite different to the initial version.

Though this project was slightly contrived for training purposes, I have observed the same rapid evolution of visual models in many client projects. By representing test ideas in a format that is easy to adapt, we make our testing more flexible and responsive to change.

See also:

• Using mind mapping as a visual management tool - Aaron Hodder
• Mind Mapping 101 - Darren McMillan
• To mind map or not to mind map - Adam Knight