Planning & Estimation: Risk-Based Testing

Release is Friday. The sprint built six stories. You are one tester with two hands. You cannot test everything equally — and here is the uncomfortable truth: pretending you can is how important things get shallow coverage while trivia gets deep. Risk-based testing is the profession's answer, and it's beautifully simple to state: spend testing effort where failure would hurt most and where failure is most likely. This topic turns that sentence into a table you can build in twenty minutes and defend in any meeting.

Airport security runs on the same logic in plain sight: every passenger walks through the metal detector — a cheap universal check — while higher-risk situations get the thorough treatment. Same staff, deliberately unequal attention, and nobody calls it unfair. They call it security.

Risk = Impact × Likelihood

Two questions per area, that's the whole engine. Impact: if this breaks in production, how bad? Payments breaking is catastrophic — money, trust, headlines. The FAQ page rendering oddly is a shrug. Likelihood: how likely is it to actually break? Three signals raise it: new code (this sprint's changes), complex logic (many rules interacting — your decision-table territory), and history (areas that produced bugs before — defect clustering from Chapter 1, now earning money). Multiply the two — high/medium/low on each axis is plenty; this is judgment wearing numbers, not mathematics — and you get a ranking. The ranking is your priority order.

Ranking the Release

Here's Friday's release, ranked in twenty minutes:

Notice what the table did to the vague dread of "six stories, five days": it became a sequence with reasons. Promo changes rank first — money plus new code plus the refund-weekend history, three signals stacked. The reworded email ranks last — a text change in a low-stakes area. And notice the table's political power: when Nadia sees it, she reallocates one of your days from email-testing to promo-testing without you asking. The table did the arguing; you just built it.

Depth Follows Risk

The ranking decides not just order but depth — and this is where the chapters snap together. Tier 1 gets the full Chapter 4 treatment: field workups, the decision table's columns, boundaries, plus an exploratory charter for what no script predicts. Mid-tier gets designed cases on the core rules. Low tier gets checklist coverage or a smoke-level glance. The crucial discipline: say out loud what gets less attention. "The email rework gets a glance, not a workup" — written in the plan, visible to the team. Conscious shallow coverage is a decision; accidental shallow coverage is a time bomb with your name on it.

Estimating Honestly

"How long will testing take?" is the question every tester dreads, because the honest answer is a counter-question: how much confidence do you want? Testing has no natural finish line (Principle 2 — you could always test more), so an estimate is really a scope declaration: "the table's depths, executed, is about four days." Estimate by area and session, not by imagined test-case counts: a tier-1 area is a day; a checklist area is an hour or two. And the part everyone forgets — pad for the bug cycle: finding bugs creates work (reports, re-tests, regression around fixes — the Chapter 3 loop), and a release with zero bugs found has never happened. A useful rule of thumb: whatever the pure execution time, bugs will add a third. Say that out loud too; it stops being padding and becomes a plan the moment it's visible.

When the Schedule Slams Shut

Wednesday afternoon: the promo story lands a day late, the sandbox ate a morning, and two days of plan now fit in one. The unprofessional response is silent triage — test worse everywhere, hope, say nothing. The professional response is transparent scope-cutting: "Given one day, I cover tiers 1 and 2 fully; the search filters drop to a checklist; profile and saved searches drop out — here's the risk that adds." Maybe Nadia accepts; maybe she moves the release; maybe Lucy picks up the checklist areas. All three beat the silent version, where the same corners get cut but nobody chose them and nobody knows. The difference between a professional and a martyr is exactly this sentence, spoken on Wednesday instead of confessed on Monday.