Overview
Testing What Matters Most
RBT is the pragmatic answer to the impossible task of 'testing everything.' It ensures that if time runs out, the most critical parts have been verified.
In RBT, the team identifies Technical Risks (complex code, new tech) and Business Risks (legal compliance, financial impact). Testing resources are then allocated to the high-risk quadrants first.
Best Practices
Dos and Don'ts
Avoid common mistakes that can lead to flaky tests and maintenance nightmares.
What to do
- •Involve stakeholders (Product, Dev, QA) in the risk assessment process.
- •Use a Risk Matrix (High/Medium/Low) to visualize priorities.
- •Adjust the testing depth based on the risk score.
Common Pitfalls
- •Don't ignore 'Low Risk' items entirely; they just get less focus.
- •Don't assume risk is static—it changes as the project evolves.
The Details
The 2x2 Risk Matrix
QA Managers use the Risk Matrix to defend the test strategy to leadership. Items in the 'High Probability / High Impact' quadrant get 100% automation and manual exploratory testing. Items in the 'Low Probability / Low Impact' quadrant might only get a basic smoke test. This transparency allows the team to accept 'Residual Risk' consciously rather than by accident.