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; 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 and risk control 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, risk is not the same as a defect. A defect exists in a work product. A risk may or may not occur. Testing helps reveal information about risks and can reduce some risks, but it does not remove all uncertainty.
Risk level combines two attributes: likelihood and impact. Likelihood is the probability that the risk will occur. Impact is the consequence if it does occur. In a quantitative approach, risk level may be calculated as likelihood x impact. In a qualitative approach, a risk matrix may classify risks as low, medium, high, or critical.
Example: a typo in an admin-only help page may be likely but low impact. A rare incorrect medication dosage calculation may be low likelihood but extremely high impact. A flaky checkout calculation before a sales launch may have both high likelihood and high impact. Risk-based testing gives more attention to the riskier areas.
Project Risk vs Product Risk
Project risks are about 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 are about the quality of the product. They threaten functionality, reliability, performance efficiency, usability, security, compatibility, maintainability, portability, safety, or other quality characteristics. If a payment calculation is wrong, a user session leaks data, or response time is unacceptable, the product risk has become a product quality problem.
| Scenario | Risk type | Why |
|---|---|---|
| Test data will not be ready until the final week | Project risk | It threatens the ability to test on schedule |
| A tax calculation may round incorrectly | Product risk | It threatens functional correctness |
| The supplier may miss delivery of an API stub | Project risk | It threatens project dependency management |
| Search may time out under peak load | Product risk | It threatens performance and user experience |
The exam trap is to classify every technical issue as product risk. A technical issue can be a project risk when it threatens the project process. Poor tool support, unstable environments, and missing skills are often 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 in a way that minimizes residual product risk. It should begin early when 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. Useful 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 see different risks.
Risk assessment categorizes risks, estimates likelihood and impact, determines risk level, prioritizes risks, and proposes responses. Categorization helps because similar risks may 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, 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 ignoring low-risk areas blindly. It means making explicit tradeoffs. If the team has one day left, 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 has already been covered.
Risk Control
Risk control includes risk mitigation and risk monitoring. Mitigation implements actions intended to reduce the risk level. Monitoring checks whether those actions work, gathers new information, and looks for emerging risks. Risk 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. Some risks may be accepted, transferred, avoided, reduced by redesign, or handled with a contingency plan. Testing can provide evidence and find defects, but a high-impact architectural risk may require design change, not just extra test cases.
A team is worried that the shared performance environment will not be available before release testing starts. What type of risk is this?
Which actions may be appropriate responses to analyzed product risks?
Select all that apply