When you think of a test plan, you certainly know test plans that describe in detail all possible aspects of a testing project on a lot of pages. Maybe you already had the task to write such an extensive document or to contribute to its elaboration. However, did you not find that, after having completed this detailed test plan, it was hardly ever read seriously again – perhaps not even by yourself?

I will present you another kind of test plans that contains every relevant aspect of managing your testing project on just one page (cf. Fig. 1). The idea is to have a single-page, well-arranged, concise and clear document at your hands that you like to consult, share and take as a basis for discussions with other stakeholders in the test project. This concise planning document will actually guide you in all relevant areas of managing your testing activities. You can easily distribute it or attach it wherever you want in printed or digital form. As James Whittaker said: “We know full well that we are not going to test everything so why document everything?” (cf. reference at the end).

Some relevant areas for the one-page test plan

You may want to consider the following topics in your one-page test plan, for example:

• Introduction/Context/Goals: Describe the context of your testing activities, the product, or the main goals of your test project.
• Strategy: Which test strategy will primarily be applied?
• In scope: It is of uttermost importance to be clear about the scope of your testing, so that you can easily and efficiently focus on these areas.
• Out of scope: It is equally important to define which aspects are not to be considered in your testing project. By doing so, you avoid wasting time and resources, and you can be sure to achieve the set goals. You could for instance exclude certain aspects of non-functional testing, such as portability or reliability, when they are not part of your test mission.
• Project risks: Any major risk that could harm your project should be taken into account here, e.g. the sudden absence of project team members, time delay, cost overrun, etc. Instead of a list of risks specified directly in this area, you could also just place a link to your more detailed risk management or risk matrix.
• Product risks: If a risk may not affect your project, but the product itself, for example by diminishing its intended quality, then it is called a product risk. Further examples are poor usability, insufficient functions, or inadequate scalability.
• Conditions/Requirements: In this section, you can mention relevant conditions that need to be fulfilled in order to achieve your project objectives. You could for instance list specific entry conditions to be met in order to launch the actual test phase or exit conditions for stopping the testing activities.
• Resources/People: If you need to rely on specific resources, list them in this area.
• Schedule/Time frame/Timescales: You can specify the milestones of your project and the relevant time frame here, without going into details. You may want to refer to a more detailed project schedule.
• Communication/Interaction: In software testing, an appropriate and timely communication with all stakeholders is of key importance, in order to make your testing project a success. You could describe the acceptance process with business representatives, the defect management, reporting, and so on.
• Environment: Specify the key parts of the environment needed to accomplish the testing tasks or to achieve your aims, e.g. the system under test, the generation of test data, the handling of sensitive data, the access management, etc.
• Tools: In this area, you can list the essential tools that you use in the central processes of your test project.
• Assumptions/Estimates: Anything relevant to your project you can just assume to occur at the time of creating your test can be mentioned in this section.
• Links: In case you would like to refer to other important pages or documents whose content you cannot integrate into a specific area in a concise manner, then briefly list the links to these resources here (e.g. risk matrix, design documents, architecture, list of test cases, etc.). Check if your audience has access to the linked resources, if necessary. On the whole, the one-page test plan should stand on its own, and not contain too many links to other information.
• Open points: At the time of initial development, it may well be that not all issues are already addressed in a sufficient manner. Therefore, you could mention substantial questions to be clarified in the near future.
• Contact information: Include contact details in case people are looking for more information and details about your test project.

Once your test plan is tailored to your intended audience, you will be able to decide about its most relevant content and appropriate language. When we integrate some of the above-mentioned topics into a very high-level, fictional one-page test plan, it may then look as follows:

Wording tips

Try to use short sentences, not whole paragraphs, or lists to describe relevant content. According to James Whittaker it is useful to concentrate on:

• Attributes: “adverbs and adjectives that describe the high level concepts testing is meant to ensure”(fast, secure, usable, etc.)
• Components: “nouns that define the major code chunks that comprise the product” (classes, module names, and features of the application)
• Capabilities: “verbs that describe user actions and activities” – very important!

These core aspects of writing a concise document do not only refer to the application or test object, but to the style and language of your test plan in general.

Design aspects

Of course, you are free to arrange the collected topics in any order and form you like and find most appropriate to your needs. It often seems that the form of a table or matrix is expedient, as it facilitates the orientation when reading your test plan, and clearly separates the individual sections.

You could combine related areas into one area in order to limit the total number of fields. Try to focus on the really relevant topics for your test management, so that you do not overwhelm your target audience with too much information. According to the relevance of each area you can put more emphasis on certain topics if your desired form of presentation allows for doing so.

Do not use a tiny font, in order to include as much information as possible in your single-page test plan. Better concentrate on highly relevant aspects and have the courage to leave gaps.

You can colour the areas as you like to get the desired overall visual impression.

The result of teamwork

Depending on your project conditions, the test manager may work out this test plan on his own – provided that he has all information needed at his disposal. However, a document of such a crucial importance will usually be the result of close teamwork. I recommend you to have the one-page test plan developed by a core team of stakeholders who can contribute to the main topics. You can for instance organise a workshop during which small groups determine which areas are to be taken into account. Once the collected ideas have been discussed in a plenary meeting, a draft will be elaborated, possibly again in small groups – either as a whole test plan or by distributing some topics to each group for further development. In a concluding session, a general version will be established.

During project term, relevant changes should be reflected by the one-page test plan. Generally, you will probably not often have reason to modify this concise steering document.

Benefits

By developing a one-page test plan, you have to focus on aspects which are most relevant to a project in software testing and to limit the information you would like to include in this central document. One of the main goals of using a test plan like this is to have it actually read by the target audience, and not let it be disregarded in any dark corner. Hence, no resources and time will be wasted on writing documents that will not be read by the major part of its intended recipients. Thus, you will be able to focus more intently on the progress of your testing project, so that you will reach your objectives.

Conclusion

If your test project is managed by a slim one-page test plan, this allows you to rapidly and effectively adjust it to a fast-moving software project. Thus, it will be a useful guide in all possible situations during the duration of the whole project. The next time you have to set up a plan for your test management, think about the many advantages of using a one-page test plan. People will actually consult your test plan, so your testing objectives will likely be accomplished to a higher degree. Designing this concise document will leave plenty of room for your creativity. When you gain positive experience by applying the one-page test plan, spread the word in your organisation. That way, the management of testing projects will largely benefit from your expertise, and hence the quality assurance as a whole.

Further resources

You will discover numerous tips for designing your one-page test plan in the blog “The One Page Test Plan” by Claire Reckless on Ministry of Testing. Watch also the short, inspiring video “On Test Plans” by Ilari Henrik Aegerter (CEO of House of Test). A blog worth reading has been written by James Whittaker: “The 10 Minute Test Plan”, more strongly emphasising the creation of a handy test plan in a really short time.

Should you have any questions concerning test management, agile testing, DevOps, test automation, integration of testing tools, or Atlassian products, we are happy to assist you. Please feel free to contact us.