Test Plan: [Project or release name]

Complete project test plan. The section structure follows the test plan information item of ISO/IEC/IEEE 29119-3: context, communication, risk register, test strategy, activities and estimates, staffing and schedule. Replace every [bracketed] value and every row marked Example, and explain any removed section in 4.12 (deviations).

Document control

Approvals

Revision history

Contents

1. Context of the testing
2. Testing communication
3. Risk register
4. Test strategy
5. Testing activities and estimates
6. Staffing
7. Schedule
8. Glossary and references

1. Context of the testing

1.1 Projects and test sub-processes

This plan covers testing for [project name], delivering [one sentence on the business outcome] by YYYY-MM-DD. It is the [master / level] plan and covers these test sub-processes:

1.2 Test items

1.3 Test scope

• Features to be tested: [feature 1 with requirement IDs], [feature 2], [regression of existing checkout].
• Features not to be tested: [feature] because [reason, for example unchanged and covered by automated regression].
• Quality characteristics in scope: functional suitability, performance efficiency, security, usability, compatibility, [accessibility].

1.4 Assumptions and constraints

1.5 Stakeholders

2. Testing communication

Escalation path: tester -> test lead -> test manager -> project manager -> steering committee. Blockers older than [one working day] are escalated.

3. Risk register

Exposure is $E = L \times I$ on a 1-25 scale; 15 and above is high, 8-14 medium, below 8 low.

3.1 Product risks

3.2 Project risks

4. Test strategy

4.1 Test sub-processes

4.2 Test deliverables

4.3 Test design techniques

4.4 Test completion criteria

4.5 Metrics to be collected

Planned versus executed test cases, pass and fail counts, blocked tests, defects opened and closed per day by severity, requirements coverage, automated suite duration and flaky test count. Metrics feed the weekly status report and the completion report.

4.6 Test data requirements

4.7 Test environment requirements

4.8 Retesting and regression testing

Every resolved defect is retested in the build that contains the fix. The automated regression suite runs on every merge to the release branch; the full manual regression checklist runs once on the release candidate.

4.9 Suspension and resumption criteria

4.10 Independence and test levels not performed

[State the level of independence for each sub-process and justify any test level or type that the strategy would require but this plan omits.]

4.11 Entry criteria for the plan itself

The plan is approved, the test environment is booked, test data is ready and the test team is staffed as in section 6.

4.12 Deviations from the organisational test strategy

5. Testing activities and estimates

A contingency of [15%] is held by the test manager for retesting and scope changes.

6. Staffing

6.1 Roles, activities and responsibilities

6.2 Hiring needs

[None / one contract performance engineer for four weeks from YYYY-MM-DD.]

6.3 Training needs

7. Schedule

The schedule below shows the main test milestones; dates are illustrative and must be replaced with the project dates.

8. Glossary and references

References: [Test strategy TS-ORG-001], [SRS], [Release plan], ISO/IEC/IEEE 29119-3, Software testing, Part 3: Test documentation.

Standard and licence note

Structure aligned with ISO/IEC/IEEE 29119-3, Software and systems engineering: Software testing, Part 3: Test documentation, test plan information item. This template is original text written for this collection and reproduces no text from the standard; obtain the standard from ISO, IEC or IEEE for its normative requirements. Template licence: MIT.