# Test Strategy Definition

Decides how a change will be tested before anyone writes a test — which risks are covered at which level, what is deliberately not automated, and who owns each part.

## Deliverable

One Markdown document, `test-strategy.md`, in the structure set out under **Output** below. It sets the levels that **Test Case Specification** writes cases for, and the frame the **Regression Suite Audit** judges an existing suite against.

## Required inputs

- **What is being built or changed** — the system, service or change under test, in whatever written form exists.
- **The risk it carries** — what it costs when this fails: who is affected, what breaks, and whether the damage is recoverable.
- **Who owns quality for this work**, at least by role. Someone has to be able to say the strategy is wrong.

If any of the three is absent, stop and report it. A strategy written without a stated risk ends up covering whatever is easiest to reach.

## Optional inputs

- The architecture: components, integrations, external services, data stores
- The environments available, and how each differs from production
- Test data: what exists, how it is created, and what is restricted
- The pipeline this work passes through, and what it currently blocks on
- Existing automated tests and their run history
- Coverage targets, regulatory obligations or contractual commitments, each with the person or document that states it

Absent optional inputs become entries under **Open questions**. Coverage targets are recorded only when the requester states one; this skill never sets a number itself, and a category with no stated target reads `no target supplied`.

## Execution

**1 — List the risks, not the features.** For each risk: what fails, who it affects, what it costs, and whether it is recoverable. A risk nobody can name a consequence for is not a risk — take it off the list rather than testing against it.

**2 — Assign every risk to a level.** Put each risk at the cheapest level that can actually detect it: the closer to the code, the faster the feedback and the narrower the evidence. Record the level against the risk. A risk that no level covers is written down as uncovered, not quietly moved to a level that cannot see it.

**3 — Decide what is deliberately not automated.** Name the checks that stay manual or exploratory, and the reason for each: changes too often to be worth encoding, needs a judgement no assertion can make, costs more to automate than the risk is worth. An undocumented gap becomes an accident later; a documented one is a decision.

**4 — Name the environment and the data each level needs.** Per level: where it runs, what data it needs, where that data comes from, and what is restricted. Where the environment differs from production, record the difference and the class of defect it hides.

**5 — Give every level an owner.** Per level: who writes the tests, who runs them, and who fixes them when they fail. A level with no named owner stops being maintained, and nobody notices until it is needed.

**6 — Define what the pipeline blocks on.** Which levels gate a change and which only report, what happens to a change that is blocked, who may override a gate, and where that override is recorded. A gate nobody can override is bypassed some other way; an override nobody records is not a gate.

**7 — Set the flakiness rule before there is flakiness.** How an intermittent failure is detected, who is told, whether it is quarantined, who fixes it, and the window the team agrees for that fix. Write the window the team states, never one chosen here. A suite without this rule teaches people to ignore failures.

## Output

`test-strategy.md`, in this order:

- **1. Scope and date** — what is under test, what is excluded, who wrote the strategy and when
- **2. Risks** — one line each: what fails, who it affects, what it costs, recoverable or not
- **3. Levels** — per level: the risks it covers, what it explicitly does not cover, and why that level was chosen
- **4. Not automated** — what stays manual or exploratory, with the reason recorded against each entry
- **5. Environments and data** — per level: environment, data, where the data comes from, and how the environment differs from production
- **6. Ownership** — per level: who writes, who runs, who fixes
- **7. Pipeline gates** — which levels block, which report, what a blocked change does next, who may override and where it is recorded
- **8. Flakiness rule** — detection, notification, quarantine, owner, and the fix window as stated by the team
- **9. Coverage targets** — only those the requester stated, each with the person or document that set it; otherwise `no target supplied`
- **10. Open questions** — what could not be decided, what it blocks, and who decides it

## Validation

The strategy is ready when all of these hold:

- Every risk in section 2 appears in section 3 or section 4, or is listed as uncovered
- Every entry in section 4 carries a reason
- Every level in section 3 has a named owner in section 6
- Section 7 states, for each level, whether it blocks or only reports
- Section 9 carries no figure that the requester did not state
- Section 10 is either non-empty or states explicitly that nothing is outstanding

Fail the run if a risk is covered by no level and is not recorded as uncovered, or if a coverage figure appears without the person who set it.

## Failure handling

- **No stated risk** — stop. Report that the strategy has nothing to choose a level against, and name who must state the risk.
- **No access to the environments or the pipeline** — write sections 5 and 7 from what was reported, mark them `reported` throughout, and state that nothing was verified and every gate described may differ from the one that runs.
- **Contradictory instructions about what must be automated** — record both, name both sources, and raise the contradiction in section 10 as blocking. Do not settle it by choosing the stricter one.
- **A coverage target is demanded but nobody will state one** — write `no target supplied` in section 9 and name who must set it. Never supply a figure to close the section.
- **Partial material** — produce every section the material supports, mark the rest `INCOMPLETE — pending <question>`, and deliver. A strategy that names its gaps can be reviewed; one that filled them cannot.