Document Exploratory Testing Using Mind Maps
A definition of Mind Maps, and how they can be used to document exploratory testing.
Join the DZone community and get the full member experience.
Join For Free
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 was titled “a note on note-taking using mind m
aps.” there i heard the idea about
documenting
your test logs through
mind maps
.
the workshop was not as practical as i expected. it was more on how to use a specific tool for creating mind maps. however, i was so keen on the idea to use mind maps for keeping my test records, so i tried it immediately when i returned 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 documenting the bugs .
the main advantages 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 requirementsand 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 really believe that keeping notes on what has been tested is the proper way to go. however, many qas still are not in full agreement with this idea. 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. 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 that the vertical timeline based template (similar to facebook) was quite helpful. 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 .
what problem am i trying to solve?
- 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.
- 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.
document exploratory testing via mind maps
as i mentioned previously, i log all kind of information during the test execution. examples include date, time, environment, execution browser, the theme of the site, input data, and output data.
i paste the date and time as a label of the currently executed mind map node (current test case).
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.
all other 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. i also associate the urls of the bugs (from the bug tracking system) with the currently executed node.
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.
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.
Published at DZone with permission of Anton Angelov, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments