A CAST of 1,000 - Live from #CAST2015

I'm smiling a little bit today as I have realized that this is a special post for me. This particular post is number 1,000 on Testhead. When I started this blog, I don't think I ever imagined I would get to 1,000 posts, but I am still here, and you are still reading, and both of those realities make me very happy. Forgive the title, but it's just a quick celebratory dance, and on with the show.

We've been focusing on mind maps during the morning in Dhanesekar Subramanian's Tutorial on "Mobile App Coverage Using Mind Maps". The first part of the morning was spent discussing how to create mind maps and the properties of what makes a mind map effective. During this part of the morning, we are looking at some ways that a mind map can be use to develop a testing strategy and actually tracking coverage and progress. In addition to creating topics and sub topics, we can create markers that have semantic meaning, and we can also create nodes that have markers that show pass or fail, or can show level of completion:

A slightly silly example, but this shows how you can layer images on a node to convey information.

This is an interesting avenue for communicating exploratory test ideas. as I was playing with the admittedly simplistic music mind map, I realized that this could be a way to communicate a research coverage for a topic, or to be used for making quick notes for application test coverage. Instead of having to read through a bunch of minute details, especially if the testing is mostly clean with little in the way of comments. If we have sub-sections that can be marked as underway, completed, or those with issues, then I can drill down to see the issue and defocus on the rest of the stuff that is clean.

As an exercise, we are asked to look at a Mobile app from AirFrance called "Hop!" One of the areas that we initially started looking was to take the app and split it into the major functions on the screen (Book a Flight, Check an Itinerary, etc.) As we were looking at the workflows available to us, the natural reaction was to go through and break down the steps of the workflow into their own nodes, and give each option a node of its own. What we realized by doing this was that we made a lot of branches and separate paths for individual tests... our mind map quickly became cluttered with step details, and we had only looked at one button. If we were to do this for every option, we would have a very detailed and very messy mind map to try to look at. Instead, we considered looking at each workflow and display each workflow as a single node, at least to start with. The benefit to this is that this allows us to give the app a broad view first, and to create the important nodes that are the essential interactions. There will certainly be branches we can drop into, but rather than chasing down minutiae of steps, we can word the nodes so that they are unique workflows without the need to atomic specificity.

One of the things I am realizing with mind maps is that there are ways that popping a node can change the purpose of the map. By adding a "heuristics" node, we can turn a mind map that is a static model of an application into a test strategy, and do so with very little work. Even with these discoveries and neat uses, the biggest challenges with mind maps, unless they are very basis, is the fact that communicating the meaning of the map will take some communication. I've had mind maps sent to me as notes from a talk or a presentation that were very clear and understandable, and I've received mind maps that were undecipherable, at least to me they were. However, when I started talking to the person who made the map, and got to understand their individual context or the way that they were communicating the information, then the system became clear, and I understood the reasoning behind what they were recording.

It's time to take a break for lunch, so I'll chat with you all again in an hour or so. I hope you are finding this as fun as I am :).