Mind Map Testing: Where are the test steps?

As you can tell in previous posts, mind maps do not give exact steps for test cases. This is one potential problem with writing test cases in this method (I will list pros and cons in a future post). I have thought about it in detail, and have come to this conclusion. Step by step instructions are not needed. Yes there are some test cases where very precise information is needed but that information can be added as a Note to a node on the map.


I have several reasons why you do not need to include steps:

• When a tester gets comfortable with doing test cases they will often see the title of the test case, and simply run the test by heart. 
• If a tester follows exact steps every time the test case is run, you get into a situation where you will not find bugs in the code. Think of a minefield. If you walk the same path all the time, what are your chances with finding a new mine? The same goes with testing.
• I have also been asked "If there are no steps, how will a new tester know what to do?" This is a legitimate question. My answers to this are:
• We work in an Agile environment and team members (I am trying to get away from using Testers and Developers) should be talking and working with one another. It is a great opportunity for a new team member to ask questions about how the product works and how they should test this feature. This will give a fresh prospective to the product as well.
• If a professional person working in high tech as a Tester is unable to figure out how a test case works, does that not mean that it is too difficult for the customer to use as well?
• By not giving exact steps it allows testers freedom to explore and build in ad-hoc testing. Not every tester is going to "Create a bookmark" in the same way. To get better coverage rotate who is tests what Area.

Mind map testing may not work for everyone, but I would like to hear your thoughts and experiences. What do you think works well? What can be improved?


Some topics still to cover are:
- Pros and cons
- Setting priority
- Test case execution
- Reporting on results
- Formatting
- Test case review
- Whole team approach

Creating Test Case Maps: Where Do I Begin?

In the comments below on my first post I was asked "What do you do with multiple test cases and/or test cases with multiple steps?". The answer is that you split them up and make individual maps. But where and how do you start?


The first step is to create a Feature Map. A Feature Map highlights all of your main areas for testing at a very high level. For examples going forward I have decided to write test cases for a generic web browser so that you can easily follow along. 


For my team, I have found that group test case writing has been very successful. We met as a team and first came up with the main areas of testing. 


For a web browser your Feature Map may look something like this.

Mind Maps are a great way to brainstorm your ideas and are very visual. With some work your team can come up with a good set of main features. You will notice ideas start flowing more naturally, which will lead to more test cases and therefore better coverage. 


Next I have had success with dividing up the main nodes into individual Area Maps. In this case we would have maps for Setup, Options, Bookmarks, History, Controls and Window. Split the work among the team and have each take one Area (an Area being a group of common test cases) to start expanding and writing test cases. 


A tester may go off and create a map for Bookmarks such as shown here. 

I suggest printing this map off or display on a projector for your team to discuss. Get everyone up to talk about the test cases and find out what is missing.


There is one map created per Area. If you find a map is getting too large, split it into sub maps. Think of User Stories in Agile. Sometimes we have to split them up to make them easier to manage. The same concept applies to Area Maps.


Next post will talk about test case execution and how to report on results. Again, this is at a very high level at the moment. We will go into more details about formatting, priorities, how to include detailed information, etc at a later point.


Please let me know if you have any questions or if there is something you want me to cover. The more, the better :) I want to learn just as much as you do. 

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. 

Humble Beginnings

Today is the first day of my blog. I have never written a blog post before.  I have found encouragement from colleagues and people that I have met recently to "just do it" and start writing and sharing my experiences.


My goal of this blog is to share ideas and gain new knowledge from other software testers around the world.


I started today thinking of a name for this blog. I thought of Testing the Limits (taken), Mapping the Future, Building a Foundation (sounds like construction work), and many others. I was trying to play with the idea of using Agile in the title as well well, but I do not want limit myself to Agile only. Yes I am exploring Agile testing currently, but I want to be open to all types of software testing.


There is much for me to learn and I am looking forward to your opinions, your expertise and advice.


Let the journey begin....