Risk-Based Testing

What it is

Risk-based testing (RBT) is an approach to test planning where you use risk assessment to prioritise test activities. The areas with the highest risk get the most test effort; low-risk areas get less or none. This is how experienced leads make defensible decisions about coverage when there isn’t time to test everything.

Product risk vs project risk

• Product risk — risks that the software will fail to meet stakeholder needs. These become test targets. Examples: payment processing errors, data loss, security vulnerabilities.
• Project risk — risks that affect the testing process itself. Examples: late delivery of test environments, incomplete requirements, team capacity issues.

Risk-based testing primarily addresses product risk. Project risk is managed in the test plan.

Risk exposure = likelihood × impact

Risk exposure is the product of two factors:

• Likelihood — how likely is this to fail? (technical complexity, code churn, new developer, known defect history)
• Impact — what’s the consequence if it fails? (financial loss, user harm, reputational damage, regulatory breach)

Building a risk register

1. Identify risks — brainstorm with stakeholders, developers, and the team. Review defect history. Check industry-specific risks.
2. Assess likelihood — consider: code complexity, number of changes, developer experience, module age, integration points.
3. Assess impact — consider: user importance of the feature, business criticality, regulatory requirements, number of users affected.
4. Calculate exposure — multiply the scores. Sort descending.
5. Map to test effort — high risk = deep testing + automation + early testing. Low risk = light testing or none.

How risk drives test decisions

• Test order — test high-risk areas first so critical bugs are found early.
• Test depth — high-risk areas get full EP/BVA/decision table coverage. Low-risk areas may get smoke tests only.
• Automation priority — high-risk, frequently run paths should be automated first.
• Exit criteria — if time runs out, you can demonstrate that high-risk areas were fully tested and low-risk areas were consciously deprioritised.

ISTQB mapping

NZ example — risk register for a NZ e-commerce platform

For a New Zealand e-commerce platform, a practical risk register might include:

• Payment processing via POLi (NZ bank-to-bank payment) — High likelihood if newly integrated, High impact (revenue loss, customer trust) = exposure 25, test first and deepest.
• NZ address validation (RD addresses, apartment formats) — Medium likelihood (complex input rules), High impact (failed deliveries) = exposure 15.
• GST calculation correctness — Low likelihood (stable code), High impact (tax compliance breach, IRD penalty) = exposure 10.
• Product image display — Low likelihood, Low impact = exposure 4, test last or not at all if time is cut.

Risk-based testing means: when the sprint is shortened, you can show the stakeholder exactly which risks were fully tested and which were consciously deferred. “We tested payment and address validation; we deferred product image testing — here is the residual risk.”