A team working on an online payment system uses risk-based testing to decide where to focus. A risk analysis identifies the payment authorization flow as high risk (high likelihood of defects and severe impact if they occur), while the report download feature is low risk. Testing effort is allocated accordingly: the payment flow gets extensive test design and execution, including boundary value analysis and integration tests, while the download feature receives a lighter pass. Stakeholders are informed of the residual risk level throughout the project.
How is risk-based testing different from regular testing? It is an approach where the level of testing is driven by the level of identified product risks. Risks are identified starting in the initial stages of the project, and their levels guide the test process — more risk, more testing.
What is a product risk? A product risk is a risk that the component or system itself may fail to meet its objectives — for example, incorrect functionality, poor performance, or security vulnerabilities. Risk-based testing targets these product risks.
Who performs the risk analysis? The test team, developers, and stakeholders together. Risk identification benefits from multiple perspectives, and the resulting risk levels are agreed rather than imposed.
Does risk-based testing replace other test design techniques? No. It determines WHERE and HOW MUCH to test; the actual test cases still use techniques like equivalence partitioning, boundary value analysis, and error guessing.
What is the role of risk in the test plan? The test plan documents the risks requiring contingency planning. Risk-based testing operationalizes that: the plan, the schedule, and the exit criteria all reflect the identified risk levels.