Risk-based testing when everything is urgent

Risk-based testing is easy to nod along to and hard to do when it matters. It matters when the release date just moved up, half your test time evaporated, and a stakeholder is telling you everything is critical. In that moment you will not test everything — that decision has already been made for you. The only real choice is whether you cut testing deliberately or by accident. Here's the triage I run when the clock is the constraint, learned the hard way across a few too many compressed releases.

Risk = likelihood × impact (and you can eyeball both)

You don't need a formal matrix with numbers. For each area, two fast questions:

• How likely is this to be broken? New code, rushed code, code that just got merged, code with a history of bugs, anything touched by the change → high likelihood. Stable code nobody touched this cycle → low.
• How bad is it if it breaks? Money, data loss, security, "can't use the product at all", reputation → high impact. Cosmetic, rare edge case, easy workaround → low.

High-likelihood and high-impact is where your scarce time goes. Low-likelihood and low-impact is what you consciously skip. That's the whole model — the discipline is applying it out loud.

Anchor on the change, then widen

When time is gone, start at the diff. What actually changed in this release? Test that hardest — it's where new bugs are by definition. Then widen in rings: what's directly connected to the change (calls it, is called by it, shares data with it), then the critical paths users hit regardless (login, checkout, the core workflow), then everything else. You work outward until the time runs out, and because you went in risk order, what you didn't reach is the lowest-risk stuff by construction.

"Everything is critical" is a question, not an answer

When a stakeholder says everything is P1, they're not lying — they just haven't been forced to choose. So force it, gently: "I have time to fully test three of these six before the cut. Which three would you most regret shipping broken?" Almost every time, the list reorders instantly. You're not refusing to test; you're making the trade-off visible and shared, so the call isn't silently yours to be blamed for later.

Write down what you're NOT testing

This is the part that turns triage from a gamble into a decision. List the areas you're skipping or only lightly checking, and attach it to the release sign-off: "Not tested this release: bulk export (low change, low traffic), admin reports (unchanged). Light pass only: settings page." Now the gap is a documented, accepted decision instead of a surprise in production. If one of those skipped areas breaks, the response is "we knowingly accepted that risk", not "QA missed it".

Don't confuse fast with shallow everywhere

Risk-based doesn't mean test everything a little. It means test the high-risk things thoroughly and the low-risk things barely or not at all. A thin, even pass across everything is the worst outcome — you've spent your time without going deep anywhere, so the high-risk bug slips through and you wasted effort on the low-risk areas. Depth where it counts, nothing where it doesn't.

Where this fits

This is everyday test-management judgement under pressure. It pairs directly with the release sign-off checklist (where the "not tested" list lives) and with test plans nobody reads on keeping the planning lightweight. The test plan templates include a risk/assumptions section, and test design techniques help you go deep efficiently on the areas you do test.

Triage under a cut deadline

• Score each area on likelihood (changed/rushed?) × impact (money/data/security/usability?)
• Start testing at the diff, then widen in rings to connected and critical paths
• Reframe "everything is critical" — ask which three they'd most regret shipping broken
• Test high-risk areas deeply; skip or barely touch low-risk ones (no thin even pass)
• Write down what you're NOT testing and attach it to the sign-off as an accepted risk