# Test Strategy Checklist

**System / release:** _______________  **Date:** _______  **Owner:** _______

## 1. What is this system's risk?

- [ ] **What is the worst thing this software can do?** Written down
- [ ] Which parts, if wrong, cost money or safety
- [ ] Which parts, if wrong, are noticed immediately and cheaply
- [ ] Testing effort matched to that, not spread evenly

> Even coverage across unequal risk is the most common way test effort is wasted.

## 2. Levels — what belongs where

- [ ] Business logic tested at the **lowest level that can test it**
- [ ] Integration tests cover the boundaries between components
- [ ] End-to-end reserved for genuine user journeys — **counted, and small**
- [ ] Nothing asserted at three levels at once
- [ ] Each level's runtime known and acceptable

> A test added at the level where a defect was *seen*, rather than where the logic *lives*, is
> how end-to-end suites grow until nobody waits for them.

## 3. Coverage of behaviour, not lines

- [ ] Boundaries: empty, one, many, maximum
- [ ] Invalid input at every entry point
- [ ] Failure of each external dependency
- [ ] Concurrent execution where it is possible
- [ ] **Negative cases — what must never happen**
- [ ] Permissions: every role against every protected action

## 4. Can these tests fail?

- [ ] Each critical assertion **demonstrated failing** against deliberately broken code
- [ ] No assertion so loose it passes on any output
- [ ] Tests fail with a message that identifies the problem
- [ ] Tests assert behaviour, not internal structure

## 5. Data

- [ ] Test data resembles production in **shape and volume**, not just values
- [ ] No real personal data in test environments
- [ ] Tests do not depend on the previous run's state
- [ ] Tests can run in any order, and are run in a random order at least sometimes

## 6. Environments

- [ ] Environment matches production in the ways that matter, and the differences are listed
- [ ] Created from code, not maintained by hand
- [ ] Not shared in a way that makes tests queue
- [ ] External dependencies stubbed at a boundary you control, with **recorded real responses**

## 7. Speed and trust

- [ ] Pipeline runtime measured, and short enough that people wait for it
- [ ] **Flaky tests: zero.** A known-flaky test is deleted or fixed, not re-run
- [ ] A red build is believed — if the reflex is to re-run, the suite has a defect
- [ ] Fast subset available for pull requests

## 8. What is not automated

- [ ] **Exploratory testing scheduled**, with time protected
- [ ] Usability checked by someone who did not build it
- [ ] Accessibility tested with an actual assistive technology
- [ ] Anything requiring judgement is named as a manual activity, not left implied

> A fully automated strategy tests what somebody thought of. Exploratory testing is how you
> find what nobody thought of.

## 9. Non-functional

- [ ] Performance target stated as a percentile, not an average
- [ ] Load tested at realistic peak, and past it on purpose
- [ ] Security testing proportionate to what the system holds
- [ ] Behaviour when a dependency is slow, not only when it is down

## 10. Explicitly out of scope

- [ ] What is deliberately **not** tested, and why
- [ ] Accepted risks named and signed
- [ ] Anything relying on a supplier's testing recorded as such

> An untested area that somebody chose is a risk. An untested area nobody noticed is a
> surprise.

## 11. Maintenance

- [ ] Someone owns the suite
- [ ] Tests are deleted when they stop earning their runtime
- [ ] Escaped defects are reviewed: could a test have caught it, and at which level?
- [ ] The suite is reviewed on a schedule, like any other code

## Sign-off

| | Name | Date |
|---|---|---|
| Prepared by | | |
| Accepted by | | |