Risk-based testing & prioritisation
The second testing principle says you cannot test everything. So the real question becomes: what gives the most value to test in limited time? The answer is risk-based testing.
Risk = Probability × Impact
- Probability — how likely is a defect here? How complex is the code, was it changed recently, was it written by a new developer, how many bugs has it produced historically.
- Impact — what does the business lose if the defect happens? Money, customers, reputation, a regulatory fine, data loss.
The two are measured separately and don't substitute for each other: a rare but money-losing defect (e.g. a double charge) outranks a frequent cosmetic one.
| Risk level | Probability × Impact | Testing approach |
|---|---|---|
| Critical | High × High | Detailed test cases, all negative and boundary cases, regression on every build, an extra exploratory session |
| High | Low × High | Main scenarios plus the key negative cases; always checked before release |
| Medium | High × Low | Checklist-level checks, regression in sprints where it changes |
| Low | Low × Low | Smoke only; exploratory if time allows; explicitly reported as out of scope |
Practical prioritisation criteria (listing these in order makes a strong impression in interviews):
- Money flow — payments, pricing, discounts, refunds
- Change — code touched in this release and its dependencies
- Usage frequency — the paths 80% of users take, per analytics
- Defect history — modules that historically produce the most bugs (defect clustering)
- Regulatory requirement — mandatory reporting and audit areas in insurance/banking
- Irreversibility — can the mistake be undone? A wrong SMS can't be recalled, a wrongly issued policy can't just be deleted
Communicating what was NOT tested is inseparable from risk-based testing. Silence signals "everything was tested" and puts all the risk on QA. The right formulation: "Critical flows are fully tested. Modules X and Y were only smoke-checked due to time — risk: medium. The decision is yours."
For "time is short, what do you test?" the weakest answer is "the most important things". A strong answer names the criteria and gives examples: "Payments and premium calculation — money is at risk; then the code changed in this sprint; then the renewal flow, the most used one in analytics. I'd drop cosmetic UI changes from scope and state that in writing in the release note."