Visualizing Success

Requirement Review, Impact Analysis and Test Planning with Mind Maps

Professionals working in quality or test roles need some form of planning to discover and describe how we think testing will be done and what it will look like.  If you are like me, you have seen varied and sundry tools and planning models put forward as “the solution” that fix the shortcomings of the others.   Each of these will be replaced by some other technique that will “fix” the problem. 

The fundamental question these models all try to address is “How will you plan testing so we can show what has been done, what remains to be done and how long it will take?”

The problem in answering that question is that it is usually asked at a time when the major points within a project are not clearly understood.  When that happens “I don’t know yet” may be the most correct answer, but few Project Managers will be satisfied with that. 

I have been using a tool I find helpful for both requirements analysis and test planning.  I find that requirements analysis needs to be done so the test team and I can understand the intent.  This gives us a foundation for meaningful test planning and testing to occur. 

Mind Maps for Requirement Analysis
Each organization will describe requirements a little differently. 

There may be “business requirements” which describe some need that is not being met by the people using the software or the results of the software.   There may be “solution requirements” which may be a bit more granular in that they are associated with a given business requirement and describe one aspect of how that requirement can be fulfilled.  Then there may be “solution detail requirements” which may be extremely granular and get into the technical aspects of addressing the need. 

​Unfortunately, people documenting requirements are often imprecise in their language.  Even when they believe they are being extremely precise, there are some pieces that will be missed.   

I start with mind maps to see if any of these gaps can be identified.  I pull the requirements from their repository to visually represent them in some logical manner.  Usually these are by function or component within the software.   Sometimes, if it is for a project on a well-known existing system, I map only the change.  Other times, if it is a larger project or a significant change to an existing project, I will map the current system with the changes highlighted. 

I began doing this several years ago when I encountered documented requirements I did not understand.  Individually they made sense, but when I tried to consider them as a group I found I could not make sense of them.  By mapping them visually, by function, the reason became clear.  I noticed there were several requirements that, taken as written, contradicted each other when viewed together.  By asking for clarification, I was able to get the lead developer and designer to work with me to understand what the true scope of the project was. 

By representing the requirements visually, by specific function area, I was able to identify potential conflicts and gaps I was not noticing when the requirements were in a tabular form. 

When a single requirement has a relationship with more than one functional area, I am able to see that and identify that with dotted lines between them.  The more dotted lines I end up with, the greater the likelihood some of the requirements need to be reconsidered or restated.  This is another form of ambiguity resolution I was not able to effectively contribute to before I began applying mind maps to the question of requirements. 

By updating the requirements mind map as more information is available, I am able to assist the design and development teams in understanding what the product owner and other stakeholders believe they are requesting.  I can also help identify potential trouble-spots beyond the requirements.

Mind Maps for Impact Analysis
In some instances when the requirements appear to be understood, they are masking potential problems within the software.  If, for example, a requirement can be expressed simply and any development work to make that change is minimal, one question remains to be answered:  “What is the impact of this change?”

This is critical, and often overlooked in many models for estimation.  If testing is to be some percentage of development effort, for example 30 percent, and development work takes one hour, can testing really be finished in 20 minutes?  What part of the system is being touched?  How does that impact other areas? 

What about logical flows within the application, do we know what passes through them?  The importance of these questions came clear to me in ways I had not appreciated a few years ago.

The system being modified allowed customers to register on a retail website and order products. 

Language options were available so customers could receive emails and other communication in their preferred language.  The change was simple: allow customers to select from a new group of languages so the need for these communication templates could be really measured.  They would be created, but until the new languages were ready customers would get information in English along with a message saying their language preference was not completely ready and a message when it would be.

This seemed straight forward.  A slow roll-out meant that the marketing staff had time to finish their translation work and make sure it was correct, then roll each piece out as it was ready. 

Development time, including required documentation, was 90 minutes.  When I examined what was being changed and the areas that were potentially being impacted, I got nervous.  I looked for documentation on that logical flow and found none.  When I asked others about it, the response was there was none because “it was so well understood.” 

When I began looking at the logical flows that touched this seemingly simple change, I ended up with over 300 scenarios that potentially needed exercising.

By using a mind map as a decision tree, I was able to track impact areas for this change.  I also was able to find logical paths to focus on and eliminate others that were effectively within the same variable set as other paths.

From that project on, I looked to mind maps to help visually model logical flows, particularly when people believe them to be well understood.  This project changed my thinking in many ways and forced me to reconsider much of what I believed about requirements and impact to systems.

By looking at “what is touched by the change”, as opposed to “what does the change touch” the full scope of the project was made clear.  I now try to apply the same concept in each project I work on, where it is appropriate.  By taking this approach, the test team found 14 critical bugs in 38 hours of testing these logical paths.

Mind Maps for Test Planning and Reporting
It is these logical paths that proved interesting at the time, and they are why I now use this approach for test planning.  By identifying what possible relationships exist and what paths are available to get to them, I can model behavior without exercising the application itself.  This gives me the chance to talk with product owners, subject matter experts and designers to see if my understanding is correct and to get their input on the likelihood of these paths being followed. 

Once I have possible paths identified, I can then map what functions are available for testing right then. 

When working in iterations, in an Agile model, I can apply this idea to what is being worked on in that sprint, what was delivered in previous sprints and relationships between them. 

I can also see if I missed any possible paths in testing by comparing the test reports with the map showing possible paths.  With each iteration or delivery cycle we can add pieces to the mind map as they become available. 

By examining what areas of the application can be tested and what possible paths exist that may touch these areas, the nature of testing expands with each code delivery.  Sprint planning meetings, or the project plan depending on the project environment, give me an idea when certain functions will be made available.  From this I can see what is expected to be impacted based on what logical paths, which were identified earlier, may open up in the current iteration.

Within the mind map I can add the location in the project SharePoint or wiki where the test reports are saved.  For me, these are not simply tagged lists of steps to be done, expected results and actual results.  Instead they are more in the line of Session Reports from SBTM.  The purpose of why the testing is being done is described, who is doing the testing, what environment they are working in and information around what test data they are using is recorded. 

Other things are recorded as well, including what they did: 

• what was clicked on;
• what was entered;
• how they navigated from point A to point C; 
• messages displayed on the screen;
• messages displayed in the logs for the system under test (SUT) as well as source systems the SUT may interact with;
• test user accounts or other data used in testing that may have been changed or updated;
• records added and deleted;
• their results for each action and what they expected the results to be if they were not in alignment
• how long it took to execute the tests described;
• any outside factors that may have influenced the time it took to execute the tests;
• ​the testers’ general satisfaction with the tests and how the SUT behaved.

By keeping the mind map openly available, anyone with an interest in the project can look and see at any time what testing has been done, what is currently in progress and what is left to be tested.  By associating the test reports in the mind map I can give full access to anyone viewing the mind map what the testers did and saw.  (My current client’s tool does not allow embedding hyperlinks in mind maps.  I give the full, explicit link so people can copy and paste it directly into their browser and get the test report they are interested in.)

This can help Subject Matter Experts weigh in and ask questions about the testing and note potential flaws in a report, either what was done, how it was done or what the results were.   

The Underlying Purpose of this Model
This reflects on the question of "How does the software behave?" 

Usually, I'm not testing to validate requirements.  I find that documented requirements are one part of the puzzle to suitability for purpose.  By comparing documented requirements with the actual behavior of the software, I can report the behavior more fully and relate what I and the test team are observing with expectations for the software, one part of which consists of documented requirements.

In the end, I have a full visual representation of what has been exercised, how it has been exercised and how thoroughly.  This gives me something I can present to stakeholders and describe what we tested how it was tested, and what our findings were.  This gives me the chance to describe any variations encountered and ask them if they see this as a problem.  This sets up the question of “Are you comfortable with this or would you be more comfortable with more testing?"

Rather than talking about tests and test cases and what has been run and not run, which I've found is of really little value to most people, I talk about the business processes we have exercised. I talk about the depth to which we exercised them. 

When a reference is needed, I find mind maps give me a useful tool to present abstract ideas clearly to people with an interest in the software.

​In the many years since I worked on this project, I still find the examples hold up. I have been able to adapt some, and sometimes all, of these techniques to meet the needs of the project and team I am working with. While no single approach works everywhere for every project, I find this to be a versatile tool that can be readily adapted as needed.