Map the change
Which users, money, data, or obligations move if this release is wrong?
Strategy is a risk budget.
A test strategy says what you will not automate, what must fail the build, and which risks you accept with your eyes open.
- Coverage is not a strategy
- Every check has an owner
- Exceptions are written down
Start from change, not from tools.
The useful question is which failure would be expensive this month.
Name the signal
Which check, if red, would stop you? If the answer is none, the pipeline is a report, not a gate.
Leave a remainder
Some risk stays. A strategy that claims otherwise is marketing.
Where the budget goes.
Most of the permanent suite should be fast and specific. Journeys are scarce.
Developer feedback
Unit and component tests that run before review, on the change that caused them.
Boundary feedback
Contracts and API examples so another team is not your test environment.
Journey feedback
A small end-to-end set for the paths that would embarrass the company, plus smoke after deploy.
Tradeoffs we will say out loud.
A strategy that refuses tradeoffs becomes a wish list.
Speed against fidelity
A stub is faster and less true. Use it when the contract is the risk. Use a real dependency when the integration is the risk.
Determinism against realism
Seeded data makes failures repeatable. Production-shaped chaos belongs in a deliberate exploratory or reliability exercise.
Automation against attention
Exploratory testing is not a failure to automate. It is how you find the risk you did not know to name.
Bring the strategy you have.
Even a rough one. The gaps are usually in ownership and placement, not in missing vocabulary.