Q24 of 38 · Manual & exploratory
Explain risk-based testing and give a concrete example of applying it.
Short answer
Short answer: Risk-based testing prioritises test effort by (likelihood of failure × business impact of that failure). High-likelihood, high-impact areas get more tests, deeper test design, and earlier execution. Low-impact areas get less or no testing.
Detail
Most real teams have more tests they could write than they have time to run. Risk-based testing makes the prioritisation explicit and defensible.
The framework: for each feature/area, score likelihood (complexity, recency of change, dependencies, history of bugs) on a 1–5 scale. Score impact (revenue, data, users affected, regulatory, brand) on 1–5. Risk = L × I. Sort. Test from the top.
A worked example for a payments-service hot-fix:
| Area | Likelihood | Impact | Risk |
|---|---|---|---|
| Payment authorisation | 5 | 5 | 25 |
| Refund flow | 3 | 5 | 15 |
| Currency conversion | 4 | 3 | 12 |
| Receipt email rendering | 2 | 2 | 4 |
| Admin dashboard pagination | 1 | 1 | 1 |
The hot-fix touches authorisation. Risk-based prioritisation says: full regression on authorisation, targeted regression on refund and currency conversion (downstream of auth), smoke on receipts, skip the dashboard. If the team has 6 hours of test time, that allocation is defensible to the engineering manager.
Where it gets nuanced: likelihood factors include change recency, code complexity (cyclomatic), dependencies, recent defect rate, and team familiarity. Impact can be split into financial, operational, regulatory, and reputational — sometimes weight them. And coverage doesn't equal risk reduction: a high-risk area with shallow tests is still high-risk; risk-based testing demands the depth of testing scale with risk too.
The senior signal: making the risk model explicit, sharing it with stakeholders, and using it to negotiate scope ("we're not testing X this release because risk = 2; if business impact changes, let's revisit").