Test Strategy: [Organisation, programme or project name]

Complete test strategy for an organisation, programme or project. The structure follows the test strategy concepts of ISO/IEC/IEEE 29119-3 (organisational test strategy and the strategy part of a project test plan). Replace every [bracketed] value and every row marked Example, then remove what does not apply and record why in section 13.

Document control

Approvals

Revision history

Contents

1. Introduction
2. Scope of testing
3. Risk-based approach
4. Test levels and test types
5. Test design techniques
6. Entry, exit and completion criteria
7. Test environments and test data
8. Test automation strategy
9. Defect management
10. Test metrics
11. Roles and responsibilities
12. Tools
13. Reporting
14. Deviations and tailoring
15. Glossary and references

1. Introduction

1.1 Purpose and strategy type

This document sets out how [organisation / project] tests [products or system] so that release decisions rest on evidence proportionate to risk. It is a [organisational / project] test strategy. Project test plans inherit every rule in it unless a deviation is recorded in section 14.

1.2 Test objectives

1.3 Context

• Products in scope: [product A], [product B], [shared platform].
• Delivery model: [Scrum with two-week sprints / continuous delivery / phased V-model].
• Regulatory drivers: [none / PCI DSS / ISO 13485 / accessibility law], which add evidence requirements in section 13.
• Test policy implemented: [Test policy ID and version].

2. Scope of testing

2.1 In scope

2.2 Out of scope

2.3 Assumptions and constraints

• [Assumption, for example: production-like data can be generated synthetically without personal data.]
• [Constraint, for example: the performance environment is shared and available two days per sprint.]

3. Risk-based approach

Testing effort is allocated in proportion to risk exposure. Product risks describe what could go wrong with the software; project risks describe what could stop testing from being effective.

3.1 Risk scoring

Each risk is scored on likelihood $L$ and impact $I$, both on a 1-5 scale, and the exposure is

$E = L \times I, \quad 1 \le E \le 25$

3.2 Risk register

3.3 Risk review cadence

Risks are reviewed at [each sprint planning / each release planning / monthly]. New features add risks before development starts; a risk whose exposure changes by more than one band triggers a review of its treatment.

4. Test levels and test types

4.1 Test levels

4.2 Levels and types matrix

4.3 Confirmation and regression testing

Every fixed defect gets a confirmation test at the lowest level that can reproduce it, and that test joins the automated regression suite. The full regression suite runs [nightly and before every release]; a risk-based subset runs on every merge.

5. Test design techniques

Coverage targets: [80%] branch coverage for high-risk modules, [60%] for the rest; every requirement linked to at least one passed test case.

6. Entry, exit and completion criteria

6.1 Entry criteria

6.2 Exit and completion criteria

6.3 Suspension and resumption

Testing at a level is suspended when [the smoke test fails / more than 20% of tests are blocked / the environment is unstable for more than four hours]. It resumes when the cause is fixed and the smoke test passes again.

7. Test environments and test data

7.1 Environments

Supported client matrix: [Chrome, Edge, Firefox, Safari: latest two versions], [iOS and Android: latest two major versions].

7.2 Test data

• Sources: synthetic generators by default; masked production extracts only with data protection approval.
• Personal data: never copied unmasked into non-production environments.
• Ownership: each test suite creates and cleans up its own data; shared fixtures are versioned with the tests.
• Refresh: [weekly reset of system test database from the seed script].

8. Test automation strategy

The automated suite follows a test pyramid: many fast, isolated tests at the base and few slow, end-to-end tests at the top. The target split by number of tests is shown below.

9. Defect management

9.1 Severity scale

Priority (P1-P4) is set by the product owner and expresses urgency of the fix, independent of severity.

9.2 Defect workflow

Triage happens [daily during system test, twice weekly otherwise] with the test lead, a developer lead and the product owner. Every defect records: ID, title, steps to reproduce, expected and actual result, environment, build, severity, priority, linked requirement or test case.

10. Test metrics

Defect detection percentage is computed as

$DDP = \frac{D_{\text{pre}}}{D_{\text{pre}} + D_{\text{post}}} \times 100\%$

where $D_{\text{pre}}$ is defects found before release and $D_{\text{post}}$ is defects found in production within [90] days.

11. Roles and responsibilities

12. Tools

13. Reporting

Evidence retention: test results, reports and approvals are retained for [two years / the regulatory period] in [system].

14. Deviations and tailoring

A project that cannot follow a rule in this strategy records the deviation below and in its test plan, with the compensating measure.

15. Glossary and references

15.1 Glossary

15.2 References

• [Test policy, version]
• [Quality management plan, version]
• ISO/IEC/IEEE 29119 series, Software and systems engineering: Software testing (parts 1-3)
• [Project test plans that implement this strategy]

Standard and licence note

Structure aligned with ISO/IEC/IEEE 29119-3, Software and systems engineering: Software testing, Part 3: Test documentation, organisational and project test strategy concepts. 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.