VisaSpark
Sign in
intermediate19 min

Risk-Based Testing and Test Planning

You can never test everything. Risk-based testing gives you a principled way to decide what gets tested first and hardest.

What you'll learn

  • Score a feature's testing priority using likelihood and impact
  • Explain why risk-based prioritization matters more as available time shrinks
  • Distinguish risk-based planning from testing everything equally

Prerequisites

Explanation

A release is two days away, and there's a full week's worth of testing left to do. Something will not get tested as thoroughly as planned. The question is not whether to cut scope — it's which scope to cut, and risk-based testing answers that with a repeatable formula instead of a guess: for each area, estimate likelihood (how probable is a defect here?) and impact (how bad would it be if one slipped through?), and prioritize testing effort toward the areas where both are high.

A payment-processing change has high impact almost by definition — get it wrong and customers are charged incorrectly, a serious, trust-destroying, possibly legal problem. If it's also a complex change touching code that's historically been buggy, its likelihood is high too: this area gets tested first, most thoroughly, with the widest range of techniques from this course. A cosmetic tooltip color change has low impact (nobody's charged wrong, nobody's data is at risk) and usually low likelihood (simple, isolated change) — it can reasonably get a much lighter pass, or be deferred first if time runs out.

Likelihood is informed by real signals: how complex is the change, how much of the codebase does it touch, has this area had bugs before, how experienced is the team with this kind of code. Impact is informed by different signals: how many users are affected, is money or personal data involved, is there a legal or safety consequence, how visible is the failure.

Risk-based testing is not an excuse to skip testing low-risk areas entirely — it's a principled way to allocate finite time, which is always finite in a real project. Teams that test every feature with equal intensity regardless of risk often end up over-testing trivial areas and under-testing the ones where a defect would actually hurt.

Example

A simple risk score: likelihood times impact, both on a 1-5 scale, used to rank features by testing priority.

function riskScore(likelihood, impact) {
  return likelihood * impact; // both on a 1 (low) to 5 (high) scale
}

const features = [
  { name: "Payment processing", likelihood: 4, impact: 5 },
  { name: "Tooltip color", likelihood: 1, impact: 1 },
  { name: "Password reset", likelihood: 3, impact: 4 },
];

const ranked = features
  .map((f) => ({ ...f, score: riskScore(f.likelihood, f.impact) }))
  .sort((a, b) => b.score - a.score);

console.log(ranked.map((f) => `${f.name}: ${f.score}`));

Try it yourself

Add a fourth feature to the array with your own likelihood/impact scores, then re-run and see where it ranks.

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Guided exercise

Guided exercise

Score two features on a 1-5 scale for likelihood and impact, then compute their risk scores: loginLikelihood, loginImpact, footerLikelihood, footerImpact (a security-sensitive login change vs. a static footer text update). Then set loginScore and footerScore as likelihood times impact.

Checks: login scores higher risk than the footer change · loginScore is correctly computed · footerScore reflects a low-risk change

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Stuck? Get a hint.

Independent exercise

Independent exercise

Write a function testingPriority(likelihood, impact) that returns 'high' if likelihood*impact >= 15, 'medium' if it's 6 to 14, and 'low' if it's 5 or below (both scales are 1-5).

Checks: high-risk combination returns 'high' · medium-risk combination returns 'medium' · low-risk combination returns 'low' · exactly-at-boundary score (15) returns 'high'

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Stuck? Get a hint.

Common mistakes

  • Skipping testing on a low-risk area entirely instead of giving it a lighter, proportionate pass — risk-based testing prioritizes, it doesn't eliminate.
  • Estimating likelihood or impact from gut feeling alone instead of real signals (code complexity, past defect history, number of users affected, financial/legal consequences).
  • Treating the risk score as a one-time calculation instead of revisiting it as a feature's complexity or blast radius changes during development.

Knowledge check

Knowledge check

1. What two factors does risk-based testing combine to prioritize testing effort?
2. A cosmetic, isolated change has low likelihood and low impact. What does risk-based testing suggest?
3. What real signal would most reasonably raise a feature's estimated likelihood of containing a defect?

Takeaway

Risk-based testing turns "we don't have time to test everything equally" from an uncomfortable reality into a principled decision, using likelihood and impact to decide where finite testing time goes first.

Summary

This lesson covered scoring testing priority by combining likelihood and impact, and explained why proportional, risk-informed allocation beats testing every area with equal intensity.

References

Your notes

Notes save automatically.

Finished this lesson?

Mark it complete to track your progress and schedule a future review.

Next: Writing Defect Reports Testers Trust →