by Claire Reckless
Search for 'How to write a test plan' on the internet and there are all sorts of templates, 'must haves', tutorials and lots more. When it comes to creating test plans, there are so many ways to do it, and so many things to consider, it's easy to end up more confused than you were before. People end up putting certain information in 'just to be on the safe side', as it seems better to include it than not. It might be important to someone, right? Once it's written, reviewed, edited, finalised, and distributed to all the relevant stakeholders, it's quite common to find out later than almost no-one has actually read it.
Spending ages creating lengthy test documentation that no one ends up reading or using, can be incredibly frustrating. One problem is that management doesn't always have time to read a huge document, they want to know the most important things.
James Whittaker wrote about the 10 Minute Test Plan a few years ago, describing the challenge he set for his team. The aim there was to get to the value of a test plan, if there were any, as quickly as possible. Let's try and look at it from a different perspective, but with a similar aim. This time, the challenge isn't time, it's space. We're going to think about how we can reduce a test plan to one page.
Why Write A Test Plan Anyway?
We can write any document to record or communicate information, in this case, the information we want to communicate is about how we plan to test a software product. We can do this in a variety of different ways. After reading the test plan we want the reader to have more knowledge and hopefully, a greater understanding of the product under test, how the testing will be conducted for a feature or a release, any risks, and other information that might be helpful.
A test plan may also be used as a 'shield' of sorts. If something goes wrong, it could be necessary to refer back to the test plan document, to find missed scope, lack of test coverage, or to see what the agreed scope of testing was. In a regulated or very controlled environment it could be a mandatory part of the testing cycle, a legal requirement even, or a deliverable of the project.
You might not write a test plan with the intention of communicating it to others. Writing down what you plan to do can assist you in organising your thoughts. When you see something presented in front of you, it can help you learn, or understand what is missing from the plan. Take a mindmap for instance, the visual representation is an intuitive way to link and group concepts together through association and reflects the non linear way the brain generates ideas. The use of imagery enhances creative thinking and memory and can prompt you to fill in more detail and see where there are gaps in your plan. Maaret recently shared some great information on exploratory testing self management and how you can also use notes to plan and manage your testing, including information about your testing mission, as well as any charters you are going to use to guide you.
It's possible your project doesn't require a test plan. An organization could communicate information about testing activities differently, maybe it doesn't produce any documentation at all. Don't create it if it's not necessary, just because a process or template says you should. Writing lengthy reports that aren't useful to the testers or anyone else is a poor use of time. Writing documentation is also expensive, so documentation which goes unused could be seen as a waste of money. Lacking a written test plan doesn't mean a plan does not exist. Sometimes test plans could be very simple mission statements or mind maps with workflows. Do what suits the business needs best.
The Agile Manifesto states: "Working software over comprehensive documentation." As a result of adopting an agile way of working, a lot of organisations have reduced the amount of documentation produced as part of a development project. Understanding the value a test plan could add is important. Sometimes it's necessary and often the least complicated way to communicate testing efforts outside of the development organisation.
Why a One Page Test Plan Might Work For You
Present a very busy manager with a document spanning many pages, packed with information, which might require an hour or more to read and they may never get time to look at it. Present them with a short document where they can get a view of the testing planned for a project and they might be more likely to take a look.
Still on the subject of time, a side effect of one page of information is that it will probably (not always) take less time to produce than something longer. This gives you more time to devote to other testing related activities.
Limited space means you can only fit so much in your test plan. This will make you consider what the most important information you want to include really is and what will add the most value. You won't be able to add in unnecessary detail that the reader is unlikely to care about. If you usually write longer test plan documents and want to try a one page version, speak to the people who will read it and gather information about what they absolutely require. If you still end up with a long list, choose the top two or three items to help build your plan and fit more in if you can. Alternatively, look at how different formats can help you fit in the information you need.
It's also vital you know when one page just won't work for the project. If there are things you absolutely must include for business reasons then do so. If your test plan needs to include a list of all the tests you will run, find ways to save page space by using links to other documents or applications the project uses for test case management. The goal is about summarizing testing efforts. If stakeholders want more information, providing links to other documents inside of the test plan can do that without a lot of wasted space and clutter.
Even if a one page plan is totally unrealistic, it can be a great way to take a fresh look at the test plans you do produce and question if there are things you could do differently to get the most value out of them.
Ideas For Your Test Plan Presentation
If you have a small space in which you need to fit all your information, you might have to be creative with how you present it. You can follow a template if you find one that works for you, just make sure all the sections in it are necessary and relevant to your project. You want to avoid spending time writing something just because a template says you should. Consider whether the following formats might work for you:
A Word document
A trusty classic. Lisa Crispin and Janet Gregory have a nice one page test plan example in their book 'Agile Testing'. In summary, the plan contains information about what is in scope, out of scope, resourcing, features, performance and load testing, UAT, infrastructure, assumptions and risks. You can change / amend these for the relevant areas in your project. There are only 2-3 lines under each section, just enough to give an overview of what will be done.
Dashboard format
Presenting information like this can be a good way of giving the reader an at-a-glance view of the test plan in a nice visual way. Use colours and styles to draw the reader's eye to each of the different areas. Mike Talks (@TestSheepNZ), developed his own test plan dashboard for testing individual features. This Usability Test Plan dashboard is also a great starting point.
Mind maps
Another great visual way to create your test plan and you needn't be confined to an A4 page. Create a node for each area of your test plan and go from there. Whilst it's tempting to run wild creating lots of nodes, be mindful that too many could affect the readability. There's a great example here from Elizabeth's article, If you are creating a plan which includes lists of tests to be carried out this approach might also work for you. You could even use a mind map as a precursor to a written plan to help you sketch out the content. Try XMind, Mindmup, MindMeister or Coggle.it if you are looking for mind mapping tools.
Excel (or a Spreadsheet of Your Preference)
If you don't have a test management tool and you want your test plan to contain the list of tests or scenarios you plan to run you can use spreadsheets and make use of pivot tables to display the information you want.
Wiki page
Create a page for your test plan and add links for different sections. This can help make creating reusable test plan content much easier. This method could also work as a collaborative approach if you require input from different team members.
A Whiteboard
Does this still fall into the 'One Page' category? I think so. If your plan will only be used by the immediate team this might be sufficient to communicate it, no need to create a formal document at all! Using a whiteboard is one of the simplest ways you can create a test plan and is also quick and cost effective to update if necessary. You can take a photo of it for reference for when you aren't in the immediate vicinity, or if there is a risk someone might remove it.
Trello board
This is a great online project management tool which enables you to create boards containing all the tasks you need to complete, as well as columns for each status the task will have. You might use something similar to manage your agile projects. Create a board for the project or feature under test and a card for each item in the test plan. You can add due dates for each item and as much detail as you need, links to external resources, as well as comments. Assign them out to people and move them across the board as they are in progress then completed.
However you present your plan, think about what will be of the most use to you, your team and whoever you are writing for.
Choosing Topics To Cover
Organise your one page test plan document with only the most important content the reader would need to know. The following might help you get started:
- The Product / Feature under test
- What is In Scope / Out of Scope
- Risks
- Assumptions
- Tools
- Environments
- Resources
- Estimates
For everything you decide to add to your document, ask yourself, 'Does the reader need to know this?', 'Is this information that matters?'. In addition, as mentioned previously, ask the reader! What do they want to know from the plan? Don't fall into the trap of including something because that's what's always been done.
If you can't fit something in, think if you can add a link to an external document or resource which will provide that information, such as :
- Test management tool
- Test charters
- Design documents
- Risk register
- List of assumptions
- Gantt chart showing timelines / resourcing
- Links to research / prototypes
- UAT documentation
- Infrastructure documentation
- Related test plans for specific types of testing, for example Performance and Security
Make It Easy To Read
Knowing who the audience will be and what they will use a test plan for will help you ascertain what the most high priority things are to include. Different people will use the plan in different ways.
- The Test Team or Test Manager - they might use it as a starting point for creating test charters, to work out what environments to create, and where to allocate resources.
- Wider business - the plan may feed into other departments like Marketing, who might use schedules to coordinate a new campaign. It could be used by Customer Support or your DevOps team to help prepare for the release.
- Upper management - they might not want the granularity of a list of all the tests which will be performed. An overview of what will be done, an idea of what the risks are and when testing is planned to start and finish may help them see whether development is on track with their product roadmap.
- Regulatory body - they will want to know your testing complies with certain standards or legislation.
- Customer(s) or client(s) - You might be required to communicate the test plan as part of a contractual agreement.
When communicating with customer(s) or client(s), you may want to generalise more or simplify technical language used if they don't understand technical terms. Address any concerns they might have about testing with the documentation. Including context or even contact information might be necessary so the customer(s) or client(s) have the means of getting more information or clarification directly from the source.
Be aware that the customer(s) or client(s) might not have access to internal tools or documentation. This could limit how much you can link to the test plan document. Obtaining special permission for read-only access or providing links to external facing documents might be necessary for external customers.
Sources / References
- Developsense - What should a test plan contain
- Ministry of Testing - The Software Testing Planning Checklist
- Google Testing Blog - The 10 Minute Test Plan
- Usability Focus - Usability Test Plan Dashboard
- Agile Testing - Lisa Crispin and Janet Gregory
- Theory behind Mind Maps
About Claire Reckless
Claire Reckless is a tester at Avecto, working on endpoint security software. Her passion is in helping people learn how to become better testers. Her domain expertise also includes financial and ERP software. Claire lives in Manchester, with her husband Rob, their cat, and dog. She also enjoys running as time allows. You can find Claire on her Twitter.
