Risk Based Testing

Risk can be understood as an expected negative outcome that can occur in future and effect quality, cost, technical, and business results. Risks are divided into five levels where level 1 being minimum and 5 being maximum. Here, level 5 is system crash / loss of data, level 4 is boundary conditions, level 3 is negative testing scenarios, level 2 is inconsistent behavior, and level 1 UI issues / spelling errors.

Risk based testing in short RBT is a familiar term in the testing phase of agile methodology. RBT comes into picture when there is a limited time left for testing when compared to development. This scenario is quite common in the today’s IT industry. Management comes across requests from the development team that they would require more time to develop the planned features for the release. In this case the testing time for the last sprints developed features would be less. This may cost dearly to the management if there are any critical functions / features if developed in the last sprints and left with insufficient testing. To avoid such bitter experience in the eleventh hour RBT plan is chalked out at the very beginning of the development phase.

The key stakeholders in the project will identify the user stories that require more attention or has more risk and will provide more story points. And will list out them and plan their development in the first sprints. This helps the QA team to test them rigorously till delivery. The user stories that have more story points will be understood as risk involved features or functions by QA team. The RBT is calculated as product of probability of failure and cost of failure (Rf × Cf).

RBT helps management to track risk involved user stories testing accurately and helps to avoid any unwanted outcomes in the last minute.