# 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.

<!--
Guidance: How to use this template
- Decide first whether this is an organisational strategy (applies to many
  projects, changes rarely) or a project strategy (applies to one project,
  feeds the test plan). Say which in 1.1 and keep the level of detail to match.
- Start with the risk register in section 3. Every later decision (levels,
  techniques, automation depth, criteria) should point back to a risk ID.
- A strategy states principles and defaults. Dates, names and estimates belong
  in the test plan (quality/test-plan-29119).
- Keep the numbering stable. Test plans and audits refer to "TS 5.2", not to page numbers.
-->

## Document control

<!-- Guidance: Identify the document so every copy traces to one version. Status moves Draft -> In review -> Approved -> Superseded. -->

| Field | Value |
|---|---|
| Document ID | [TS-ORG-001] |
| Strategy type | [Organisational / Programme / Project] |
| Applies to | [Organisation unit, product line or project name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@test-manager] |
| Classification | [Internal / Confidential / Public] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Related documents | [Test policy], [Test plan TP-xxx], [Quality plan], [Risk register] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Head of quality / test | [@name] | [Approved / Rejected / Approved with comments] | YYYY-MM-DD |
| Engineering lead | [@name] | [Decision] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | YYYY-MM-DD |
| Security lead | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: One row per published version. Describe what changed in strategy terms, for example "raised unit coverage target to 80%". -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft for review |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added contract testing for partner APIs after risk PR-07 was raised |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the quality steering group |

## Contents

<!-- Guidance: Keep this list in sync with the headings. -->

1. [Introduction](#1-introduction)
2. [Scope of testing](#2-scope-of-testing)
3. [Risk-based approach](#3-risk-based-approach)
4. [Test levels and test types](#4-test-levels-and-test-types)
5. [Test design techniques](#5-test-design-techniques)
6. [Entry, exit and completion criteria](#6-entry-exit-and-completion-criteria)
7. [Test environments and test data](#7-test-environments-and-test-data)
8. [Test automation strategy](#8-test-automation-strategy)
9. [Defect management](#9-defect-management)
10. [Test metrics](#10-test-metrics)
11. [Roles and responsibilities](#11-roles-and-responsibilities)
12. [Tools](#12-tools)
13. [Reporting](#13-reporting)
14. [Deviations and tailoring](#14-deviations-and-tailoring)
15. [Glossary and references](#15-glossary-and-references)

## 1. Introduction

<!-- Guidance: Give a reader enough context to understand why the strategy looks the way it does. Mention the test policy it implements and the products it governs. -->

### 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

<!-- Guidance: Objectives must be checkable. "Find bugs" is not an objective; "no open severity-1 defects at release" is. -->

| ID | Objective | Measure |
|---|---|---|
| OBJ-01 | *Example:* Prevent regressions in payment and checkout flows | Zero escaped severity-1 or severity-2 defects in checkout per quarter |
| OBJ-02 | *Example:* Give fast feedback to developers | Pull request pipeline completes in under 15 minutes at p90 |
| OBJ-03 | *Example:* Demonstrate conformance to accessibility target | WCAG 2.2 AA audit passes before each major release |
| [OBJ-nn] | [Objective] | [Measure] |

### 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

<!-- Guidance: State what the strategy covers and what it explicitly does not. Out-of-scope items need a reason and, where relevant, the party that does test them. -->

### 2.1 In scope

| Item | Description | Notes |
|---|---|---|
| *Example:* Web storefront | Customer-facing React application | All supported browsers in 7.1 |
| *Example:* Order service | REST service and database schema | Includes data migrations |
| [Item] | [Description] | [Notes] |

### 2.2 Out of scope

| Item | Reason | Tested by |
|---|---|---|
| *Example:* Payment gateway internals | Third-party certified component | Vendor; we test the integration only |
| [Item] | [Reason] | [Party] |

### 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

<!-- Guidance: This section drives the rest of the strategy. Score each risk, then decide which test levels, types and techniques treat it. A risk with no treatment is an accepted risk and must be signed off. -->

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$$

| Exposure | Band | Test treatment default |
|---|---|---|
| 15-25 | High | Several levels, formal techniques, automated regression, independent review |
| 8-14 | Medium | At least two levels, automated regression for the main paths |
| 1-7 | Low | One level, checklist or exploratory testing |

### 3.2 Risk register

| ID | Type | Risk | L | I | E | Treatment (levels, types, techniques) | Owner |
|---|---|---|---|---|---|---|---|
| PR-01 | Product | *Example:* Incorrect tax calculation for cross-border orders | 3 | 5 | 15 | Unit tests with decision tables; API tests per tax region; UAT sign-off by finance | [@name] |
| PR-02 | Product | *Example:* Checkout slower than 2 s at peak load | 3 | 4 | 12 | Load and spike tests (section 4); production monitoring | [@name] |
| PR-03 | Product | *Example:* Stored XSS through product reviews | 2 | 5 | 10 | SAST in CI; security test cases from OWASP WSTG input validation category; annual pentest | [@name] |
| PJ-01 | Project | *Example:* Test environment unavailable for more than two days | 3 | 3 | 9 | Ephemeral environments per pull request; contract tests to reduce dependency | [@name] |
| [ID] | [Product / Project] | [Risk] | [1-5] | [1-5] | [L x I] | [Treatment] | [@name] |

### 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

<!-- Guidance: The matrix shows which test types run at which level. Each cell says who runs it and whether it is automated. Avoid testing the same thing at three levels without a reason. -->

### 4.1 Test levels

| Level | Objective | Test basis | Owner | Environment |
|---|---|---|---|---|
| Unit (component) | Verify logic of individual functions and classes | Code, detailed design | Developers | Developer machine, CI |
| Integration | Verify interfaces between components and services | API contracts, architecture | Developers and testers | CI, ephemeral environment |
| System | Verify end-to-end behaviour against requirements | SRS, user stories | Test team | System test environment |
| Acceptance | Validate fitness for use by business users | Business processes, acceptance criteria | Product owner, users | UAT environment |

### 4.2 Levels and types matrix

| Test type | Unit | Integration | System | Acceptance |
|---|---|---|---|---|
| Functional | Automated (devs) | Automated contract and API tests | Automated E2E plus exploratory | Scripted scenarios by users |
| Performance | Micro-benchmarks for hot paths | Service-level latency tests | Load, stress, soak, spike | Not applicable |
| Security | SAST, dependency scan | DAST on APIs | Pentest per release train | Not applicable |
| Accessibility | Lint rules | Component axe checks | Automated plus manual screen-reader pass | Feedback from users with assistive technology |
| Usability | Not applicable | Not applicable | Heuristic review | Moderated sessions |
| Compatibility | Not applicable | Not applicable | Browser and device matrix (7.1) | Spot checks |
| Recovery and resilience | Not applicable | Fault injection on clients | Failover drills | Not applicable |
| [Type] | [Approach] | [Approach] | [Approach] | [Approach] |

### 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

<!-- Guidance: Name the default techniques per risk band and per test basis. Testers then choose within this frame and record the choice in the test design specification. -->

| Technique | Category | Use when | Required for |
|---|---|---|---|
| Equivalence partitioning | Specification-based | Inputs fall into classes treated the same way | All medium and high risks with input fields |
| Boundary value analysis | Specification-based | Ordered ranges, limits, sizes | All numeric and length limits |
| Decision table testing | Specification-based | Business rules combine several conditions | High-risk rules (PR-01) |
| State transition testing | Specification-based | Objects have lifecycles (orders, accounts) | Order and subscription lifecycles |
| Pairwise (combinatorial) testing | Specification-based | Many configuration parameters | Browser and locale matrix |
| Statement and branch coverage | Structure-based | Code-level adequacy | Unit tests of high-risk modules |
| Exploratory testing (charter-based) | Experience-based | New features, unclear requirements | Every feature before release |
| Error guessing and checklists | Experience-based | Known failure patterns | Low-risk items |

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

<!-- Guidance: Criteria must be objective. Write them so that two people reach the same yes/no answer. Separate the criteria for starting a level from those for finishing it. -->

### 6.1 Entry criteria

| Level | Entry criteria |
|---|---|
| Unit | Code compiles; static analysis passes |
| Integration | Unit tests pass; API contracts published |
| System | Build deployed to system test environment; smoke test passes; test data loaded |
| Acceptance | System test exit criteria met; UAT users trained; known-issue list published |

### 6.2 Exit and completion criteria

| Criterion | Target | Applies to |
|---|---|---|
| Planned test cases executed | 100% of high-risk, 95% overall | System, acceptance |
| Pass rate of executed tests | >= 98% | System |
| Open severity-1 defects | 0 | All |
| Open severity-2 defects | 0 without an approved workaround | All |
| Requirements coverage | 100% of must-have requirements traced to a passed test | System |
| Branch coverage | >= [80%] high-risk modules | Unit |
| Performance | p95 latency within SLA under target load | System |

### 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

<!-- Guidance: Describe the environment tiers and the rules for data. Personal data in test environments is a privacy risk and often illegal; say how it is avoided. -->

### 7.1 Environments

| Environment | Purpose | Fidelity to production | Refresh | Owner |
|---|---|---|---|---|
| Ephemeral (per pull request) | Integration and E2E checks | Same container images, stubbed third parties | Per pull request | Platform team |
| System test | System and regression testing | Same topology, scaled down | Each release candidate | Test team |
| Performance | Load and resilience testing | Production sizing for tested tier | Before each performance cycle | SRE |
| UAT | Acceptance testing | Production-like configuration | Each release | Product operations |

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

<!-- Guidance: State the target shape of the automated suite and the rules that keep it healthy. The pyramid is a default, not a law; justify a different shape. -->

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.

```mermaid
flowchart TB
  e2e["End-to-end UI tests: about 5%"]
  api["API, contract and integration tests: about 25%"]
  unit["Unit and component tests: about 70%"]
  e2e --> api --> unit
```

| Rule | Detail |
|---|---|
| Pipeline gates | Unit and contract tests block merge; E2E smoke blocks deployment |
| Flaky tests | A test that fails intermittently is quarantined within one working day and fixed or deleted within one sprint |
| Speed budget | Pull request pipeline under [15] minutes; nightly suite under [2] hours |
| Ownership | The team that owns the code owns its tests |
| What not to automate | One-off checks, rapidly changing UI under design, usability judgement |
| Maintenance | Test code follows the same review and coding standards as product code |

## 9. Defect management

<!-- Guidance: Define severity and priority separately, the workflow states and who decides. Inconsistent severity is the most common source of argument at release time. -->

### 9.1 Severity scale

| Severity | Meaning | Example |
|---|---|---|
| S1 Critical | System unusable, data loss or security breach, no workaround | Payments charged twice |
| S2 Major | Core function broken, workaround is costly | Cannot apply discount codes |
| S3 Minor | Non-core function broken or core function degraded with easy workaround | Sort order wrong on history page |
| S4 Cosmetic | No functional impact | Misaligned icon |

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

### 9.2 Defect workflow

```mermaid
stateDiagram-v2
  [*] --> New
  New --> Triaged: triage meeting
  Triaged --> InProgress: assigned
  Triaged --> Rejected: not a defect or duplicate
  InProgress --> Resolved: fix merged
  Resolved --> Closed: confirmation test passes
  Resolved --> Reopened: confirmation test fails
  Reopened --> InProgress
  Rejected --> [*]
  Closed --> [*]
```

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

<!-- Guidance: Collect only metrics someone will act on. For each, say who uses it and what decision it supports. -->

| Metric | Formula | Used by | Decision supported |
|---|---|---|---|
| Test execution progress | executed / planned test cases | Test lead | Is the cycle on schedule? |
| Pass rate | passed / executed | Test lead, release manager | Exit criterion 6.2 |
| Defect density | defects found / size (KLOC or story points) | Quality manager | Which components need more review? |
| Defect detection percentage | defects found before release / total defects found within 90 days | Head of quality | Is the strategy effective? |
| Mean time to fix S1/S2 | average time from triage to closed | Engineering lead | Staffing and priority |
| Flaky test rate | quarantined tests / total automated tests | Automation lead | Suite health |

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

<!-- Guidance: Name roles, not people; the test plan maps people to roles. Make independence explicit for high-risk items. -->

| Role | Responsibilities | Independence |
|---|---|---|
| Head of quality / test | Owns this strategy, approves deviations, reports quality to management | Independent of delivery teams |
| Test manager / test lead | Writes test plans, tracks progress, chairs triage, signs test completion reports | Within programme |
| Tester / quality engineer | Designs and executes tests, maintains automation, reports defects | Within team |
| Developer | Writes unit and integration tests, fixes defects, keeps pipeline green | Not independent |
| Product owner | Sets priority, accepts residual risk, leads acceptance testing | Business side |
| Security tester | Security testing and pentest coordination | Independent team or external |

## 12. Tools

<!-- Guidance: List tool categories and the approved tool per category. Note licensing and data residency where relevant. -->

| Category | Approved tool | Notes |
|---|---|---|
| Test management | [Tool name] | Stores test cases, runs and traceability |
| Unit testing | [Vitest / JUnit / pytest] | Coverage via [tool] |
| UI automation | [Playwright / Cypress] | Runs headless in CI |
| API and contract testing | [Postman / Pact] | Contracts versioned in repository |
| Performance | [k6 / JMeter / Gatling] | Scripts in repository |
| Security | [SAST tool], [dependency scanner], [DAST tool] | Findings triaged weekly |
| Accessibility | [axe-core], [screen readers in 7.1] | Manual checks per release |
| Defect tracking | [Issue tracker] | Workflow in 9.2 |

## 13. Reporting

<!-- Guidance: Define what is reported, how often and to whom. Reports should support decisions, not just display numbers. -->

| Report | Frequency | Audience | Content |
|---|---|---|---|
| Test status report | [Weekly / per sprint] | Project team | Progress, blockers, new risks, defect trend |
| Test completion report | End of each test level or release | Release board | Results against criteria, residual risks, recommendation |
| Quality dashboard | Continuous | Everyone | Pipeline health, coverage, open defects by severity |
| Strategy effectiveness review | [Quarterly] | Quality steering group | DDP, escaped defects, changes proposed to this strategy |

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

## 14. Deviations and tailoring

<!-- Guidance: Projects may deviate from the strategy only with a recorded reason and approval. Unrecorded deviations are audit findings. -->

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

| ID | Rule deviated from | Project | Reason | Compensating measure | Approved by | Date |
|---|---|---|---|---|---|---|
| DEV-01 | *Example:* 8. E2E suite gates deployment | Legacy billing | No stable UI test hooks | Manual smoke checklist signed per deployment | [@head-of-quality] | YYYY-MM-DD |
| [DEV-nn] | [Rule] | [Project] | [Reason] | [Measure] | [@name] | YYYY-MM-DD |

## 15. Glossary and references

<!-- Guidance: Define terms that readers outside the test team will meet. List the documents this strategy depends on. -->

### 15.1 Glossary

| Term | Meaning in this document |
|---|---|
| Test basis | The documents or knowledge from which test cases are derived |
| Test level | A group of test activities organised around one stage of integration |
| Test type | A group of tests aimed at one quality characteristic |
| Exposure | Likelihood multiplied by impact of a risk |
| Escaped defect | A defect first found in production |

### 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.