Risk-Based Testing: Deciding What to Test First
There is never time to test everything. A simple, repeatable way to rank features by risk so that testing effort goes where failures would hurt the most.
By russellazim
2 min read
Every release has more possible tests than time to run them. Risk-based testing replaces “test everything a bit” with a deliberate decision about where depth matters.
Risk = likelihood × impact
For each feature or user journey, estimate two things on a simple 1–3 scale:
- Likelihood of failure — new or heavily changed code, complex logic, many integrations, a history of defects.
- Impact of failure — money, data loss, legal or security exposure, number of users affected, reputational damage.
Multiply them. A score of 9 deserves deep, automated coverage; a score of 1 may only need a quick exploratory check.
Build the risk matrix with the team
Risk assessment works best as a 30-minute conversation with developers and the product owner, not a document QA writes alone. Developers know where the code is fragile; product owners know what the business cannot afford to break.
Turn scores into a test plan
- High risk: automated API and UI tests, negative and boundary cases, performance checks, and a place in the release smoke suite.
- Medium risk: automated happy paths plus targeted exploratory sessions.
- Low risk: lightweight checks, monitored in production.
Revisit it every release
Risk changes as the product changes. Re-score features touched by the release, and feed escaped defects back into the matrix — every bug found in production is evidence that a risk was underestimated.
