As testers, we usually use a large variety of tools in order to do our job efficiently, whether they’re native apps, browser extensions or web applications. This is due to the fact that testing activities don’t always follow a strict pattern or ‘best practices’. In order to be proficient in our job, a certain level of creativity and imagination is required.
Following the same patterns over and over will not help us find and isolate new bugs, and at a certain point we will get stuck, and the job itself will become monotonous and repetitive.
The tools that we use
We all are aware of the fact that the software industry that becomes more competitive, advanced and is rapidly changing. The need for tools that help the implementation of quality software was obvious. Due to the fact that a testing tool is selected based mostly on the project requirements and the financial implication, for each type of testing we perform, there are some reference tools which won’t be replaced in the near future.
In performance testing for example, an indispensable application would be jMeter. Of course there are lots of alternatives, paid and free, but most performance testing scenarios can be covered with this tool so there’s no immediate need to find something better. Another reference name would be Selenium Webdriver which is the most used testing framework for automating web application tests since it’s compatible with most browsers and operating systems (for now).
For other types of testing or activities which are included in the process, new tools are launched every day, some of them showing real promise that they can make our job easier.
Below i have compiled a list of resources which could be a reference for various activities here.
A bit about mind maps
As you’ve probably noticed in the link above, the resources were not presented in the form of a list or excel table. The arborescent structure in which I organised all those resources is actually called a mind map.
So what is a mind map? Plainly put, it is a diagram used to visually organize information. Its main characteristic is that it’s hierarchical, starting from a center point, a subject/topic, and branching out in multiple directions until all ideas regarding that topic are expressed. A mind map is also relational as ties together different pieces of the whole and those pieces are connected to each other.
Organizing our testing ideas through mind maps
So why use mind maps in testing? I first got the idea of using mind maps from James Bach after I attended one of his lectures in 2015. He mentioned that, in a context where he is asked to test a certain product, usually ideas and approaches come overflowing and mind maps help him organise and attain a high test coverage.
This means that, for starters, when one has to test a new product or new feature of an application, mind maps can be used for documenting test ideas. A test strategy can be created as an assembly or those ideas which will help you express your testing vision to the team and stakeholders. In the case of a test strategy, the center point of the map is the project name and the different aspects of the test strategy are branches and sub-branches starting from that center part. I’ve taken from James Bach and Michael Boltons book, ‘Rapid Software Testing’ a set of heuristics for a testing strategy and compiled them into the mind map here.
Also, most modern mind mapping tools like Mindmeister offer the possibility of collaboration. This means that maps can be used for brainstorming sessions which could yield great results and ideas a single individual would not have come up with by himself.
Creating diagrams and flowcharts is also feasible with mind maps. This means that, if the need arises, the tester and the team can collaborate and create a map for user flows and user scenarios for a certain feature, before the feature is implemented. In my opinion, by doing this, the total implement — test — fix bugs time (for a certain new feature) is reduced. The reason is that, by openly discussing about the feature at hand before implementing, the testers gain some extra information about how a certain aspect is going to be implemented which could make the testing easier, and the developers gain some insight about how the testers approach is going to be, thus covering some potential corner cases or unexpected flows which would have otherwise been discovered during the testing phase, then having to be fixed and re-tested.
Test cases can easily be included in a mind map since the maps are usually easy to maintain and changing requirements will be represented without any difficulty. My suggestion would be to draw branches to every epic or user story and associate all the corresponding functionalities as sub-branches. Then you can add test cases under each functionality. I used a similar approach for creating an integration test for the application I was working on. The map was continuously updated and maintained and every time, before a deploy on the live environment we would run the integration test which consisted of multiple flows. We would add a corresponding image for PASS or FAIL to each flow and the entire team had access to the map so they could see real time if our tests were passing and everything was all right. A sample of this mind map can be see here.
On a final note, you can find a large library of mind maps which represent different areas of testing here and here.
The tasks I’ve talked about above, sometimes involve using more creative alternatives than reference software like excel or word. Mind maps can help us organize, gain clarity and improve certain aspects of our testing job.
There are plenty of mindmapping tools out there (like xMind, FeeMind, XMind, MindMapper etc), free and paid, each with their own sets of unique features. For the mind maps displayed in this article I have used Mindmeister , it has both free and premium subscriptions, it’s easy to use and has a wide range of useful features, but this is a personal preference and you plenty of other alternatives if this tool doesn’t meet all your needs.
By Dragos Campean
The article was originally published here.