What is Test Plan?
In software testing industry, a test plan refers to a document with the information related to the coming test activities conducted in a project. Team members and stakeholders can follow the plan for the best preparation before the project and for the status during their project. In general, a test plan may include testing approach, the scope of tests, required resources, and the estimated schedule of all the activities in a testing project.
It normally identifies the details such as test items, which specific features to be tested, list of tasks, allocated personnel for each of task, required test environment, which technique to be applied, which criteria for entry and exit, any forecasted risks to be managed, so on.
Test Plan is considered the very first step and among the most essential parts of a testing project as it helps things run smoothly and meet the project expectation. Test Plan needs to be flexible and up to date, depending on the real situation and status of the project.
Why Test Plan?
- A solid test plan provides details so that testing team can get ready for the coming stages, in term of effort and resources.
- Test plan is a kind of communication. It keeps the team and stakeholders updated on the strategy and status of the testing project.
- Better risk management as those risks could be estimated and controlled at the early stage.
- Important items are stored in the document, which can be utilized for later projects.
What is inside a Test Plan?
The Software Test Plan Template is various for different projects. However, it normally includes some basic parts below (as suggested by IEEE standard):
1. Test Plan Identifier
Just like other software documentation, test plan is also flexible and must be updated along the way. Testing manager will need to generate some numbers to identify the plan. The identifier also contains the information of the author and the revision history.
2. References
This section contains all the materials supporting this plan. They could be the high-level design document, detailed design document, project plan, requirements specifications, development & test process standards, testing method guidelines, organization guideline, and standards.
3. Introduction
This part can be considered the executive summary of the plan. This section will introduce the goal and level of the plan. It also includes the scope of the plan, resources, budget, and testing effort, the process for change control, and communication in general.
4. Test functions (items)
This section contains something we will test within the scope of the plan. It may be developed from the app inventories and other resources. The information may include version numbers, configuration requirements, key delivery schedule issues for critical issues.
5. Software Risk Issues
You need to identify the software to be tested and forecast some critical risks that may occur such as third party, new.
6. Features to be tested
List out which functions should be tested from users’ point of view. Also, set the risk level for each feature: High, Medium, Low.
7. Features not to be tested
List out which functions not to be tested, from both the system and users’ viewpoint. Remember to state the reasons for not testing, probably:
- Not included in this release
- Included in this release but not documented as a functional part of the release.
- Low risk, considered stable
8. Strategy (Approach)
State the general testing approach for your project. It should include the level of the plan, rules, and processes, testing tools, metrics, configuration management, hardware, software, level of regression testing, so on.
9. Pass/Fail criteria
Specify the criteria to determine either a test item passes or fails at both unit test level and master test plan level.
10. Suspension Criteria and Resumption Requirements
Identify the criteria for pausing the testing activities. Also, specify which activities to be resumed.
11. Test Deliverables
Contains the items to be delivered: Test plan document, Test Cases, Test design specification, Tools & the outputs, Error, and execution logs, Test reports.
12. Remaining Test Tasks
This section includes the parts of the plan does not address. These should be identified to make sure there is no confusion in the future. It will also help testers and users avoid incomplete functions and prevent waste of resources.
13. Test Environment
List out some requirements related to the test environment such as hardware (simulators, static generators), power requirements, supporting software, and restricted use of the system.
14. Staffing and Training Needs
Identify the staffs needed for the project, including both roles and required skills. It may also state the training if necessary.
15. Responsibilities
List out the specific responsibilities for each team member or role of the project
16. Schedule
Provide the estimated timeline of the plan, specify the key milestones of the projects. The more details provided, the more effective your team can be.
17. Risk management
Identify the risks that may occur during the testing, then manage to reduce and resolve the issues.
18. Approvals
Provide the information about the people who will take the responsibility to approve the plan.
Read more: Software Testing Types | The most common types