Planning using mind maps

Hello to everyone! Today we’ll continue with the series of post related to Mind Maps in Testing. Last time we did a kick off describing some areas where the mind maps can be useful. Today it’s time to go deeper in the area of planning using mind maps.

Test Plan

Before we start, what is a test plan? There are tons of definitions on the subject, there are lots of template if you take the time to google it, but our thinking of what should be a test plan is close to The 10 minutes test plan than an ISTQB definition of what should be a test plan.

Some “features” I would like to have in a test plan:

  • Meaning to the team: the test plan should be a living doc, the team should use it, questioning about the approaches we are doing and understand our main goals. If the plan will be stored and will never be used, what’s the purpose of having it in the first place? We don’t like documents or artefacts that we’ll never use; if that is the case, why did we invest time in it instead of learning or doing something more interesting?
  • Dynamic: don’t be afraid to change the scope or approach of testing throughout time. It’s a fact that the product will evolve, the features will undoubtedly evolve, so if we don’t adapt our Test Plan to that reality, what is the objective of having it?
  • A source of understanding for our product goals & strategy: I always tend to talk about the product and not only QA or Testing b/c what we are delivering is a product and the quality is a responsibility of the whole team.
  • It would be nice if our test plan reflects the performed activities not only what we’ll be doing, this approach enforces the goal of “meaning to the team”

How to use Mind Maps to Plan

Using mind maps tools give us some flexibility that are difficult to find using other approaches:

  • Simple to extend/Dynamic: when we are doing any kind of testing activities is simple to add nodes and express that information in a simple way so everyone could easy understand
  • Tree structure: as a mind map is just a tree is simply to map not only testing activities performed as a tester, is simple to convert automation results from XUnit results to a tree in the format of the tool we are using
  • State: there are lots of mind maps tools that allow us to set a state to a node, the states we want to use depends of our context and the way we want to express it but you could for example use to mark activities as: in progress, completed, pass, fail, blocked, etc.
  • Measurements: some tools allow us to attach some custom numbers to nodes, this is great to add information like complexity points to estimate time invested in some areas, number of bugs if we are interested in have a track of the amount of related issues or any other kind of information you want to attach to a node and later aggregate as a result of the testing activities. Remember that a mind map is usually stored as a tree so it’s pretty simple to build a script to get all of this information automatically for us.

We usually use Mindmup for some cases when we need measurements and states. Open Source project is here.

Some simple examples

We want to give you some samples of mind map usage, we don’t like to express as methodology or “best practices” because this depends a lot from your context, goals, testing strategy, etc.

Have a global mind map for the plan

We usually use a single mind map that link other mind maps. A good approach could be have all the related mind maps stored in github and have a script or application that load all the data and build a dashboard; following that approach there is no need to collect data manually ;) Also having all that information in github or any other repository is simple to build a snapshot of what we did in the past and analyse and learn from those experiences.

Describe risks

Mind maps can be used to describe the risks, identify possible problems which must be discussed with the whole team. Having this kind of things expressed in a mind map could be a good approach to optimise your meetings with the team and help them understand potential problems from the beginning. Remember that if we can address this kind of issues from the beginning of the iteration, then it is prone to reduce the likelihood to have problems close to the release time ;)

As a tool to work together with development

Mind maps are great to discuss with development, as soon as we can discuss our ideas and other stakeholders ideas with development the better. There is a high likelihood that the quality of the product is better if development knows what we’ll be looking before they finish the implementation. The cycles between dev & testing will be less if we all are in the same page.

Describe features & bugs addressed

Do not use mind maps only to describe testing scenarios, mind maps is a great tool to describe our ideas regarding a product. Don’t think only about which are the title of the new features, improvements or bug addressed, we can do better than that and start learning and model the reality from day 1.

Describe charters

It’s pretty simple describe charters and group them by feature, area, or whatever you think is best. Later is simple to have a big picture of which are our testing goals and discuss with the team. I found that meetings could be much more productive with a mindmap than a spreadsheet or a regular testing tool. In future posts we’ll share an approach to do exploratory testing using mind maps.

Describe scripted testing

Is pretty straightforward to build suites of scripted testing using mind maps. Also is pretty simple to build plans, add tests to plans, etc. Is much flexible than use tools like testlink that you need to create the test, create a plan, add a plan, create builds, etc. If you need to repeat a plan modified is simple, just copy, paste and modify on the fly, pretty simple right?

Describe automated checking

As we said before, it is simple to map an XUnit report to a mind map tree. If we add just one step to our automation we can have all our testing activities integrated in a single mind map. Building a dashboard with all of this information is incredible useful!

Have separate nodes for different goals

Keep it simple! Build a single testing plan and group each activity in different mind maps linked to the main one. I usually have different nodes for: Risks, Product Analysis, Testing Ideas, Testing Sessions or Threads, Scripted Checks that we usually run before go to production, Automated Scripted Checks, grouping testing sessions per product version. All of those activities/nodes depends of your context! Please share your experiences!

Learn from your practices in future iterations

Having all of this information stored in github give us the flexibility to build in a simple way a snapshot of the result from previous iteration. Using for learn! Analyze which problems did you have in the past, review testing ideas and sessions. Did you have some problem in production? try to detect a pattern of why did happen, keep learning from your practices and your product! The goal is improve our skills and practices as much as posible!

Do you think using mind maps for planning is a good approach? Have you used them before? Share you thoughts and stay tuned with our mind maps in testing series! Next topic to cover will be using mind maps to represent our testing scenarios! Stay tuned!

Introducing an Exploratory approach in your workplace

¡Hello to everyone!

Today, I’d like giving out a few pieces of advice from what I’ve done to introduce the ideas of using and working with Exploratory Testing while managing it with Session Based Exploratory Testing, and organising it using Trello.


Let’s get started taking our first baby step, because as it is expressed in a quote credited to Lao Tzu:

“The journey of a thousand miles begins with one step”. Lao Tzu

Baby Step Number One: WALK YOUR TALK

Exploratory approach - Figure 1

More often than not, you will come into a team that is already working/operating in a certain fashion, and because of it (provided you are in that situation), making a compelling presentation will play a key role. On the other hand, you may have the rare chance of already working with either Exploratory Testing, or with Session Based ET, or maybe even with both, if that is your situation then two things, the first one is that you are a lucky person :) and the second one is that you can skip this section of the post, otherwise, if your case looks more like the first scenario, keep on reading.

Before you can start talking about the What’s, How’s, and Why’s to your audience, make sure to read about the matter, to learn from it, and more importantly, practice it with a great deal of curiosity. Practice it not until you do it right, oh no.. no.. practice it until you cannot do it wrong! Basically, what I am saying is, you must make yourself an expert so that others see you like it. However, if time is against you, and you cannot allocate some room to learn and practice, then ask for someone with more experience and knowledge on the subject to help you with it prior to introducing the ideas.

Why is the previous important? Because, having a solid foundation on the subject is paramount, and also, it’s part of the basics, specially if you are looking to be successful when introducing new ideas to an organisation with old-time fixed practices.

What should I present?”” Focus on the main ideas, concepts and cornerstones around Exploratory Testing, make sure to explain the big picture, and also, what the team would gain from its implementation as a regular practice.


Exploratory approach - Figure 2

Ok, so if you are here, that means one of two possible things:

  • You either skipped Baby Step Number One because you are a lucky person, way to go!!; or,
  • You have already managed to introduce the idea, way to go again!!

Let’s continue then, so once people decides going for the idea of introducing and working with Exploratory Testing, then it’s time to keep on moving fast and propose a P.O.C. (a.k.a. Proof Of Concept).

You will have to let them know that it will bring value onto the team, as well as a new experience to those who are unfamiliar with the approach, and also, it will have a sense of participation, of involvement, because all of a sudden a lot of people (if not everyone on the team) participates in the experiment.

A few points to make the most our of the P.O.C.:

  1. Make sure to engage all of the members in the team, if they all, or at least some of them buy into the idea, then chances are they will also, somehow, help you with it;
  2. Propose working with it in a real project. In my experience, it has usually been easier earning people’s trust proposing the implementation with a real project, but, a real project in which risks are not “big”, or at least, in which there are no major impediments/constraints yet. Does that mean it should usually be like that? All POC’s should be conducted through low-risk projects? ¡NO, definitely NO! Why? Simple, because depending on your stakeholders, the people who matter and may make a difference to either support, or completely discard the idea, a low-risk project may be completely insignificant for them to the point in which they will not really see the real value to it. They might ultimately feel reluctant to include it in a high-risk project, or include it at all should they even consider implementing it. However, why is this so important? Because if you propose using it, experimenting with it in a real project, then, the results you make will be a lot more appealing to the people who matter, to the people who can make the decision to adopt it as a common practice within the organisation;
  3. Keep in mind at all times, a clear objective for the vision you have for the P.O.C., be very clear with what you are trying to achieve out of the mission;
  4. Last, yet certainly not least, keep your eyes on the results that you are trying to get, and more importantly, on how you want to present once the P.O.C. is completed.

Baby Step Number Three: RUN YOUR P.O.C.

Look for “a partner in crime” or for as many as you possibly can, and yes, I am talking about testers in your organisation. I know that that will at times be an easy to accomplish task, and some other times it will be hard, if not an impossible task. However, there’s always someone out there who happens to be willing to help us out while learning something new in the process.

Do you remember something I mentioned in the previous step? For the P.O.C., begin by picking either a project that is not on fire, or just a few areas of a test item within your organisation to conduct your chartered sessions.

As it is a P.O.C., let’s suppose you will be testing a small subset of functionalities from a test item in your organisation, what you can do is to think about your charters, create them and have them available in a tool such as Trello, and your board could look something like this:

Exploratory approach - Figure 3 Using such a tool has plenty of benefits, among which we can mention its reach, since it’s online, if you have a distributed team across the globe, the charters from your P.O.C. can be easily shared with your teammates. Otherwise, another way you can do the very same with a team located in the same office it’s through a whiteboard divided in columns, and lots of post-its with the charters in it.

Anyhow, and regardless of your preferred method for generating the charters, one other thing that will help you is assigning values to the charters, and by values, I am referring to weight. Take a closer look at the screenshot I shared from a board I created in the tool, the one charter that’s under TESTED is #6, whereas the one charter under TESTING is #5, you get the idea. Basically, the point is to weigh them so you have your priorities in order.

And you may ask, “Hey, wait a minute… where and how am I supposed to log my test notes?” Good question! That’s simple, let’s suppose you go for the first option, therefore, you make up your mind for using Trello. What you have to do is simple, each card has a placeholder for comments, and you can add as many as needed, so that very same space can be used for your Test Notes, check the screenshot:

Exploratory approach - Figure 4

“What would happen if you were using the whiteboard with the post-its?” Well, that’s pretty simple too, make sure to use coloured post-its, so you can use a colour of your choosing for the Charters and stick to it, and then, pick a different colour for the Test notes, which might also vary in terms of priority using an appropriate colour convention. For example:

Charters: Post-its with a yellowish-like colour; Test Notes: Whereas you might use coloured post-its like the following to indicate priority:

Reddish-like colour for those of high priority; Blueish-like colour for those of medium priority; and, White-like colour for low priority. Regardless of the systems or applications you implement, it is of the utmost importance to convey your ideas in a successful manner, as well as your objectives, results, and the value they will add with their implementation.

Stay tuned, because in following posts we will start talking about managing this type of work. In the meantime, let us know what you think, your opinions, your feedback, ideas and experiences on the matter.

Mind Mapping in Testing

Hello everyone! Today as a sequel to our last article, we want to kick off a series of blog posts related to the usage of mind maps for testing. The aim of the articles are a compendium of ideas and experiences we have collected over the course of time while using mind maps. Please share your thoughts, let’s keep an open discussion about it to keep on learning and improving our day to day work :)

Mindmaps in testing

This mind map will be extended in each new blog post from this series.

Which are my initial thoughts on how I could use mind maps in testing?

  • Describe plan of testing: if we take into account that a mind map is just a tree structure, we could start adding childs to set forth:
    • Charters of exploratory testing, organised in a root level of the plan or breakdown in Stories/Features, ticket numbers, tester’s names or whatever is the organisation you feel comfortable, there is no silver bullet for this, it always depends of your context;
    • Scripted checking? Of course! You may consolidate your scripting testing with exploratory testing and have all of them hanging in the same tree and all you information is consolidated;
    • Automation? If you have the skills to automate tests I’m pretty sure you know how to build a tree of execution of your tests! and of course, you may also link one mind map to another (the mind map of the plan of testing!);
    • Express other types pf ideas and activities in the mind map containing your plan.
  • Describe your scenarios of test
    • Do you execute scripted tests? Use mind maps to express them, is just a tree like any other testing tool and you could add the script as node information;
    • Do you use exploratory testing? Use mindmaps to define charters and handle sessions. Regardless you are using SBET or not, mind maps are a great tool to express units of execution of exploratory testing, and also come back later at them to understand which parts of your plan were covered;
    • Any other scenario of test could be represented in a mind map, and having it stored in some place could be very useful;
    • Execution log, there are several mind mapping tools that allows you to set up states in nodes, so you could use the leafs of the mind map as “units of execution”. You could define whatever framework fits to you, the aim of this post series is not just define “a way” of working with mind maps. We want to hear from you on how you use it!
  • Add information as needed. Some mind maps tools allows you to add information to nodes and add custom measurements. Sometimes we used to attach bugs found, issues found, complexity points, and any other information needed.
  • Getting Information. Once you have all of this information in a mind map or linked mind maps is pretty simple to build a script to aggregate information and build reports to express testing coverage, bugs found, lists of issues reported, complexity points of testing areas, etc.
  • Log of our knowledge learning curve and execution. We want also share one approach of how to organize your mindmaps. Storing them in a filesystem is ok, but in our opinion there can be better approaches to store the data and afterwards, compare our outcomes throughout time.

To organise this series of posts, below you will find the agenda with the topics we’ll be covering in the upcoming weeks:

  1. Planning using mind maps

  2. Designing and execution using mind maps

    • Exploratory (Coming Soon)

    • Scripted (Coming Soon)

  3. Getting Information from mind maps (Coming Soon)

  4. Don’t miss your history or how to use mind maps with Github (Coming Soon)

Have you worked with mind maps to manage your testing? How do you feel about this approach? We want to hear you thoughts about this!

Stay tuned with this series of posts!