This article was first written in 2016 by the brilliant Claire Reckless and has now been reviewed and updated by the equally brilliant Ady Stokes. Since software development and testing are constantly evolving, we decided it was time to give it some love and bring it bang up to date with current formatting, updated links and modern lightweight testing tips.
Have you ever searched for 'How to write a test plan' on the internet? You'll find 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.
Spending ages creating lengthy test documentation that no one ends up reading can be frustrating. One problem is that management doesn't always have time to read a huge document. They want to know what the most important things are.
James Whittaker once wrote about the 10 Minute Test Plan, describing the challenge he set for his team to get to the value of a test plan 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 just one page.
Why write a test plan anyway?
We can set out a simple set of objectives for our test plan. At the very least, we want the test plan to give its readers a greater understanding of:
- The product or system under test
- How the testing will be conducted for a feature or a release
- Risks and mitigation strategies
A test plan may also be used as a 'shield' of sorts. If something goes wrong, it can be helpful to review the test plan document for missed scope, lack of test coverage, or to see what the agreed scope of testing was. In a regulated or controlled environment, it could be a mandatory part of the testing cycle, a legal requirement, or a required deliverable of the project.
Do you really need to write a plan?
You might not even write a test plan to communicate it to others. Carefully designed images can be even more effective than the written word. Take a mind map, for example (search MoT for more on mind maps). 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 help you see where there are gaps in your plan. Maaret Pyhäjärvi shared some great information on exploratory testing self-management: how you can also use notes to plan and manage your testing, including information about your testing mission, as well as any charters that will guide your testing.
It's possible your project doesn't even require a test plan. Don't create a plan simply 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. Sometimes, a simple mission statement or mind maps with workflows will do just fine. 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, many organisations have reduced the amount of documentation produced as part of a development project. With that in mind, create a test plan only if it's necessary or if it truly is the least complicated way to communicate testing efforts outside of the development organisation.
Why a one-page test plan might work for you, and why it might not
Managerial time constraints: If you present a busy manager with a multipage document packed with information, it's likely they won't have time to review it. Instead, present them with a short document that gives a clear, concise view of the testing planned for a project. They'll thank you for saving them time, AND they might be more likely to take a look.
Quicker for you to write: A one-page test plan will probably (not always) take less time to produce than a longer one. This gives you more time to devote to other testing-related tasks and activities.
Tips for keeping it brief: Limited space means you can only fit so much in your test plan. This will force you to consider what you truly need to include and what can be left out. 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.
When one-pagers won't work: It's also vital to know when a one-page test plan 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 requires a list of all the tests you will run, consider saving page space by using links to other documents or applications that the project uses for test case management. The goal is to summarise testing efforts. If stakeholders want more information, providing links to other documents inside 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 already produce and question if there are things you could do differently. Is every section in the template required? How far down into detail do you need to go at this stage, or in this plan?
Ideas for presenting your test plan
You might have to get creative with how you present your one-pager. 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:
Documents (Word, Google, and so on)
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, what is out of scope, resourcing, features, performance and load testing, UAT, infrastructure, assumptions, and risks. You can change or amend these for the relevant areas in your project. There should only be two or three lines under each section, just enough to give an overview of what will be done.
Dashboard format
Presenting information this way gives the reader a birds-eye view of the test plan. Use colours and styles to draw the reader's eye to each of the different areas, ensuring good contrast. This format is also created with virtual whiteboard tools, like Miro.
Mike Talks developed his own test plan dashboard for testing individual features.
This Usability Test Plan dashboard is also a great starting point.
Mind maps
This is another great visual way to create your test plan on one page, and you don't need to 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 mind map created on MindMeister for a music app from Elizabeth Zagroba's article How to use mind maps to develop clarity with your software testing strategy. 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.
Spreadsheets
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 pages
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. It can also be more visible and easier to maintain than other options.
Old-school physical whiteboards
Source: Using Mind Maps for Test Planning
Does this still fall into the 'one-page' category? I think so. If your plan will be used only 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 when you're not in the immediate vicinity, or if there's a risk that someone might remove it.
Virtual whiteboards and kanban boards
Online project management tools enable 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.
Trello board
In Trello 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 to people and move them across the board as they are in progress, until they are complete.
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 essential content. The following list 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 intended readers: What do they want to know from the plan? Don't fall into the trap of including something just because that's what's always been done.
If you can't fit something in, perhaps you can add a link to an external document or resource, such as :
- Test management tool
- Test charters
- Design documents
- Risk register
- List of assumptions
- Gantt chart showing timelines and resourcing
- Links to research and 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 how they will use a test plan will help you ascertain what the highest priority things are to include. People in different roles 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.
- Business stakeholders: The plan may feed into other departments, like marketing, which 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 that 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.
Special concerns with giving test plans to customers and clients
When communicating with customers or clients:
- You may want to generalise more or simplify the technical language used if they don't understand technical terms.
- Address any concerns they might have about testing.
- You might want to include some contact information 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 what you can link to from within the test plan document. Obtaining special permission for read-only access or providing links to externally facing documents might be necessary for external customers.
What has changed in test documentation over the last decade?
Artificial intelligence (AI) has changed the game for test documentation
It is difficult to summarise any type of change in software development and testing without considering AI. This is also true whether you are looking to draft test cases, generate data, write exploratory testing charters, or create a test plan.
AI’s many tools will shout about how they can create fantastic plans in seconds with the right inputs or prompts. Drop in a list of requirements, and boom, a test plan appears. However, like anything automatically generated by AI, it requires human oversight, analysis, and thought to work out if what you really want and need has been accurately generated.
Yes, AI is consistent in structure and tone. It can be given templates that it will reproduce with perfect formatting. It doesn’t really matter if you use user stories, API documentation, feature outlines or any type of product language to inform it. It will transform any and all of them into test artefacts. There is value in using AI tools to generate test plan documentation, but use them wisely and don’t substitute expediency for quality.
From big up-front documentation (BUFD) to conversations about quality
There has been a gradual shift away from the lengthy test planning documents of the waterfall era, which often took months to write. Lighter, more accessible documents have gained momentum as the world of software development has (almost) caught up with the Agile revolution.
As software testers have become more involved in projects from the beginning of development, this has driven more conversations about quality, leading to more lightweight planning. The nature of modern software development makes the ability to adapt and respond to change vital, and the documentation created alongside development has had to evolve too.
Quality characteristics are less of an afterthought, which is a good thing
Not so long ago, security for software was the only area considered to be a risk. While it is a vital area, it is not the only one that needs thinking about. As excellent tooling has become more widely available, testing areas like APIs, monitoring and performance are brought into the conversation earlier. Earlier consideration generally leads to better quality outcomes.
Usability and accessibility are being talked about more too, but they still have a way to go to become a planned-for testing area. The European Accessibility Act, which comes into force in 2025, is already having some effect, but only time will tell how significant it will be.
To sum up
Test plans can be anything from post-it notes to visual boards to one-page documents. And yes, they can still take up large tomes of multiple pages or even (yes, I’ve seen this in real life) 70-plus-page PowerPoint templates. Only knowing the project and its context will inform what the right choice will be in a given scenario.
Whoever first said, ‘less is more,’ definitely had a point. Do ask questions such as, 'How much up-front and documented information do I need for this test plan to be valuable?' You may find that less is indeed more, and your team and testing will be more efficient using a smaller test plan, such as a one-page test plan. Happy planning.
Sources and references
- Ministry of Testing - The Software Testing Planning Checklist
- Google Testing Blog - The 10 Minute Test Plan
- The Agile Manifesto
- Usability Focus - Usability Test Plan Dashboard
- Agile Testing - Lisa Crispin and Janet Gregory
- Theory behind Mind Maps
- Empathy lessons for software testers: Preparing for the European Accessibility Act
