Risk-Based Testing: Prioritizing What to Test
You cannot test everything. Risk-based testing helps you focus on what matters most: high likelihood of failure and high impact. This post explains how to identify and prioritize risks and align your test plan with them.
What is risk-based testing?
Risk = likelihood × impact. You prioritize tests for areas that are more likely to have defects and where failures would hurt users or the business most. You still test other areas, but with less depth or later.
Identifying risks
- Likelihood: New or changed code, complex logic, many integrations, unclear requirements, history of bugs in the area.
- Impact: Critical user flows, money, security, compliance, reputation. Ask: "If this breaks, how bad is it?"
List areas (features, flows, integrations) and score likelihood and impact (e.g. high/medium/low). Focus testing on high likelihood and high impact first.
Prioritizing tests
- High risk: Full coverage (functional, regression, edge cases); automate where possible.
- Medium risk: Core flows and main regression; automate key paths.
- Low risk: Smoke and sampling; manual or light automation.
Re-prioritize when requirements or architecture change.
Summary
- Risk = likelihood × impact; use it to decide where to test first and how deep.
- Identify risks from change, complexity, integrations, and business impact.
- Align test plan and automation with risk: more effort on high risk, less on low risk.