5.3 Risk-Based Testing
Key Takeaways
- A risk is a potential event, hazard, threat, or situation that could cause an adverse effect.
- Risk level is determined from likelihood and impact (risk = likelihood x impact); high risk deserves more attention than low risk.
- Project risks threaten project objectives such as schedule, budget, staffing, tools, suppliers, or scope.
- Product risks threaten product quality and can harm users, revenue, reputation, security, safety, or maintainability.
- Risk-based testing uses risk analysis (identification + assessment) and risk control (mitigation + monitoring) to select, prioritize, and manage testing.
Risk Basics
A risk is a potential event, hazard, threat, or situation whose occurrence would cause harm. In testing, a risk is not the same as a defect. A defect already exists in a work product; a risk may or may not occur. Testing reveals information about risks and can reduce some of them, but it does not remove all uncertainty.
Risk level combines two attributes: likelihood and impact. Likelihood is the probability the risk occurs; impact is the consequence if it does. Quantitatively, risk level may be computed as likelihood x impact. Qualitatively, a risk matrix may classify risks as low, medium, high, or critical.
Worked Risk Example
Suppose likelihood and impact are each scored 1 (low) to 5 (high), so risk level ranges from 1 to 25.
| Risk | Likelihood | Impact | Level (L x I) | Priority |
|---|---|---|---|---|
| Typo on admin-only help page | 4 | 1 | 4 | Low |
| Rare wrong medication dosage | 2 | 5 | 10 | High |
| Flaky checkout total before a sale | 5 | 5 | 25 | Critical |
| Slow report export | 3 | 2 | 6 | Medium |
The flaky checkout (25) gets the most thorough testing first; the help-page typo (4) gets light coverage even though it is more likely, because its impact is trivial. This is the core idea of risk-based testing: order and depth follow the product of likelihood and impact, not likelihood alone.
Project Risk vs Product Risk
Project risks relate to managing and controlling the project. They threaten schedule, budget, scope, staffing, communication, supplier delivery, tools, environments, or estimates. If a test environment is delivered two weeks late, the product may still be good, but the project objective is in danger.
Product risks relate to the quality of the product itself. They threaten functionality, reliability, performance efficiency, usability, security, compatibility, maintainability, portability, safety, or other quality characteristics. If a payment calculation is wrong, a session leaks data, or response time is unacceptable, a product risk has become a product quality problem.
| Scenario | Risk type | Why |
|---|---|---|
| Test data not ready until the final week | Project risk | Threatens the ability to test on schedule |
| A tax calculation may round incorrectly | Product risk | Threatens functional correctness |
| Supplier may miss delivery of an API stub | Project risk | Threatens project dependency management |
| Search may time out under peak load | Product risk | Threatens performance and user experience |
The trap is to classify every technical issue as product risk. Poor tool support, unstable environments, and missing skills are usually project risks. A runtime failure, wrong result, weak architecture, or security vulnerability is usually a product risk.
Risk Analysis
Product risk analysis aims to focus testing so residual product risk is minimized. It should begin early, while requirements, architecture, designs, user stories, or acceptance criteria can still be improved. Risk analysis consists of risk identification and risk assessment.
Risk identification creates a broad list of possible risks. Inputs include workshops, brainstorming, interviews, checklists, cause-effect diagrams, incident history, production analytics, architecture reviews, and domain-expert input. Diverse stakeholders matter because users, developers, testers, support staff, and business owners each see different risks.
Risk assessment categorizes risks, estimates likelihood and impact, determines risk level, prioritizes risks, and proposes responses. Categorization helps because similar risks need similar mitigation: security risks may need threat modeling and penetration testing; usability risks may need user research and exploratory testing; performance risks may need monitoring and load tests.
How Risk Changes Testing
Risk analysis influences test scope and thoroughness. High-risk areas may receive more test levels, more test types, stronger techniques, higher coverage targets, more independence, more experienced testers, earlier testing, more reviews, and more regression testing. Low-risk areas may receive lighter coverage if stakeholders accept the remaining risk.
Risk-based testing does not mean blindly ignoring low-risk areas; it means making explicit tradeoffs. If one day remains, risk analysis helps decide whether to test a legal-disclosure workflow, a rarely used color setting, or a fragile integration. The best choice depends on likelihood, impact, business priority, and what is already covered.
Risk Control
Risk control includes risk mitigation and risk monitoring. Mitigation implements actions to reduce the risk level. Monitoring checks whether those actions work, gathers new information, and watches for emerging risks. Control can include testing, reviews, static analysis, choosing skilled testers, increasing independence, changing coverage, or planning contingencies.
Not every risk is mitigated by more testing. A risk may be accepted, transferred, avoided, reduced by redesign, or handled with a contingency plan. Testing provides evidence and finds defects, but a high-impact architectural risk may require a design change, not just extra test cases.
Exam Traps
- Risk level = likelihood x impact; a high-likelihood, low-impact item is not automatically high risk.
- Project risk threatens the project process; product risk threatens product quality. Unstable environments and tool gaps are usually project risks.
- Risk analysis = identification + assessment; risk control = mitigation + monitoring. Keep the pairs straight.
- Mitigation is not always more testing; some risks are accepted, transferred, or avoided.
A team is worried that the shared performance environment will not be available before release testing starts. What type of risk is this?
A risk has a likelihood score of 2 and an impact score of 5 on a 1-5 scale. Using risk = likelihood x impact, what is its risk level, and how should risk-based testing treat it?
Which actions may be appropriate responses to analyzed product risks?
Select all that apply