Document Exploratory Testing Using Mind Maps

Semi-Automation
65 Shares
Document Exploratory Testing Using Mind Maps

Last week I attended Agile Testing Days 2015 (Greatest Europe’s Agile Software Testing Event). There were a lot of lectures about Exploratory Testing, but I found one particular most interesting- “A note on note-taking using mind maps”. There I heard the idea of documenting your test logs through mind maps. The workshop was not so practical as I expected. It was more on how to use a particular tool for creating mind maps. Therefore, I was a little bit disappointed. However, I was so keen on the idea to use mind maps for keeping my test records, so I tried it immediately when I came back from Germany. In this article, I am going to share my approach to Documenting Exploratory Testing using Mind Maps. I also tried it at work, and my colleagues loved it too.

Exploratory Testing Definition

Here is a definition of the exploratory testing for the people who haven’t heard of it.

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution.

Sometimes this approach can be more powerful and fun than scripted testing. It depends on the skill and domain knowledge of the tester. To further explain, a comparison can be made of freestyle exploratory testing to its antithesis scripted testing. In the latter activity, test cases are designed in advance. This includes both the individual steps and the expected results. These tests are later performed by a tester who compares the actual result with the expected. When performing exploratory testing, expectations are open. Some results may be predicted and expected; others may not. The documentation of exploratory testing ranges from documenting all tests performed to just recording the bugs.

The main advantage of exploratory testing is that less preparation is needed, critical bugs are found quickly, and at execution time, the approach tends to be more intellectually stimulating than execution of scripted tests. Exploratory testing is particularly suitable if requirements and specifications are incomplete, or if there is lack of time.

One of the biggest disadvantages in my opinion is that the exploratory testing is harder to be documented than other approaches.

Notepad Style Test Logs

I believe that keeping notes on what has been tested is the proper way to go. However, many QAs still are arguing this. Anyway, you can check my old approach of documenting my testing activities in the article Be Better QA- Start Creating Test Logs.

Here is a sample “Notepad Style” test log.

1. *NEW* /LIVE/ “Browser: Login with Gmail Chrome” (23-Sep-2013 09:44:20)

newUser@gmail.com

Client id = 123

https://mail.google.com/mail/u/0/#inbox

Login page displayed => OK

Previous account name displayed => OK

Login => OK

Logout Button available => OK

</OK>

There you can find information about the execution environment, date, time, test case, test input, output and summary. Anyhow, this format is fairly unreadable, especially for the people who are not familiar with the syntax. Moreover, there are not any built-in shortcuts to ease the usage of the “Notepad Style” notes. Of course, I created several Autohotkey scripts to facilitate the process but even after that the usage is not straightforward.

Mind Map Style Exploratory Testing

For mind map creation, I use the free version of XMind 7. Also, there is a web-based version of the tool. I think that the default style mind maps are not appropriate for documenting exploratory testing because the nodes are circling everywhere. However, I found especially helpful the vertical timeline based template (Facebook like). This way every new node is representing a new test case. Usually, I don’t use pure exploratory testing- I design most of the high-level test cases in advance. Most times we need only test case titles + verification checklist + the feature’s requirements.

XMind Document Exploratory Testing

What Problem am I Trying to Solve?

  1. Usually, after I complete my testing I send my results and executed test cases to my teammates to review them and suggest new missing tests if there are any. However, if the format of the test logs is unreadable and complicated, they won’t read it, or if they do, they won’t fully understand it.
  2. When we upload some of our applications on Production, we need to keep all test logs and test results indefinitely in case of an audit. The test records should be understandable for the auditors. Otherwise, they won’t be able to verify them and bad things can happen after that.

Prepare Mind Map Before Exploratory Testing Session

As I mentioned earlier I usually create all high-level test cases that I can think of in advance. With the “Mind-map Style” documenting I create all test cases as different nodes and save the mind map as a new template.

This way I can perform this session multiple times in case I need to retest something. After the first execution of all prepared tests, I usually add new tests during the session (this is the whole point of the Exploratory Testing). After the first session is complete I add the newly generated test cases to the default template.

Save Mind Map Template

Document Exploratory Testing via Mind Maps

As I mentioned previously, I log all kind of information during the test execution like- date, time, environment, execution browser, the theme of the site, input data, output data and so forth.

I paste the date and time as a label of the currently executed mind map node (current test case).

DateTime Label Mind Map

Another interesting thing that I set on the nodes is a URL if there is a particular URL for the test. Just mark the node and insert a new hyperlink, it can be later opened through the planet icon.

The final result of the test– pass, fail, inconclusive, more information needed is set using the built-in XMind’s markers.

xmind markers

All another kind of information is logged as subnodes of the executed test case’s node. If there is a bug, you can insert an image of it directly on the map. Also, another thing that I do is that I associate the URLs of the bugs (from the bug tracking system) with the currently executed node.

Mind Map Data Nodes

If one particular test case should be executed against multiple combinations of browsers and themes or something like that, you can easily create different nodes for this combinations.

You can find the final result below.

Shopping Cart Exploratory Testing Demo

Another handy thing is that you can save your mind maps directly to Evernote (you don’t need the Pro version). After that, you can encrypt them if you want.

Save Mind Map Evernote

  • Kobi Halperin

    Thanks, but I wonder – If you don’t make use of the Coloring and Icons abilities of MM – Where is the benefit in compare to using the basic abilities of a Test Management / ALM SW, and just creating a Tree format with same Data?
    At least then its more exportable as its stored in a DB.
    As to logging which you mentioned – I guess combination of Auto activity Tracking logs with user comments would be best (as its less intrusive thus free us to think and explore) – I think QASymphony has such a tool, and I heard testim.io too.
    @halperinko – Kobi Halperin

  • Pingback: Discovering Exploratory Testing | CrossBrowserTesting.com()