A test plan must contain data on three things; test coverage, test methods and test responsibilities. In an earlier article, What is a Test Plan in Software Testing? we explained what a test plan is and why it is essential to create one. This article lists contents for your test plans and offers a few good templates, with help on how to fill in each of the sections, with examples.
Contents of a Test Plan
A standard test plan must contain the following sections:
Introduction
This section must provide details about the document. It’s mainly kept to give the reader an idea of what will be covered in the test plan.
Scope of Testing
This section is important to include because it lists the overall areas included and excluded from testing. It provides an insight into the approved scope of work for the QA team and works as an excellent reference for reporting.
- Features to be tested – Include a list of all the functionality to be tested. Providing a reference to the requirement is always helpful as it’s useful in tracking back and gathering overall coverage information.
- Features not to be tested – Include a list of all the elements which will not be part of the Verification. Do be sure to include a reason for exclusion. Common scenarios like payment related testing, access limitation to the system, location constraints, and cases bound by the security protocol, all fall out of scope for QA team.
Testing Approach
The primary objective of a test plan is to communicate the testing approach/methods to the reader. This section must list the types and number of rounds of testing, the defect tracking process and list of tools to be used for the project.
Item pass/fail criteria
We all know the general rule that when the system matches the requirement, the test is considered a pass, but during testing conditions can arise when the testers aren’t sure whether to mark something as pass or fail. Identify such criteria and include them in the test plan. A common example of this would be if an event was unreproducible or concerned environmentally related defects.
Suspension criteria and resumption requirements
During the test execution, there may be instances when the testing needs to be suspended for a period. The test plan must explicitly mention the condition when test activity has to stop and when it can resume. A few examples to consider could be “Testing will be suspended when 40% or more of the defects are open,” or ” Testing will be suspended if blocked defects have not been fixed.”
Test deliverables
Test deliverables must give a list of all the documents planned for creation during the QA cycle. Along with it, mention the schedule and timeline for the production and submission of these documents.
For example:
| Document | Submission Time |
| Test Cases | Test Cases will be submitted during the test design phase. |
| Bug Report | Bug Report will be shared at the end of each day throughout the test execution cycle. |
| Test Summary Report | Report will be submitted at the end of testing. |
Testing tasks
This section must detail all the activities and tasks planned for execution during the overall testing phase. It must include everything, starting from test case creation through to defect retesting and the test closure report.
Responsibilities
List the roles and responsibilities of each team member, including the project managers. Apart from informing everyone about the members involved in the project, it serves as a resource for the respective points of contacts when a need arises.
| Name | Roles | |
| John | QA Manager | john@tester.com |
| Smith | Test Lead | smith@tester.com |
Resource Planning
Environmental needs vary, depending on the type of system under test. Similarly, the requirement for human resources also vary. The Test plan must list all required resources.
- System Resources – The test plan must list all hardware requirements. Be sure to include details about specific devices and versions needed.
- Staffing and training needs – List the required resources and all types of training needed for a smooth execution of the project, including the identified skills and resources needed for the training. The reason for including this information is to help with developing the training plan, and provide a better idea of the total time required and cost involved in training.
Schedule
Having a schedule is an essential part of any project success. A QA manager must schedule all QA activities, and note them in the test plan. The QA plan/timing needs to align with the overall project schedule. Schedules and timelines are dynamic and require frequent updating. It’s a good idea to keep the test schedule as a separate document, or in a tool, and provide a reference to the link in the Test Plan.
Risks and Contingencies
Risks need to be determined and documented at the start of the project. Just making a note of the risks is not enough, as an associated mitigation plan is required too. This section is concerned with providing details on action to take when a hazard occurs.
Refer below for some of the common risks and contingency plan
| Risk | Mitigation Plan |
| Lack of required skill within the team. | Onboard skilled team member or plan for on the job training. |
| Frequent requirement change and strict delivery timeline. | Onboard new resources or set priority and test only critical path. |
Finally
In closing, it’s worth stating that the creation of a test plan does not need to follow a particular format. What matters most is the intent and information provided in the document. Whichever style you choose, it is recommended that you keep the test plan concise, containing details that are specific and applicable to the project.
