Test Plan Mind Map

Coverage Maps

Uber self-driving taxi
Timtempleton, CC BY-SA 4.0, via Wikimedia Commons

 

The story of quality drives the quality research strategy, the set of ideas that guide testing. A test plan for a software product, system or service can then be constructed and modelled out using techniques such as mindmaps that contain all of context that make up the hypotheses.

The first step is to research all the background material you can to find initial claims of quality. As testing progresses, you’ll likely find more claims to add to the test plan right up until release. Break these claims down and map them out as you go (analysis). Organise these by different quality dimension. It may be useful to get feedback on the dimensions and initial claims that are most important to the stakeholders. These can be marked with different prioritisation flags. In the example below, included are just used requirements, actors and emotions:

Click to enlarge

 

Once this is complete, it’s time to do the risk evaluation. There are two approaches to this. The first is to generate stories of benefit and then flip them on their head to create stories of risk where the benefit may not delivered. The stories of benefit can be generated from the requirements or generated from other sources (Tomes, 2019).

The second is to brainstorm risks against the most important quality dimensions to come up with other ways that lost value or harm may come about. Get as many people involved as possible for many different diverse ideas (van Daele, 2017).

These quality stories of benefit and risk are hypothesis building. The hypothesis story may contain assumptions about many of the elements that make up the story and will currently lack the evidence from the software at this stage (this will come later). 

Click to enlarge

 

As testing progresses, further benefits and risks will be uncovered and can be added to the test plan. The next step is to add charters and questions, plus any other test ideas that come to mind at this stage (Hendrickson 2003) (Tomes, 2019)

Also add anything that requires any specialist environments, skills, training, tools or personnel. The risk coverage map part of the test plan is now complete and ready for testing.

Click to enlarge

 

The next step is to research the product to uncover information about the makeup of the software itself. Include components, processes, data, states and anything associated with the software, like external systems and supporting documentation (Bach, 2020). Think of these as nouns, verbs and adjectives. As before, break everything down and map it all out to serve as an objective model to test against (Pirsig, 1974) The will provide the vulnerabilities (weak product elements) evidence to your hypothesised stories of benefit and risk.  These elements can also be prioritised by the stakeholders, allowing them to have input to what’s most important:

Click to enlarge

 

Once again, add any test ideas, questions or designs plus anything that requires any specialist environments, skills, training, tools or personnel at this stage:

Click to enlarge

The software element coverage map is now complete. As testing commences, the findings can be added to the mindmap too. An example of this are more complete stories of quality such as bugs, that contain the story of benefit or risk supported by evidence from the software itself. Optionally link these together on the mindmap to make connections between the benefit or risk and the vulnerability on the software element map. This uses deductive testing where the goal is to falsify or support a hypothesised benefit or risk respectively.

Project issues and constraints (blockers) are also test results of the quality of the testing project, if not the product, so these can also be added to the mindmap. All bugs can be reported and all findings can be compiled into a test summary report for stakeholders to read as required:

Click to enlarge

 

Tree of Risk

The mindmaps build out like a tree to cover as much risk as possible. There is an infinite amount of unknown risk, but the approaches above give a good, broad coverage of the most important aspects.

A tree of known knowledge branches out into the unknown knowledge that surrounds it

 

 

References

  • Bach, J., 2020. Heuristic Test Strategy Model. Version 5.7.5 [online] Satisfice. Available at: Link
  • Pirsig, R., 1974. Zen and the Art of Motorcycle Maintenance: An Inquiry into Values. 40th an. ed. London: Vintage, p. 90
  • Hendrickson, E., 2013. Explore it! Reduce Risk and Increase Confidence with Exploratory Testing. Frisco, TX: The Pragmatic Programmers, p. 12.
  • Tomes, S., 2019. Start Exploratory Testing Today – Risks & Questions. [online] TestBuddy. Available at: Link
  • van Daele, B., 2017. RiskStorming Workshop. [online] Isle of IT. Availble at: Link

v1.0

Leave a Reply

Your email address will not be published.

You may also like these