Mindmaps are a tool which I have heard about and dabbled in for at least a couple years now. While I have always wanted to see them work for me, I just haven’t quite found them to be natural within my workflow. When I use a tool to create them I feel bogged down by how it is structured or non-intuitive shortcut keys. When I do them by hand I have a mix of issues with my handwriting and with not being able to erase or edit once its been written. That being said, I have always found them to be valuable and interesting as a thinking tool. I think this is why I thought to use them again more recently on my current project.
In my current project we are “adopting and adapting” a product from another region. One large module we needed to adopt was the file storage system for a user’s documents. This includes functionality like saving/deleting/copying/moving as you would assume. But when you dig in deeper there is creating new folders, restoring deleted files, renaming files, adding notes, and the list goes on.
Once the developers wired the whole module up there were a lot of questions around if that means the feature works. Being my usual cautious self I decided to list out the risks and in turn the testing options to verify this. I laid them out a bit like the three bears and as you might assume the business picked the medium route. The more intense route included needing data/user permissions to be clarified significantly more, and also included development work as it would have wrapped automation around the current behaviours. The smaller route was really just a gut check and may have caught the big things, but relied on end of lifecycle certification testing to catch anything more hidden. The middle route meant that I would dig into every nook and cranny we could identify, but that only a single user permission and a priority set of 3 document types. This clearly is not 100% coverage, but it seemed like the right call on cost/value for the team.
While the product owner had identified the features they could as user stories, I was not familiar with the original feature and wanted to dig in more. I decided to explore the original team’s site and see if there were any more features we should be testing. During this exploration, I created a mind map with Freemind. After a couple days I found that my perceived issues with the tool fell away and I all of a sudden felt like it sped up my work significantly. I could link externally to the user stories I was creating to track my work and I could also link internally within the map so that I did not duplicate nodes when it was the same toolbar on multiple pages.
In the end, I colour coded the mind map to indicate where the original product owner stories were covering, where some test cases we dug up from the other team covered, and where I identified additional work to be done. This set me up to have a really frank conversation with the business about the cost and time frames for the testing as well as visualise why even with the middle route of testing, there is significant risk given the size of the feature.
Since then I have been creating smaller mindmaps for each feature as I test it. I use the mindmap to write down my targets for the testing and some different data cases I may need to create. I then identify any behaviours I notice along with screenshots and annotations of them so that we can review and decide which of them are defects in our adoption, global defects across products, or enhancements that could be applied globally.
This has proven to be an amazing way to showcase the testing effort and everyone has really loved having more of a discussion around testing instead of the historical way which included the business signing off test cases before they could be run. I am now actively looking for other ways to use mindmaps effectively and I am excited to next create a mindmap which describes my current responsibilities and activities so that as I onboard a new QA/Scrum Master it can drive our conversations.