Mind Map Testing - Part 1: Writing Very Simple Test Cases

Over the next few weeks I will be writing about Mind Map Testing. I recently moved to a new organization within the same company for a variety of reasons. One was they were using Agile, and I didn't know much about what Agile was but wanted to learn. 

I lead a small team of testers all with a background in waterfall testing. What I noticed was that development was working well in Agile, but testing was falling into mini waterfalls at the end of each sprint. Ideally testing should be done within the sprint, and the real solution is to have automation in place. With no automation (we are moving in that direction) I searched ways to help reduce the amount of overhead that testing has. One area was test case maintenance. So my first journey began.

Twitter has proved to be a valuable source of information. One of my first contacts was @darren_mcmillan who I found through a blog he contributes to called http://www.bettertesting.co.uk/content/. There is a wealth of information on that blog, and through that I came across something called a mind map. I was unfamiliar with the concept, but through exploring it I have fully embraced the idea. I downloaded Xmind and starting using it for basic brain storming. I then thought about using it for test case brainstorming, and then finally writing and running test cases in a map. I'm not the first one to think of this at all, and I take no credit for this. I just knew that I was onto something that could shift my perception of how I test.

As you know general manual test cases are often written in this format. 

Preconditions:

- software loaded

- hardware version X+

Steps:

1. Turn on device

2. Click on Button A

Expected:

Clicking on Button A shows a dialog.

The question is, what if there are multiple buttons to test? Say Button C, D and E. Testing generally copies the first test case and then changes A to C, etc. However, what happens if after Step 1, you need a new step(s) before you can click on the button? Now we are in test case maintenance hell.

Testers need to go through all the test cases and update each to include the new step. This is time consuming, and takes testers away from what they really want to do. My colleagues were skeptical about writing test cases in maps instead of Word documents, which then were imported to Quality Center. Luckily, a few testers were desperate to try something new and we worked together on the concept and it has grown.

Here is a simplistic map of how to write test cases for the above. Each Step can be considered a branch. Leafs of the branch can be the different actions.

And if you need to add a step, it is as simple as adding a node and moving items around. 

In future blog posts I will expand on this concept and show you how this will work for more in depth testing.

Your comments and feedback are very welcomed.