How to write a software testing plan: from scope to schedule

Key points of this article

Determine the scope of the test plan first, and state the unexpected content. If the scope is unclear, subsequent strategies and progress will be biased.
The test strategy should clearly describe the test level, test type and passing criteria, and should be able to correspond to specific needs.
Resources and progress should be allocated to the person in charge, the test environment and specific dates, and time should be reserved for rework and waiting.
Use a Word template to unify the chapter structure, and then check items one by one according to the checklist. It is less likely to miss items than temporary drafting.

When many teams do testing, they have requirements documents and test cases in hand, but there is no plan that clearly states "what to test this round, how to test, who is responsible, and when it will end." Common results are that the test starts late, the scope keeps changing midway, and it is discovered before acceptance that the environment is not in place. The core of how to write a software test plan is to answer these questions on paper in advance.

This article is written for test engineers and project managers who are drafting a test plan for the first time, as well as for development leaders who need to review the plan. After reading, you will get a general chapter structure: what to write about scope, strategy, resources, and progress, and how to draft and check using Word templates. The test plan is the arrangement before starting work, and the test report is the conclusion after completion. The two should be written separately. This article only talks about the former.

How to write a software test plan? One sentence conclusion

There is no single standard for how to write a test plan, but the order is relatively stable: first determine the scope, then determine how to test, then allocate resources, and finally arrange the schedule. The table below gives common processing methods according to project conditions.

your situation	Recommended practices	reason
Small projects with stable needs and few functions	The plan is compressed into several pages, and the range directly refers to the requirement number.	There is little content, and if it is too long, no one will read it. Reference requirements can avoid repeated descriptions.
Multi-module parallelization and frequent changes in requirements	A single column in the scope is "How to update the plan after changes", and the testing phases are divided by iterations	The scope will change, and the plan must have an update mechanism, otherwise it will become invalid quickly.
Involving high-risk functions such as payment and privacy	Special tests are written separately in the strategy, and passing standards are written more specifically.	High-risk features require stricter acceptance criteria
Outsourcing or multi-party collaboration testing	In the resource section, clearly state the responsibilities of each party, environment provider and frequency of communication.	Unclear responsibilities are a common source of rework in multi-party collaborations
Maintenance projects that only do regression testing	The scope lists the list of regression modules, and the progress is only arranged in one or several rounds.	The focus of the maintenance period is the impact of the change, and does not require a complete full-volume plan.

Before you start: Confirm these points first

Before you start writing, think clearly about the following items. They will determine how detailed each subsequent section will be.

Test object and version: Indicate the system under test, version number and corresponding requirements document version. Without a version number, test conclusions cannot be traced back to a specific build.
Testing Objective: Is it for acceptance before release, to troubleshoot certain types of defects, or to verify performance. The goals are different, and the strategies and passing criteria vary greatly.
Available time and personnel: Ask about the testing window and manpower first, and then schedule the progress. If you arrange the schedule first and find people later, the plan is often not feasible from the beginning.
Test environment conditions: Whether the server, test data, and third-party interfaces can be provided. Environment preparation often takes more time than the test itself, so it must be marked in advance in the plan.
Existing documents: requirement specifications, design descriptions, historical defect records. They are the primary basis for scope and risk judgments, do not write based on impressions.

Steps to draft a test plan using a Word template

The following practices will work with any Word template. You can first use the existing template of the team. If not, build your own according to the following structure. OmniDoc's UniDoc web editor supports Word-compatible editing and can also be used to open and modify .docx files.

Establish a title structure. Use first-level headings to list "1 Introduction, 2 Test Scope, 3 Test Strategy, 4 Resources, 5 Schedule, 6 Risks, 7 Appendix", and reserve subheadings under each section to facilitate section-by-section comparison during review.
Write the background, test objectives and audience in the "Introduction". In two or three sentences, explain why you are doing this round of testing and who you plan to target it with.
List the included functional modules and untested content in the "Test Scope". Exclusions must also be written and explained, for example, "The third-party payment page is the responsibility of the other party, and only the callback interface will be tested this round."
Write the test level (unit, integration, system, acceptance), test type (functional, performance, security, compatibility), and the start and end conditions of each type of test in the "Test Strategy".
Write down the passing criteria, for example, "All serious level defects will be closed, and the remaining number of general level defects will be confirmed by the review meeting." The standard must be able to judge yes or no, and cannot just say "good quality".
List the personnel roles, test environment, test tools and data preparation in "Resources", and indicate the person responsible and the time of arrival for each item.
Schedule by stage in the "Schedule": plan review, use case writing, environment readiness, execution, regression, reporting. Write the start and end dates and corresponding milestones for each stage.
List three to five factors that may affect the schedule in "Risks", such as demand changes, environmental delays, and personnel vacancies, and assign a response to each.

Check each item after completion

After writing the plan, don’t rush to send it to reviewers. First, check item by item according to the table below. Most omissions can be discovered at this step.

Check items	How to see	What to do if there is a problem
Scope corresponds to needs	Can each test module find the corresponding requirement number?	Modules that cannot be found can either supplement requirements or be removed from the scope
Whether the exclusion item is clearly stated	Can readers see what is unexpected this time?	Fill in the exclusion items and reasons, and ask the demand side to confirm
Whether it can be judged by the standard	Can each standard answer "met or not met"	Replace an adjective with a countable or observable condition
Is there a person in charge of the resources?	Are the responsible persons written in the environment, data and tools?	Unclaimed resources should be implemented before the review.
Is there a buffer in progress?	Is there any rework and waiting time between phases?	Synchronously adjust the commitment of subsequent nodes when compressing the pre-order
Is there a response to the risk?	Each risk has a corresponding action and responsible person.	The risk that there is no solution is rewritten into an enforceable measure.

During the review, it is recommended that the development, product and testing parties each read through and find the missing items from their own point of view. After the three parties agree, the version number and date will be written into the plan as the basis for subsequent changes.

# frequently asked questions (FAQ)

1. What is the difference between a test plan and a test report?

The test plan is the arrangement written before the start, answering what to test, how to test, and when to finish; the test report is the conclusion written after the test, and the answer is what has been tested and what is the result. The readers and timing of the two are different, so don't write the results of the execution into the plan.

2. How long will the test plan be written?

There is no fixed number of pages. It allows the reviewer to judge the scope, strategy and progress, a few pages of small projects are enough, and complex projects can put details in the appendix and keep the text short.

3. How often is the test plan updated?

Should be updated when requirements change, schedule adjustment, or environmental conditions change, and record the version number and the reason for the change. The old version is retained for easy traceability.

4. Without a template, how can you tell if you have written enough?

Ask yourself item by item against the previous checklist: this energy saving cannot be understood and implemented by a person who has not been involved in the project. Yes, it's basically enough.

# Summary

The key to how to write a software test plan is to first clarify the scope and exclusions, and then use strategy, resources, and schedule to bring the plan to an executable level. Using Word template to unify the structure and checking item by item according to the checklist can reduce most of the omissions.

Open OmniDoc to edit and export documents online