It has been awhile since I have posted to my blog. I am happy to say that I have been approved to continue writing and updating this site. I hope to share with others on what we have learned about using mind maps for writing and running software test cases.
To recap, in January I started in a new organization that was using Agile. I was excited to join this team as I was curious what Agile was and how it worked. I inherited a team and their existing test cases. The test cases were written in the standard way, and the team was using Quality Center to run those tests. They however were outdated.
Since we were using Agile, I started to think how do I make testing fit into this methodology? How do we test within a Sprint, instead of the normal waterfall approach I was so accustomed to?
I started following several Agile testers on Twitter, read several blogs and books, including Janet Gregory and Lisa Crispin’s excellent book on Agile Testing. http://lisacrispin.com/wordpress/agile-testing-book-is-now-out/
A colleague introduced me to story mapping, which she had learned about at Agile 2010. She and I used sticky notes to visualize all of the high level features of our application. It sounds simple, but this was very important for me to learn about the application. And when I saw it up on the board I realized it was not that different looking than the mind maps that I had started to read about. However, I had never seen anyone using mind maps for writing software test cases. Some people were using them for User Stories, or to brainstorm test cases, but not the actual writing of them.
The journey then began. I downloaded Xmind http://www.xmind.net/ and started to play with it. I reviewed our existing tests and noticed that several steps were often repeated in each test. After some trial and error I had converted our Smoke Tests (approximately 20 test cases) into a single map. It was visual and easy to read. I was onto something.
During a meeting with my team, I presented the test cases in the map format. There were a lot of blank faces around the room, and some confusion. Luckily after some convincing, the testers were willing to take a chance. Our tests were in need of a rewrite anyway, so they jumped on board. We worked collaboratively and rewrote the existing 1200 test cases. We reviewed the application, and went through it screen-by-screen and started developing a map for each screen.
Once done, we had about 15 maps. We printed off all the maps (each fit on a legal sized sheet), reviewed them more as a team by posting them up on our scrum room wall. We were able to cross off duplicate areas, and group tests into more functional areas.
We then presented the maps to the development team. There were some confused faces again, but the visualized presentation of the tests proved to be valuable. We could easily see missing or duplicate tests and developers could see what testing was expecting and what we were covering. The past system of storing test cases in Quality Center was a black hole for development, and they were not always aware of what we were doing.
We then started to run our manual test cases using the maps. For each sprint or build of testing, a new directory was created and copies of the maps were placed in that folder. I created a Dashboard that was used to track what maps were tested, level completed, number of passes and failures. We, as a team, had come up with and created an easy to use test case management solution.
It has been 10 months since we started this new way of testing. Our maps have improved greatly, and our test case maintenance time has been reduced significantly. The maps allow us to test new features within sprint on daily builds, which is a huge benefit. Regression testing still occurs at the end of the sprint, but with the maps we have been able to reduce the time that this takes by almost half.
The most important thing however, is that everyone enjoys using the maps. I am pleased to say that this concept has now been expanded to several other teams within our company. There have been several skeptics, but they all have been converted once they see how valuable and easy this has been. The proof of the success is that mapping, plus other improvements to our Agile processes have allowed us to deliver on time and with better quality multiple releases since January.
In future posts I will be diving into more of how we have evolved. You can read some of my past posts as well, or please feel free to contact me (email or Twitter).