Visual Test Models

by | Syndicated

A picture saves a 1000 words!

Or in the case of testing… Saves a 30 page word document (test plan) capable of putting even the most dedicated project manager to sleep! Many times I spent hours writing a document at the request of the project team, only to realise that no-one ever reads it. If I had a dollar for all the times I’ve groaned “Its written in the document I sent you”…

So lately I’ve been studying the power of effective communication and how it can help my Testing 

Though everyone is different, the way people absorb information can be broken down into 4 basic types

  1. See it (visual)
  2. Hear it (auditory)
  3. Read it (internal dialogue)
  4. Experience it (kinesthetic)

We each absorb information by all of these methods but everyone has a preference which helps them retain and process more information. The good news is 80% of people have a preference for either visual or audio… So when using a combination of talking through a visual representation / diagram you’ll get through to most people in a group. 

So how has studying communication styles helped my Testing? 

Now I understand my preference, I realise the way I prefer to communicate doesn’t work for most people. I had to adjust my style and find a better way to get information across. This fits perfectly with the recent revival of the mind map for planning testing. I’m not a visual person at all, yet I find mindmaps so easy to understand. They work for most people as they combine words and logic with a visual representation. If you then talk people through it, you’ve covered nearly all bases. So over the last few months I’ve been using Visual Test Models to great effect.

What is a Visual Test Model?

It’s a way of capturing, planning and presenting Test Coverage using diagrams. We mainly use mindmaps but also supplement with flow / basic architecture diagrams where required. Some projects then embed this map into an excel workbook with the other tabs including the Risk Log, estimates and high level test scenarios (which we call a Visual Test Strategy). 

On a Visual Test Model we show 

  • Test Coverage (both in and out of scope)
  • Priority / areas of high risk 
  • Knowledge gaps (where we don’t have enough information to determine what / how to test)
  • Automation opportunity or existing coverage of automation

This sounds like a lot of information but the beauty of a good mindmap tool is the ability to use markers / colours and a legend to display this information clearly and easily. See here for an example. As I work for a bank I can’t show an actual example, so this is a made up one to give you an idea. (By no means do I claim it to be complete, this took 15 minutes to create)

How do we create a Visual Test Model?

Here lies the real differentiator. Yes, using VTM to capture and present information is proving very successful… But that only holds true if we are creating valuable, accurate and sufficient information. 

To give ourselves the best chance of achieving this I refer to what has become a central theme of most of my posts… Communication, collaboration and brainstorming!! Without fail, the most comprehensive Visual Test Models are coming out of these team analysis sessions. 

We find these sessions even more productive when they are facilitated by someone neutral. The facilitator captures the information (usually scribbled on a white board) and throughout performs the following:

  1. Questions the team on the information (How specifically do you test that feature? How do you create your test data for this? Could you automate these comparisons? Do you have access to that Message Queue? Who owns that server and do you let them know you require it for testing? Etc) 
  2. Asks the team to check and verify the information is being captured correctly on the mindmap. 
  3. Listens and picks up when the team say things which contradict each other and show lack of common understanding. Ask questions to clarify and ensure common understanding in the team

All the while, the facilitator is capturing the results of the discussion and using markers to highlight questions, risks and opportunities. 

How to structure a Visual Test Model
We base our VTM on James Bach’s SFDIPOT heuristic, but even with this guide, some teams struggle with how to structure the map and base it purely on screen flow. This may suit some projects but I encourage my teams to go deeper and map functions within the system using some knowledge of how the code is structured. E.g a search function found on 3 different screens may be using the same underlying code. Search would only need to appear on the system map once, with a reference to the various screens which call it. If a change happens to Search code you can more easily see which screens are affected, but it also reminds us it may be acceptable to only test it in depth once, instead of 3 times. The test team may not have this knowledge yet, so create the basic VTM and then invite the Development team to help refine it based on their knowledge of the code.

What do we use Visual Test Models for?

We started to use these models as a way of capturing the knowledge from a planning session, but they are proving to have so many uses! Let me list the ones I know of right now…

  1. Understand potential test coverage. Often test coverage is based on a Requirements Document. Of course its a valuable document, but to do efficient testing we need to consider more than just the functionality. Bringing the architectural and code structure plus functionality and data into one diagram allows us to consider these elements together and determine a more efficient test approach (e.g. One project ‘thoroughly’ tested each account type for each release, taking 4 man days of effort. The exercise of creating this map allowed them to understand (and confirm with the developer) that the underlying code was the same. Therefore performing deep testing of one product type, plus testing only the data nuances of the others was a sufficient test for most releases and reduced the test effort by half
  2. To clarify scope and priority. Once we map out the system we can use the VTM as a visual aid to discuss and agree with the project team what is in and out of scope for testing. We can also map and agree priorities at this stage
  3. To agree/ negotiate estimates/ schedule. Use of a Visual Test Model for one project resulted in an increase in planned test effort from 2 weeks to 6 months! (its not always about quicker testing). Having seen the impact to the system visually mapped out, the project team understood they were not prepared to take the risk of cutting testing. Even if the project team don’t increase the schedule, at least we were transparent with our assessment of the risk. Which gives me confidence that the project team made an informed decision
  4. Identify opportunities for
    automation.     Our automation experts can quickly get an overview of the system and technology . They scan the VTM and propose solutions to aid the manual testing. i.e. “I see you have XML messages, do you test them? Did you know we have a tool which can interrogate/ compare XML?” We also use colours in the map to show where automated checks are already available
  5. Identify knowledge gaps. We conduct a walkthrough of the VTM with the Developer $ BA to ensure we have understood the system correctly. We create VTM’s in my training course and I can now very easily see where there is a misunderstanding or gap in knowledge of the structure or the team have missed a connection between 2 features. I can more easily spot what is missing when looking at this map than by reading through reams of scripts. 
  6. An alternative to a test script. Some of our teams use their VTM as charters for Exploratory Testing. It contains sufficient information to guide the testers without the need to then recreate the information in a more traditional test document. 
  7. Report test progress. We tend to only use this method when testing small releases, but by using ‘markers’ on your mind map you can show your test progress
  8. Work allocation. With clearer understanding of the relationship between features, we are able to allocate work more logically amongst the team. This allows our testers to be more focused on testing related areas, rather than jumping around the system
  9. Impact analysis. Once the initial VTM has been created, its very quick and easy to understand the impact of future releases and more easily determine an appropriate regression effort (we are about to apply this to a project which has a regression pack of over 3,000 test cases… and growing)


How long does it take to create a Visual Test Model

That of course depends upon the context of your project. For an averagely complex investment banking system we spent 3x 2 hour sessions to create the Visual Test Model. Of course its a living document so will continually evolve with your system. To perform impact analysis of a new release on the same VTM typically takes one 2 hour session.

The re-use we are getting from these Visual Test Models is still surprising me. They add so much value that I can’t imagine planning my testing without one. 

Please leave a comment if you are doing something similar, especially if you can add to my long list of uses above!