Risk-based testing

Risk-based testing accepts that you can never test everything and decides where to spend time based on risk. Each feature or area is scored for likelihood of failure (complexity, amount of change, past defects, new technology) and impact if it fails (money, safety, data, legal exposure, number of users). High-risk areas get earlier, deeper and more varied testing; low-risk areas get lighter checks.

Example

A release touches four areas. Score each from 1 to 5:

Area	Likelihood	Impact	Risk (L x I)	Test depth
Payment provider migration	5	5	25	Full functional, negative, integration, performance, exploratory
New tax rules for one region	4	4	16	Boundary and decision-table tests, regression of totals
Redesigned profile page	3	2	6	Main flows plus a visual check
Footer link update	1	1	1	Quick check

If the deadline is cut by two days, you already know what to drop: depth on the low-risk rows, not the payment migration.

Why it matters

Every test plan makes trade-offs. Risk-based testing makes them explicit and agreed. It also gives a clear way to report status: “all high-risk areas tested, two medium risks partly tested, these known gaps remain” is far more useful to a release decision than “83% of test cases executed”.

Common mistakes

• Scoring alone. Product owners know impact, developers know likelihood. Score risks together.
• Scoring once. Risks change as code lands and bugs appear. A module that keeps producing defects should move up.
• Ignoring low-risk areas entirely. Lower risk means lighter testing, not none. Automated regression usually covers this base.
• Confusing it with bug severity. Severity rates a defect already found. Risk is an estimate made before testing, used to decide where to look.