Reverse Engineer Your Way to Adopting a Risk-based Testing Approach - Nishi Grover Garg

When I first heard about risk-based testing, I interpreted it as an approach that could help devise a targeted test strategy. Learning about risk-based testing can give us a new approach to our testing challenges. Even though Risk-Based testing may ideally be a bigger undertaking, beginning it by simply analyzing the product as well as each sprint for the impending risk areas and then following them through during test design and development, execution and reporting would help us in time crunches. 

But before I could think about adopting this approach into our test planning, I had a challenge at hand--to convince my team. I would like to share how I convinced my team about it by using their own case study, using our previous sprint’s data, defect counts based on user stories and calculating risk priority numbers. You too can reverse engineer your way to adopting a simple, no-frills risk-based testing approach!
 

Takeaways

• Analyzing a team’s sprint history in terms of risk
• Calculating Risk Priority Number (RPN) and the defining Extent of Testing 
• Finding risk areas and Re-focussing testing effort on high-risk areas
• A simplistic, no-frills approach to Risk-based testing