# Test strategy

- Product / programme:
- Author:
- Date:
- Review cycle:
- Status: Draft | Review | Approved

## 1. Purpose and audience

Who this document is for, and what decisions it is meant to settle.

## 2. Quality objectives

What “good enough to ship” means for this product. Name user or business risks, not slogans.

## 3. Scope of the strategy

- Products / surfaces covered:
- Explicitly out of strategy scope:

## 4. Test levels

| Level | Intent | Owner | Typical evidence |
| --- | --- | --- | --- |
| Unit | | Engineering | |
| API / service | | | |
| UI / end-to-end | | | |
| Exploratory | | | |
| Non-functional | | | |
| AI / model-backed features | | | |

## 5. Risk-based priorities

How the team decides what is tested first when time is short.

## 6. Environments, data, and tooling

- Environments:
- Test data rules:
- Trackers and repositories:
- Automation principles (what is worth automating):

## 7. Defect and reporting rules

- Severity / priority definitions:
- Where bugs are logged:
- What a release summary must include:

## 8. Roles and cadence

Who designs tests, who executes, who signs off, and how this sits in the sprint or release train.

## 9. AI and model-backed features (if applicable)

What changes after a prompt, model, or retrieval update — and what evidence is required.

## 10. What this strategy does not replace

A strategy is not a test plan, not a case list, and not an RTM. Link those artefacts when they exist.

## 11. Review triggers

When this document must be updated (new surface, new market, new compliance demand, new AI feature).