By Elizabeth Zagroba
[Elizabeth is speaking at TestBash Philadelphia, come and see her and others passionate testers speak!]
You're joining a project. It's already in progress. The team knows who does what, why we're building the thing in the first place, what the roadmap and limitations are, and where to find lists of all those things. Somebody graciously invites you to a meeting where they're using lots of acronyms and referring to pages and features they're in the midst of. It takes a day or two to get you on the group chat, invited to all the right meetings, and access to the bug tracker. Somebody throws you a quick email with a link to the passwords you need and some out-of-date documentation from before anyone was building anything. How do you figure out what on earth is going on with this project now and where you fit in?
Imagine that instead of starting a project with a list of links to PDFs, login information, and documentation, you got something like this:
I love reading a pile of documentation, but I realize that to communicate with my team, I need something smaller, prettier, and more focused to my audience. I use mind maps as a lightweight form of testing documentation, because communicating effectively with my team is as important to my role as a tester as finding the bugs and identifying the risks in a product.
I follow James Bach's Heuristic Test Strategy Model as a test plan at the beginning of a project, a way to document details and decisions about the product during development, and as a starting point for regression testing. A mind map like that provides an overview of the whole product. I run through these mind maps with my team to help them draw connections, recognize patterns that help prevent redundant code, and brainstorm what else I might be missing. Other mind maps focus on one particular issue, document it completely, and becomes the source of truth for my team and the client.
A Mind Map Can Reveal the Complexity of a Problem
While working on an e-commerce project, we were trying to determine whether a product was available for purchase based on a series of flags in the API. Initially we believed that each of the Boolean flags ("available online," "available in store," "discontinued," and "in stock") played a part. I made a product status mind map that displayed the 32 (24) different combinations of flags.
This provided a way to show the client how we believed their system worked before we spent development time on the problem. A conversation with the client revealed that the discontinued flag was meaningless and the in-stock flag was the one that really determined what the user should see. A second attempt at a mind map and a deeper look at what other meaningless flags were still available in the API gave everyone a better focus on the order of the logic and what messages a user would see.
The mind map communicated the logic of how our code would be written without the technical burden of looking at code. It covered all of our use cases and drew connections in a way that would have been difficult to do in a list. To compare, here's the same information displayed in a list:
Product Status
● Available Online = True
○ Available in store = True
■ Discontinued = True
● In stock = True > No Longer Available
● In stock = False > No Longer Available
■ Discontinued = False
● In stock = True > I can buy this product in a store and on the web.
● In stock = False > No Longer Available
○ Available in store = False
■ Discontinued = True
● In stock = True > No Longer Available
● In stock = False > No Longer Available
■ Discontinued = False
● In stock = True > Online Only
● In stock = False > No Longer Available
● Available Online = False
○ Available in store = True
■ Discontinued = True
● In stock = True > No Longer Available
● In stock = False > No Longer Available
■ Discontinued = False
● In stock = True > In Store Only
● In stock = False > No Longer Available
○ Available in store = False
■ Discontinued = True
● In stock = True > No Longer Available
● In stock = False > No Longer Available
■ Discontinued = False
● In stock = True > Online Only
● In stock = False > No Longer Available
You can tell based on the depth of the bullets that this is a complex problem. For some people, this visual cue is enough. If this works for your team and your client, go for it and. just use lists. In my experience, teams benefit from the added visual cues of icons, branching, and the ability to compare each of the nodes at the same level at a glance. In particular, the ability to close sections you're not currently talking about have aided comprehension and focused my team's attention to the problem at hand. Try finding the successful cases in the list and identify the conditions that caused them. Then try the same thing on the mind map.
Mind Maps Can Be Used as Regression Testing Oracles
An oracle is a guide that helps me decide whether what's happening is something I should expect. When a feature gets changed or a bug gets fixed, the mind map is one of the oracles I consider when I'm deciding what to test. I look at the other sibling nodes on the same level to see whether the change should apply elsewhere. I look at the parent to make sure nothing's changed unexpectedly. Let's say we change the shape of a button. I look at the other buttons to see what their shapes are now and look at the designs or talk to the designer to decide whether they all need to match. I look at the parent node to see what pressing the button did and make sure it still does that. I update the mind map with the new button shape so that future testers know how it works now. I refer to previous versions of the mind map to see what it used to do. With a tool that's as easy to edit as it is to read, updating what's supposed to happen is quick enough to do during a meeting or while you're testing so your documentation is never out of date.
Mind maps help us test not just the change at hand but the consistency of that change relative to the rest of the product, the product's history, and the feature's purpose. For more on these and other oracle heuristics check out Michael Bolton's Testing Without a Map.
How To Get Your Team On Board
Mind maps are a great place to add items that are too vague to be added to the backlog, but important enough that you don't want to forget them. If somebody says, "we should remember to test that when the feature is ready," or "I'm in the middle of this thing but I noticed something else," add it to the mind map. Get in the habit of reviewing it before your daily scrum, at your periodic retrospectives, or at other prioritization meetings so those good ideas don't get lost in the shuffle.
A mind map is a tool a non-technical person can grasp without being intimidated by the technical jargon. It gives them enough information to start in a particular spot and allows them to learn more as they gather more contextual information.
Mind maps help you share information with your team. People who aren't going to read an email or a document can be convinced to listen to your strategy with an expressive visual aid for a few minutes. Having a document that can be updated during a conversation or a meeting means it's never a chore that leaves you out-of-date. It's where you go for what's happening now, what's wrong, and what's planned.
Sharing your process and asking for your team's input builds trust in your work. As someone who points out flaws for a living, it's important to remember that I too have flaws and blind spots that can be remedied by the involvement of a properly engaged team.
Mind Map Tool Recommendation
I've taken to using Mindmeister because it's free, web-hosted, shareable, and has a wide selection of icons. Their icons allow you to transition the progress of testing or the status of a feature with a click, and the standard range of emojis are available to help you differentiate a bunch of nodes among a sea of words. Its privacy options are similar to Google Docs, allowing you to share the URL, make the whole thing public, or keep it all to yourself.
I've also used the free versions of the following products:
- MindMaple: http://www.mindmaple.com/Downloads
- Free Mind: http://freemind.en.softonic.com/
- XMind: http://xmind.en.softonic.com/
Give Mind Maps a Shot
Try them for yourself -- find something on your project that you understand or that you'd like to understand better. It might be a list, a user flow, or some functions that rely on nesting or inheritance. Spending a few minutes mapping out how you think it works, then show it to someone else on your team to build consensus. Keep it open and add to it as you test.
About Elizabeth Zagroba
Elizabeth Zagroba is a context-driven software tester at Huge in Brooklyn. She’s tested innovative user interfaces for iOS and Android apps, responsive websites, content management systems, and streaming and on-demand audio. Before Huge, Elizabeth worked on the digital team at a public radio station in Manhattan. You can find Elizabeth on Twitter and her blog.
