Essential mind mapping: Rapid test design.

By
Darren McMillan
– November 7, 2011

Overcoming the limitations of traditional test design

Test design is often a very time consuming process when it need not be.  People are often weighed further down by tools such as jack of all trades, master of none test management systems which dictate that tests are written in a less than optimal format, or introduce additional frustrations to those that try to use them.   External pressures outwith the team may see them required to produce sufficient quantities of tests in relation to features or requirements being developed.  Problematic, this certainly is.   When it seems everything is conspiring to make what should be a very creative experience, regimented and structured, then it is time to step back and think of alternative options.

Mind mapping helps reduce the cost of test design significantly by visualizing the item being designed and providing a holistic view point to develop ideas rapidly.   Essentially what this really means is that the creative side of our brains is much more engaged whilst developing ideas in a visual format.   Additionally by providing a birds eye view of the elements under test, ideas will spring to mind which may have not been consider in a linear thought process associated with writing tests in a document, or test management system.

Obviously this is not a straight forward technique that will work for everyone, so in the following series of posts I would like to introduce approaches to test case design using mind maps, and introduce considerations to make your experience with the concept more beneficial and powerful.

Test Conditions Vs Test Ideas

We will start off simple and look at the idea of test conditions Vs test ideas.  Let’s explain each briefly to remove any uncertainty behind them.   A test condition is a check that states based upon our knowledge of the item under test, we expect something to occur.  An example of a test condition might be:

“The login functionality should be easily extensible, so that in the future, should we want to add in an additional field such as a user pin, we could do this easily by extending the capabilities of the login API.”

Now if we were to take such an extensive approach for everything we thought of, the process of designing tests would become very long.

Test ideas on the other hand essentially allow you to note your thoughts down in a rapid but less extensive format.  Let’s look at the previous example for a test condition and switch it to a test idea:

“Extensibility > Login > Additional fields > e.g. user pin”

Now this is certainly less readable, and may prove more problematic for others to understand than a test condition, but it can greatly reduce the time it takes to design your initial tests.   You can also see how the format of test ideas blend well to mind mapping, which benefits from quick sharp notes, as opposed to longer sentences.

Additionally, consider a persons level of understanding of a type of testing.   It is much more difficult to write test conditions for something which we don’t have a full understanding of yet, but in a test idea format, we could cover this more quickly without going into too much detail.  Take for example, encryption used to secure credentials for a login process.   There are many elements to consider here, such as the type and strength of encryption used.  Has it been implemented correctly?  The distribution of keys and countless others concerns which go beyond my experience.

In a test idea format, we could simply list our knowledge in a short, quick format:

  • Security
    • Encryption
      • Type
        • Strong
          • Implemented correctly
          • Implemented incorrectly
            • Becomes weak
        • Weak
          • Improve encryption method
    • Key distribution
    • Others?

Or better still in a mind map format:

An example mind map, showing how the encryption test ideas could be formatted.
An example mind map created using XMind, showing how the encryption test ideas could be formatted, if presented in a mind map.

So when should we use one or the other?

I tend to base my decision upon the cost developing the tests Vs who will be executing them.   When you consider the person executing the tests, a developer would benefit a lot more from a test condition, than would another tester who already has a trained exploratory mind set; or at least we would hope so.

Proactive use of conditions

From a proactive viewpoint, one of the techniques I had used in the past was to introduce mind maps to take a holistic approach to test design.  You can read more about that in my post on lean test case design.   If you look at the example picture below taken from that approach, you can see that if we are mapping out a holistic view of the system under test, then test conditions become very useful.  Indeed, if the intent is to pass these on to developers as acceptance checks for their work, prior to handing it over to be properly tested, then the time taken to develop these becomes much more meaningful.   If we simply wish to hand them over to another tester, then this extensive conditional approach may limit that testers potential at uncovering new areas of interest, or additional concerns that test ideas would help promote.

An example mind map, showing how test conditions can be designed while maintaining a holistic view of the system under test.
An example mind map, showing how test conditions can be designed while maintaining a holistic view of the system under test..

My personal view on this, is that we should only ever go to the extent of writing extensive conditions if we plan on taking a proactive approach to testing, one that sees developers tasked with the execution of these test conditions in the form of acceptance checks against a piece of work they have completed, which they then plan to handover to be tested.   This raises developers awareness of areas of concern, and the thought process of how a tester would think, which over time will see them become more familiar with a testers mindset, and prevent in future at least the low hanging fruit testers would often find.

If you would like more information on Proactive Testing and how it can help your team raise awareness, then feel free to read my post on the subject.  I have planned a 101 style article on the subject in the future which should help introduce several fresh ideas on the topic.

Test ideas

Test ideas on the other hand, allow rapid development when designing what to test.   At Maidsafe, I used test ideas as opposed to test conditions for all test design, as this allowed me to work out what I should test and get feedback from others quickly, which would help pinpoint any gaps.

The example below was for the Pro version of our sister company Sigmoid’s product.  You’ll need to click on the image and zoom in to see it in more detail. Essential this product created a virtual drive, much like Dropbox, only on top of a distributed peer to peer network (no servers).  It was also unbelievably secure.

An image, displaying several test ideas generated to determine the extent of acceptance tests to be executed of Sigmoid Pro's product.
Test ideas generated to determine the extent of acceptance tests to be executed for Sigmoid Pro’s product.

You can see that for such a complex product you can still rapidly generate test ideas with varying levels of detail.  In my example, the things I have more knowledge in, have ideas broken down further.   While an idea such as  “Distributed denial of service attack” on the products peer to peer network, comes with some knowledge in my head about how I would have planned to execute the attack, but no clear steps or details.  Yet this is fine, because anyone working on the product that reads this item, will know exactly what I mean.   Better still, they might have their own ideas on how to approach this test idea, and upon discussing them, we may form a much better approach to execute it.  If I had simply listed all my thoughts on this in a conditional format, then the intended audience may not have digested the information fully, or worse still become biased towards it and not provide their own thoughts.

Techniques to improve your mapping experience

Not everyone has the ability to sit down with a mind map and rattle off countless ideas, one after the other.  Luckily this is not a unique ability, and is one that can be easily learned, or improved upon using simple techniques.

Let’s look at some of these techniques in a little more detail:

Technique 1: The mental model.

If you are unfamiliar with the concept of testing models then check out Michael Bolton’s excellent Elemental Models.   Essentially a mental model, is a model of considerations that you would apply when testing a system, product, or feature.  These considerations might simply be types of testing, key risk areas, hardware or staff resource concerns.

Everyone over time builds up their own mental models when testing systems. Mine often consists of a series of testing types that I would consider for all applications, depending upon the context.   Over the years from continually using it, and mind mapping ideas it has increased in size and as a result become more useful to me.

An example of my high level mental model might be as follows:

An image, displaying a mind map example of my mental model.
A mind map example of my high level mental model, which helps me rapidly generate ideas.

Again this is highly dependent on the context and may see items drop, or new ones be included.  The most important benefit to be gained from developing your own mental model, is the ability it provides in rapidly generating ideas based upon it.

The more you practice mind mapping using models, the more extensive your maps and ideas will become.  This is because the brains ability to processes and recall visuals is far greater than that of a written document.  This combined with the fact that our thoughts (although in the visual format of a map) are being constantly interacted with, developed, and extended, therefore further improving our ability to generate ideas, and lots of them!

Technique 2: Add a splash of colour

Probably more of a tip than a technique, but a very important one.  When I first started mind mapping, I was hooked with the way it freed up my mind to do the important work, instead of being hindered by my brains ability to link things together and make sense of it all.  I am always keen to understand fully why things work well, and additional steps I can take to improve my experience.  For mind mapping, adding colour to your maps is one very important aspect which will mentally allow your brain to group, focus and defocus on specific aspects of your maps.

Obviously with hand written mind maps this is easy, we simply choose a different colour of pen.  For tools, applications like FreeMind do it automatically.  Xmind, my tool of choice, for some reason has this option switched off by default.  On the image below I demonstrate how to enable this:

An image, showing how to add branch colouring on XMind.
An example image, of how to enable branch colouring on Xmind.

One issue with using a tool for this, is that you have to be very careful about your top level map nodes, as everything under that node (branch) will now become the same colour.  Visually this might not matter, but mentally your mind will group this as a distinct association.  So holistic idea generation might suffer if you do not give some careful consideration to your top level nodes.  I guess this makes the use of colour just as detrimental to idea generation as it is beneficial, if used incorrectly.

Technique 3: Brainstorming.

Mind mapping is a highly cognitive activity, which engages all areas of memory rapidly by linking distinct aspects together.  Maps help organize knowledge and structure it in a meaningful format, which benefits learning.  As such the more we practice it the better we become, and the more useful output we produce. This is true of anything which is practiced, but the key difference here is the visual organisation and structure, which promotes our memories ability to recall key events, in turn allowing us to brainstorm more rapidly.

In order to get the full benefit from a brainstorming session, you should make sure that before you begin mind mapping, you have at least a full 15-20 minutes uninterrupted.  This is because initial ideas will come rapidly.  Distractions will pull you away from a lateral thinking flow of ideas, back into a linear thinking (trying to make sense of it all) mindset.  This is highly detrimental to producing good ideas whilst mind mapping.  In fact, the minute you begin to slow pace, and ideas begin to be noted down less regularly, you’ve already begun to slip into a linear thinking mind set.

Brainstorm rapidly.  When the ideas stop flowing, take a break.  Return and recall what you have done so far, and more ideas will follow, although at a much slower pace, as you’ve already lost your lateral thinking mindset, and now you are much more focused on linking thoughts together and filling in gaps.

An excellent tip to improve your brainstorming abilities, and to prevent you slipping into a linear mindset, is to practice noting ideas down as one or two words maximum.  The more you write on a node, the harder it is to process when recalling it, and the more inclined you are to think too much over it.  Both obviously have a negative impact on lateral thinking, so practice hard at keeping mapped thoughts to one or two words.  It really is tough at first, but once you master it, you’ll benefit greatly.

Technique 4: External resources.

When you’ve exhausted all your ideas, stop and consider how you could improve it further.  Feedback from others is obviously a good starting point, but before you do this there has been some excellent work already done by others that you can make use of.

The guys over at The Test Eye came up with an excellent resource to use, to promote additional ideas in your mind maps called the Software Quality Characteristics v1.0.  This truly is an incredible resource to make use of, which will help you pin point gaps and areas of concern that you hadn’t even considered.

Michael Bolton also came up with a series of useful context free questions which I find very useful for considering other aspects I might have been biased towards while developing my ideas.

Taking tools away altogether and mind mapping with a group of people over a whiteboard can be highly beneficial as well.  This of course needs a very good facilitator who can focus the group and prevent the conversation straying too much from the task at hand.

Also highly worth considering, is to develop your own list of lightweight personas for reference to while developing your map.  These can be very useful prompts to defocus your thoughts and remove invalid assumptions you had created.

Wrapup

In this post we looked at the limitations of traditional test design and how mind mapping can help overcome these.  We went over using mind maps for generating test conditions and test ideas, and when one or the other should be used.  We discussed several techniques and tips which will help improve you mind mapping experience and skills.  There is still lots more to cover, which I hope to address over the next two posts in this series.

Thanks for reading.

Related posts:

  1. Tales from the trenches: Essential test case design
  2. Mind Mapping 101
  3. Tales from the trenches: Lean test case design
  4. Proactive testing: Tips from Michael Bolton
  5. Tales from the trenches: Lean requirements gathering.
Tags: , , , , , ,