The Testers, the Business and Risk Perception

 

One of the sessions I most enjoyed when I attended the TestBash on 22nd March was Tony Bruce's talk on testers and negativity. In his fantastic disarming style Tony discussed why testers are sometimes seen as negative by both themselves and the business, and whether that 'negativity' affects their lives outside work. Tony made a great point in that a tester role should be a positive one to provide information, why is that seen as negative?

A comment that I made in the ensuing discussion, that I think is worth expanding on, is how important the subject of perceived risk is to this scenario. I don't see testing as a negative role. Like Tony I see testing as an information provider to furnish the business with the information required to make important decisions. Those decisions will inevitably involve an element of risk adoption by the business and it is inevitable that each stakeholder in those decisions will have their own perception on the levels of risk involved. What I have seen is that in situations where testers are perceived as 'negative' could be more appropriately explained as a difference in the testers perception of the risks involved the development and the level of risk adopted in the decisions taken by the business. If the tester disagrees with the business decision makers regarding the risks of problems such as software bugs, delays in the development process and eventually customer dissatisfaction then this can result in negativity both from the tester in the perception towards them.

I see many reasons why testers and product owners or business decision makers may not agree on the levels of risk being taken in a product development. When testing professionals encounter a situation where there is a large disparity between our own acceptable risk level and that of the business as a whole then our position can feel and appear to be very negative. If this occurs, rather than assuming that we're the only ones with full visibility of the situation and belligerently sticking to our negative stance, I think that instead we might want to ask ourselves some questions in an attempt to explain this disparity in perceived risk.

• Am I overestimating the risks?
• Is the business underestimating the risks
• Ultimately - can I put up with it?

Am I overestimating the risks

In his book 'Risk, the Science and Politics of Fear', Dan Gardner gives an excellent explanation of how thousands of years of human evolution have formed our mental processes regarding risk.

'Our brains were simply not shaped by the world as we know it now, or even the agrarian one that preceded it. They are exclusively the creation of the Old Stone Age'

One consequence of this is how our brains make immediate risk assessments based on our ability to recall relevant experiences. This is a natural part of our 'System one' or 'gut' decision making process that has evolved to make quick decisions in risky situations. This is contrasted with the processes of logical reasoning which forms 'system two' or 'head' thinking which are slower but more accurate. We are pre-disposed to considering a situation to be risky if we are able to recall similar situations where problems have arisen. This recollection can be through our own experiences or through 'stories' conveyed to us by others, a concept known as the Availability Heuristic. As Gardner points out, whilst this mechanism worked well for our ancestors in avoiding danger, the mechanism is flawed when it comes to modern society. The huge amounts of information 'available' to us relative to a situation can provide an unrealistic perception of the actual risks present. To paraphrase Gardner for this context, we are running around testing software with brains that are perfectly evolved for avoiding dangerous animals while hunting and gathering.

Testers work revolves around finding problems with software. We find our own bugs, we read articles on testing and software problems and, when we meet other testers, we share stories of bugs and software problems. We will also typically spend more time investigating and examining problem behaviour than anyone else. An inevitable result is that the experiences driving our own availability heuristics' will be inclined to over-emphasise the likelihood of issues. The examples that are most readily available to us when facing new situations are likely to be based around problems that we have previously seen. We will have a natural tendancy to possess higher levels of perceived risk than other roles. The business, on the other hand, don't see all of the bugs. Their experiences of bugs are often masked behind figures, reports and metrics, which might convey summary information, however the personal experience of issues encountered is absent and so, therefore, is the 'System one' perception of risk. 

From a tester standpoint, a rather un-palatable conclusion that we could draw from this is that, in the situation where we have provided excellent status information to the business, they could well be better placed than us to accurately assess the risks involved in releasing the software. This is because they are more likely to be operating in a 'System two' process of logical reasoning based on the facts, whereas we will be strongly influenced by our 'System one' processes to assume problems on the basis of prior experience.

Testers role and experiences will also drive their assessment of risk to be heavily based around software bugs. The business decision makers, if they are doing their jobs effectively, will have visibility of other categories of risk which must be considered when making project and release decisions. Risks such as missing market opportunities, losing investor confidence and missing opportunity for useful feedback are all factors outside of the scope of the quality of the code which must be considered.

The somewhat enlightening conclusion for testers for me is this - we need to be able to let go of the worry. If you have done the best job that you can to provide the business with information, and they are making a decision based on that information, then you have done your job. Understand that your manifold experiences, both personal and second-hand, of failures in software causes your gut to see problems everywhere and you may not be best placed to accurately assess the overall risk involved in a software release. You may reject this idea, claiming that you are aware of biases yet not susceptible. As Gardner points out, this is a common problem

'Psychologists have found that people not only accept the idea that other people's thinking may be biased, they tend to overestimate the extent of that bias. But almost everyone resists the notion that their own thinking may also be biased.'

Sometimes as a tester you have to identify when you've been too close to too many problems to be thinking rationally, and work to providing the information to let others make the risk decisions. The folks making those decisions will hopefully have access to multiple information sources, in addition to the output of testing, which helps to balance biases in the decisions being made.

 

Is the business Underestimating the risks?

Of course there are two sides to every disagreement. Business decisions are made on the basis of perceived risk, which is based on the information available to the decision maker. It may be that the decision maker is actually adopting a riskier approach than they think due to poor, or poorly presented information, or their own biases. Underestimation of potential risks by the business will also result in a differential in perceived risk between business/management and testers. In their 1988 paper on "Underestimation Bias" in business decision making "An availability bias and professional judgement", Laurette Dubé-Rioux and J. Edward Russo suggest that underestimation as a bias is again heavily influenced by availability, or the lack thereof. 

"After evaluating such alternative explanations as category redefenition, we conclude that availability is a major cause, though possibly not the sole cause, of the underestimation bias"

In summary their findings were that decision makers tended to group risks for which they had low visibility into catch all categories and then underestimate the likelihood of anything in those categories occurring, with the lack of available examples of those risks proposed as the major cause of this underestimation,

If the perceived level of risk adopted by the business is based on low availability, and actually differs significantly from the real levels, then we may be able to help through providing better information to inform risk decisions. It is therefore our responsibility to convey as clearly as possible the relevant information to allow an informed decision. As the perception of risk is heavily influenced by our availability of relevant experiences or stories, it follows that in order to convey risk information then the most effective mechanism would therefore to be through the sharing of experience, rather than the presentation of raw figures. I've certainly encountered the situation when testing poor quality code where simply describing a few of the issues encountered can have a much greater impact on the recipient than the presentation of bug counts. Metrics and status reports can convey a certain level of information, however when backed up with examples of the nature of issues being encountered this creates a much more personal response and will have a much more significant impact on the perceived risk in the recipient. I've been in more than one situation where a "bug story" that I have conveyed to a manager has been subsequently repeated by them when reporting project status externally.

In short - if you want to influence perceived risk, then start telling stories.

Before doing so, however, consider whether it will benefit the business. As I've stated above it could be that our levels of perceived risk are unrepresentatlvely high compared to the actual risk, in which case telling stories of every bug found may simply result in the business moving closer to our 'System one' position away from a more realistic assessment of the situation.

Can I put up with it?

In my list of questions at the start if the post, you may wonder why I've included - 'can I put up with it?' , but specifically haven't included is 'how do I change things?'. The simple answer is that I believe that, whilst improving accuracy of perceived risk may be possible, changing the level of risk adopted by the business is unlikely to be something that a tester can achieve.

In a fascinating experiment, researchers into risk behaviour placed cameras at an open level crossing and then recorded the speeds of cars travelling through and the correlated risk of accident. The researchers then cut back the trees around the crossing to improve visibility and repeated the experiment. The results revealed a huge amount about human risk adoption in that, due to the reduced perceived risk, drivers increased their speed on average such that the same proportion of vehicles were at risk of an accident as before with no net safety benefit from improving visibility.

Behaviour was compared before and after sightline enhancement achieved by the removal of quadrant obstructions. At the passive crossing, sightline enhancement resulted in the earlier preview of approach quadrants. The perceived risk of approach to this crossing appeared to be reduced, resulting in consistently higher approach speeds after sightline enhancement. This performance benefit in response to the intrinsic ,effect upon safety realised by sightline enhancement yielded no net safety benefit

The implication of such results is that people will adopt a predefined level of risk to situations and will adjust their behaviour to reflect this based on new information, a phenomenon known as Risk Compensation. This led to interesting consequences for car manufacture, for example, where safety features don't result in improved safety, but instead result in increased net driving speeds and riskier driving behaviour.

This also has pretty fundamental implications to software projects. Essentially, if this phenomenon applies in business, then every action taken by a testing team to improve testing and the confidence in a product, will result in a change in behaviour by the business to operate faster or implement more features at the same risk level, rather than using the improvement to reduce risk.  For example, in the case of introducing test automation, if automated tests are seen as providing an equivalent level of confidence as humans executing the same 'cases' then the response by the business is likely to be to drive for faster development and lower levels of manual testing on the back of the perceived confidence boost. If the improvements by the tester were driven by a disparity between their own acceptable risk levels and those of the business, the outcome is likely to prove very frustrating for them.

Hence the question 'can I put up with it?' - if you as a tester are at odds with your company over what constitutes acceptable risk, get used to it, is unlikely to change and any improvements that you make to try to address it could actually make things worse.

Knowing oneself

The understanding of risk and personal bias is a complex subject. In the testing world we need to try to ensure th at our risk perception is based as much as possible on "System two" thinking and not 'System one' feelings driven by the availability heuristic. Avoiding such biases is hard, however in any situation we should be asking ourselves if our position is based on evidence arising from testing performed, or whether we simply have a 'gut' feeling that there will be problems. In considering risks are we calling to mind particuarly memorable problems from other projects that could be affecting a realistic assessment?

This problem is not limited to software testing, a 2005 paper discussing the problem of decision making in the medical profession provided these key guidelines for avoiding the availability heuristic:-

• Be aware of base rates (more appropriate for medical diagnosis, however the prevalence of issues arising from live use is an important yardstick)
• Consider whether data are truly relevant rather than just salient 
• Seek reasons why your decisions may be wrong and entertain alternative hypotheses
• Ask questions that would disprove, rather than confirm, your current hypothesis
• Remember you are wrong more often than you think

I think that these provide sound general advice. A feeling of constant negativity is not a healthy or sustainable situation for any role. Being aware of your biases and using these guidelines you may find that your negative position eases somewhat in the light of evidence. If you are doing your job and the business are happy then maybe you are overemphasising risks, and you need to lighten up and lose some of that negativity.

If, on the other hand, you are confident in your assessments, you are providing excellent information into your company's risk decisions, and you are still finding yourself in a very 'negative' position relative to the rest of the business, I suggest you think long and hard about whether you are in the right place. As we've seen, your business is unlikely to change.

References

Risk, the science and politics of fear: Dan Gardner
Risk perception by Lennart Sjõberg
DRIVER RESPONSE TO IMPROVED LATERAL VISIBILITY: EVIDENCE OF USABILITY OF "RISK HOMEOSTASIS THEORY".WARD, Nicholas J.; Husat Research Institute, Loughborough Univ. of Tech., Leicestershire, United Kingdom
Study: Airbags, antilock brakes not likely to reduce accidents, injuries - Emil Venere, Purdue University News
Five pitfalls in decisions about diagnosis and prescribing : Jill G Klein
Wikipedia - the Availability Heuristic
An availability Bias in Professional Judgement : Laurette Dubé-Rioux and J. Edward Russo Cornell University 1988

Photo: http://www.hotelsanmarcofiuggi.it/en/free_climbing.php

The self actualisation of testing

Testing is boring. That is a view held by many folks. It is a repetetive, mindless activity of following a series of highly scripted instructions. And yet a lot of people love it, and devote whole careers and huge chunks of their personal time discussing, promoting and generally enjoying being involved in it, myself included. How is it that bright individuals can find such a level of interest in a subject which to most other people outside of the profession consider to be dull beyond belief and not worthy of wasting their considerable talents on? Many testers reading this may be thinking that this is an old argument - the testing world has moved on to the extent that even banks are adopting Context Driven Testing. I'm in the happy position to be able to agree that things have moved on (thousands aren't), but I personally find it interesting to look at how things are changing and, more importantly, why?

I believe that they key to that conundrum becomes apparent when we start to examine the principles and studies of that most interesting subject of psychological and management science - motivation. Looking at the subject of software testing from the perspective of motivational theory then I find that it not only highlights why certain individuals are drawn to testing as a field of expertise, but also why the adoption of certain approaches to development and testing help to attract great people into testing roles.

Principles of Motivation

Before looking specifically at testing, it is worth presenting a brief potted history of some management and motivational ideas which I'm going to refer to later.

Scientific Management - In the 1900s a bloke called Frederick Winslow Taylor developed theories of management which were to become the 'Scientific Management' approach. Taylors theories focussed around taking knowledge out of workers and into centralised documentation and tightly controlled processes. Taylor believed that it was possible to define 'industry best practices' around the tasks performed by most workers and, by getting all workers to follow these, a more efficient process would result. Whilst subsequently criticised, Taylors theories now form the foundation for certain management schools, many of which have their roots in manufacturing, such as Lean, Total Quality Management and Six Sigma.

Maslow - Most folks who have studied psychology or humanities subjects will be familiar with Abraham Maslow and his motivational pyramid - the "Hierarchy of Needs". The hierarchy of needs is a model of humanistic psychology based on the principle that humans are conscious decision making individuals who will work towards self fulfilment if no other obstacles are present. The model outlines 5 layers in which various levels of motivation form a hierarchical pyramid from the the most fundamental "Physiological" needs such as food, drink and air at the bottom progressing up through "safety" factors via emotional fulfilment and "love" to the more rich motivational targets of "esteem" and the pinnacle of "self actualisation".

Maslow's humanistic school of psychology worked on the principle that humans are driven toward self actualisation, but obstacles at the lower levels of the pyramid will take priority. The hierarchy is based on the individual as a whole and so applies to all levels of life. Many folks working in the field of IT will be in the very fortunate position that the relevance of Maslow's hierarchy in their working context is really limited the top two tiers of the pyramid, esteem and self-actualisation. Given a stable environment and having met the more fundamental needs of the lower levels of the motivational pyramid, individuals will naturally be inclined towards lifestyle and work, where they are able to feel a sense of self esteem and personal achievement.

Herzberg - More specific to the field of motivation in the workplace are the theories of Frederick Herzberg. Based on studies of individuals in industry Herzberg concluded in the 1950's that the factors that acted as motivators for individuals to work to their best potential in the workplace were actually different to the factors which caused them to register high levels of dissatisfaction. Most of the reported reasons for dissatisfaction in Herzberg studies came about due to the absence of what Herzberg called 'Hygeine factors' which were not related specifically to the work itself, such as a safe and comfortable environment, company policies, supervision structures and relationships with peers. Salary also comes under this category. The greatest motivators that caused individuals to gain satisfaction from their work were fundamentally different and based more around the intrinsic elements of the work itself such as the nature of the work, the possiblity for personal development and the levels of autonomy enjoyed.

Principles applied

It is interesting to consider the application of the very different ideas on motivation to the field of software testing. One approach to the management of testing is to consider the activities of testers very much the same way as the activities one might see on a production line. Software is deliverered, tests must be prepared and executed, results recorded and bugs raised. The operation of testing can be broken down into the manipulation and processing of a predictable set of artifacts and actions. One could take the view that all of this activity is essentially predetermined, and many do, to the extent of predicting the number of bugs that will be raised by a phase of testing and monitoring of the variance of bug counts around this target as a measure of progress. If taking this view of the testing process then a scientific management based approach, or a derivative thereof, to the execution of the process is a relevant approach. The result is likely to be a focus on efficiency of throughput of the artifacts of testing and the adherence of the testing operation to the processing of these artifacts with a high level of monitoring in place, which is what we've seen in many organisations. This is not to say that this approach is wrong, it is simply the result of taking a certain view of the development process and adopting a management style to match, I would refer to this idea as inappropriate rather than incorrect.

When considering testing instead in the context of Herzberg's findings on motivational factors, one could argue that the role of scripted test execution is missing any of the significant motivational factors that Herzberg identified. Whilst it is possible to supply sufficient hygeine factors to avoid high levels of dissatisfaction - good pay, nice environment and clear supervisory structures, such a role lacks any level of autonomy or empowerment and the nature of the work can be mundane and without cognitive challenge. In terms of scope for improvement then building in a hierarchy of supervision will clearly allow for some possibility of promotion, however the motivation for self improvement here is not towards the improvement of testing ability itself but towards supervision, or sometimes test automation and the development of programming skills that is inherent in that activity.

So how does testing engage and motivate the smart folks that write the articles I read, present at the conferences I attend and generally make testing a good place to be? My feeling is that that these folks have created a testing role where Herzberg's motivational factors are inherent in their testing activity.

• Processes of collaborative specification give us environments where testers are included in early requirements analysis and decision making.
• Acceptance test driven development pushes testers to understand the business users to establish appropriate criteria for new features.
• Exploratory testing techniques furnish us with roles where testers are responsible for the interactive design, execution and reporting of their own testing activity - every action demands attention as the decision to take that action has been recently made by the person performing the action.

In each case the move has been towards increasing the levels of Herzberg's motivational factors in the testers role. 

One criticism of Herzberg's approach is that motivation does not necessarily lead to greater productivity at work. In a testing context you could argue that motivating people in testing is no guarantee that they are doing it better. I'd counter this by arguing that Herzberg's motivation factors primarily motivate through engagement with the work. Engagement and interest are critical factors in successful testing due to the concentration and awareness required during testing. The absence of these critical factors during testing can lead to mistakes, irrespective of the effectiveness of the defined activity. (As a relevant aside - I recently accidentally gave my daughter, who has a serious milk allergy, cows milk to drink. Surely there can be few greater motivators than the health of your child, yet I still gave her milk. Why? I was preparing drinks as I do every night, day in, day out in the same way. I worked out afterwards that I must have done this two thousand times, plenty enough to no longer be engaged when doing it - now we make it more fun by getting the kids to play a game reminding me to 'check' the milk each night, I'm more engaged with the activity and hopefully less likely to make another mistake).

My other argument would be this. In increasing the motivational factors in testing, we are not only making the job more interesting for those involved in it, but also making testing a more attractive career for people to move into. Attracting higher quality, brighter folks into testing teams will surely result in better testing by those teams. I'm incredibly lucky to have the calibre of people that I have in my team, and am convinced that these folks would not be attracted to the job unless it was interesting. We do it because we like it, and if improving motivation in testing means that we get folks like the ones in the 'blogroll of fame' linked in this site, or the amazing line up of folks speaking at the TestBash this week, then I am all for it.

References

Theories of motivation
Herzberg's Motivator Hygeine Theory
Scientific Management

 

 

 

 

 

 

To Mind Map or not to Mind Map

Testers love mind maps. We love them like kids love toys and kittens love balls of string. I am a great fan of the format, but I do find that as a community we have developed a tendency to use it at the exclusion of all other options. Mind maps are a fantastic way to capture information in certain contexts, and I use mind maps for a wealth of things. They are not, however, a panacea and there are situations that I've tried to unsuccessfully using mind maps to achieve certain tasks only to settle on another, more appropriate format for capuring and representing the information. I don't, for example, currently use mind maps for capturing exploratory testing activity.
Surprisingly, given that I've been using mind maps in testing for about 8 years now, I've not written specifically about my use of them. So when Lisa Crispin and Gojko Adzic independently contacted me in recent months to ask about how I use mind maps it prompted this post. I thought I'd put together a more detailed list of things that I do use mind maps for. At the same time I'll highlight what I see as some of the limitations of the format and some uses for which I have found them less appropriate:-

What are they good for

• Capturing meeting output
The clue's kind of in the name here. A mind map is a really handy means of capturing and mapping collective thought processes. Occasionally I use an electronic mind mapping tool for this, although in this context most folks I work with go with a white board approach, taking photographs afterwards to capture the output. The presence of a central topic in the map helps to maintain focus and identify if the meeting is straying off topic. The map format allows each category to be explored whilst concurrently maintaining an overview of the whole picture. This allows us to link in common elements and help to identify when we are going to deep into specific areas at the exclusion of other relevant ideas. Moving to another nodes of the map can help to keep discussion at the appropriate level and can provide stimulus if ideas in another area are drying up. In my company we specifically use mind maps for capturing our elaboration meetings in which we try to establish the targets for each user story. We'll typically break the story down into areas such as targets, simple use cases, risks and any assumptions we are making about how the system needs to behave. Using colours for text and branches helps to make the map clearer, a common colour scheme I use in elaboration meetings is black for central ideas and criteria, blue for assumptions and red for risk areas.

• Adding structure to a discussion
A danger that is particularly apparent in meetings with software development professionals is that focus moves too quickly to what can be achieved at the expense of really examining why it is required. On a couple of occasions where there was a risk of this I have found that drawing out a simple structure of second level branches around the main topic - Who, Why, What, How, When - can help to ensure the appropriate attention is focussed around the relevant customer and their underlying problem rather than rushing into the discussion of a solution.

In a recent discussion on a development for a customer we'd spent some time discussing a possible technical solution before drawing out a higher level mind map, at which point we identified that the requirements around timescale and potential impact for the solution meant that what had been discussed was not workable.

• Planning
Whether I am planning a talk, a blog post or a training course I generally start with a mind map. The process of adding and grouping ideas gives a great overall picture of the potential content and how it is related to the central subject. Once some logical groups are identified then it is much easier to decide what to include. One of the dangers with using a mind map to plan a talk or article is that you end up with a kind of random collection of everything that you know on the subject. I find that a great approach to avoid this is to start with a mind map to get your initial ideas down, then refine into a second diagram such as a fishbone timeline (see below) to refine your subject matter and introduce an element of flow.

• Breaking down something confusing
Mind maps don't necessarily need to be persistent, in fact I find that the format is more appropriate when used as a tool for immediate understanding rather than for long term capture. The structure of hierarchical levels of branches provides an excellent structure for breaking a subject down into categories. A few times over the last couple of years I've been faced with a dauntingly complicated project or application which I was struggling to understand. Using a mind map to categorically break the system down and identify areas for individual focus allowed me to get a better picture of the system, and the scale of any task associated with it, clear in my mind. This can be particularly useful as a group activity when starting a project. Last year a group of colleagues did exactly such an exercise on a particularly complicated development. We didn't refer extensively to the model afterwards, we didn't need to. The process of breaking the task down and mapping it out had clarified matters in the heads of the group and highlighted the requisite actions in each area such that the map itself was no longer required.

• Mapping Personal Development
One of the best uses that I've found for mind maps is in building incremental personal development plans for members of my team. With their personal development as a central topic we can identify second level skills that they want to work on and then build up groups of activities under each to build on their skills. Using simple iconography for priorities and whether tasks are in progress allows us to easily identify their progress and status.

All of the examples above share common elements that I think makes them particularly appropriate for mind mapping.

• The subjects of the map involve a single central subject or event and a need to represent breakdown or categorisation of this.
• Whether created through a single event or incrementally, in each situation the map represents a snapshot in time, there is no attempt to represent chronological events or the concept of causal relationships.
• Probably most importantly for me, the consumer of the map in each case is the group or individual involved in its creation. It is notable that none of the uses above involve the publishing of the map to external parties

 

What I don't find them so useful for

As I mentioned at the start, there are many situations where I feel that mind maps are inappropriate. Now this might seem pretty obvious, they are a tool and so are not universally applicable. I'm not talking here about obvious inappropriate uses, such as sending a "Dear John" message. I'm talking about situations where I've tried to use mind maps thinking that they are appropriate, only to find limitations in the format have resulted in me turning to other tools to achieve what I need to:-

• Sharing information
For me the main value of a mind map lies in the ability to document and/or reconstruct a mental process. In order to do this I think you needed to be part of the mental process that created the map. Viewing a mind map after the fact is like hearing about other peoples dreams or holidays, possibly interesting but lacking the relevant subjectivity to really appreciate it. In my early attempts at group based exploratory testing I attempted to share the mind maps from the sessions with the product managers. I did this as I thought it would help them to understand our thinking behind the issues that arose, but it did not work well. The feedback that I received was that the mind maps were most appropriate for review by people within the session and didn't mean much to folks who weren't there. There are exceptions of course, and some of the mind maps on testing subjects generated by Rosie Sherry at the Software Testing Club are a good counter-example. I'd suggest that for a mind map to be useful as a communication tool to others then it needs to be generated with that purpose in mind.

• Tracking sequential activity
Activity that takes place in chronological streams of events including some causal relationships between events does not translate well into mind map representation. This is one of the reasons that I prefer other formats for capturing the output of explporatory testing. Exploratory testing is a sequential process where the outcome of prior events affects subsequent decisions. In not capturing the sequential nature of the information can remove some relevant context around the decisions that were made and I think that the mind map format suffers in this respect. I know that there is a requirement for building a sequence when planning talks and articles as mentioned above. There, however, I was referring to using a mind map and then refining the information to create a sequence in another format (see below), whereas it is in the capturing of the events output from a sequential process that I find them less appropriate.

• Information with multiple categories
Mind maps rely on information branching out from a central subject. The format works great if you are looking at one main categorisation, however when considering multiple related categories then I find that they quickly get confusing. Just this week I was trying to do some planning around the division of our development into two teams using Xmind. I was trying to structure the testing across the teams, an operation which included people, responsibilities, resources and special interests. I found that adding individuals and responsibilities to the mind map worked well but when I tried to link the hardware needs and tie these to responsibilities the format broke down into a mess of floating topics and a mess of links.

What are the alternatives

It is all well and good my coming up with things that I don't find Mind Maps useful for but it is not a great deal of use without presenting some alternatives. As there are so many alternatives I've limited this list to a couple of things that I have used to specifically overcome the limitations of mind maps mentioned above.

• Tables
Tables are a great way to present more structured information where there are a number of factors under consideration with fixed categories and relationships. I find a table in excel with coloured sections is a much more effective way of organising this kind of information than a mind map. In the planning task mentioned before I laid out a table of teams and hardware on each axis and then populated with the tasks that needed completing.


I found this to be a much easier and more logical representation of the information for this task.

• Fishbone Diagrams
Also known as Ishikawa diagrams, this format is much more appropriate for mapping causal relationships. The purpose of the fishbone is to identify the causal factors that resulted in a specific event. Whilst the original format was specific in terms of the categories applied to the diagram. Some folks have subsequently applied the structure more loosely and even reversed the format to target a result and the factors that can help achieve it, typically referred to as a "reverse fishbone". I don't tend to use the fishbone diagram in its original form, however Xmind use much the same format for their "timeline" diagram


which I find really useful to refine and structure a talk as a follow up to an initial mind map to capture ideas - an example of this approach can be seen in my preparation for EuroStar 2011

• A Wiki
Whilst on the face of it a completely different use case, I think that the inclusion of a wiki is valid in this list. Where a mind map is not a great means to share information, a wiki is for this exact purpose. Turning the ideas captured in your mind map into a well structured wiki page makes them digestible for others and also searchable for folks wanting to research the subject later.

• Your Own Voice
Mind maps are a great way of organising your ideas. There is still, in my opinion, no better way of presenting your ideas than in your own words. Ideally in a conversation or possibly via email or other media, I find that well chosen words to be the most effective way of sharing our thoughts. The use of a mind map comes in organising these thoughts to allow us to present our ideas with clarity and structure.

Further reading

I hope that this post has given some food for thought on appropriate and inappropriate uses of mind maps. Here are a couple of useful resources on the subject for anyone wanting to explore the format:

• Whilst the format was used previously, Tony Buzan really pioneered the concept of mind maps and has software (iMindMap) and training on ThinkBuzan.com. The 'Who, What, Where, Why image in this post was generated from iMindMap
• Darren MacMillan's excellent Mind Mapping 101 is a must read for anyone thinking of using mind maps in testing
• Gojko Adzic has an interesting "zero friction" mind map tool development in MindMup which looks to be an exciting addition to the mind mapping arena.
• My tool of choice for Mind Mapping electronically is XMind. It has a really intuitive keyboard shortcuts which allow rapid map generation, plus very simple addition of icons, if being a little limited on choices of colour and layout. Most mind map images on this post were generated using Xmind.

Copyright(c) Adam Knight 2009-2010