Checklist · Testing

Test Strategy Checklist

Decide what to test, at what level, and what you are deliberately not testing, with the questions that stop a suite becoming slow, duplicated and untrusted.

Download the checklist (Word) Read the full guide

Markdown. No sign-up, no email.

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

Back to Testing