Risk-based testing

Exhaustive testing is not merely impractical — for anything with state and input, it is infinite. So every team already does risk-based testing. The only variable is whether the decisions are made deliberately, in advance, by someone accountable, or implicitly, on a Friday afternoon, by whoever runs out of time first.

The two factors

Risk here is the ordinary product:

Likelihood — how likely is this to be wrong? Driven by change frequency, complexity, how new it is, how many people touched it, and its defect history. Code that changed this sprint is more likely to be wrong than code that has not changed in two years, regardless of how it looks.

Impact — what happens if it is? Money, data loss, safety, legal exposure, reputation, and how many users are affected before anyone notices. That last clause is the one teams forget: a defect behind a canary with good observability has a fraction of the impact of the same defect shipped to everyone at once, which is why the production topology is a risk control and not just a testing venue.

Neither factor is knowable precisely, and precision is not the point. A three-point scale that the whole team can apply in ten minutes beats a twenty-five-point matrix that one person maintains and nobody reads.

Making it concrete

Take the change set for a release, not the system. Nobody can risk-assess a system; everybody can risk-assess the eleven things that changed.

For each area, three columns: likelihood, impact, and where the confidence comes from. That last column is the output — it is what the strategy will actually do about it.

Area	Likelihood	Impact	Confidence from
Payment authorisation	Medium — refactored this sprint	Critical — money, legal	Unit + contract + E2E journey + exploratory charter
Search ranking	High — new algorithm	Medium — annoying, not harmful	Unit + a production A/B test
Password reset	Low — untouched in a year	Critical — account takeover	Existing regression suite only
Admin CSV export	Low	Low — one internal team, has a workaround	Nothing. Deliberately.

The last row is the point of the whole exercise. It is not an omission — it is a decision with a name attached, and it is what makes the other three rows affordable.

The rules that keep it honest

Reassess per release, on what changed. A standing risk register goes stale in a month and then gets rubber-stamped, which is worse than not having one.

Untouched is not safe. Password reset above gets no new work but keeps its regression coverage, precisely because its impact is critical. Low likelihood justifies less new effort, never removing an existing check on a high-impact area.

Write down what is not covered. The uncovered list goes in the release notes for the go/no-go conversation. A risk accepted silently is a risk nobody accepted.

A materialised risk is not a process failure. If the CSV export breaks, the process worked exactly as designed and the bet lost. Punishing that is the fastest way to teach a team to stop making its risk decisions explicit — after which they are still making them, just invisibly. See quality-driven development.

Where the model comes from

Three inputs, in decreasing order of usefulness and increasing order of comfort:

Production evidence. Which areas actually generate incidents and support tickets. Nothing else predicts as well, and most organisations already have this data and do not join it to their testing decisions.

Change data. Which files change most often, and which of those are also complex. Frequently-changed complex code is where defects live; this is mechanical to compute from version control history.

The room. Ask the team, the support engineer and the product owner where they are nervous. Cheap, fast, and better than nothing — but it measures where the attention was, and the attention has already prevented most of what it noticed.

The MCP risk analysis server sketches what it would mean to join the first two automatically. It is not built.