Risk-Based Testing with Yest

As we all know, exhaustive testing is impossible. With few exceptions, you have to make a choice and focus your quality assurance activities on the most critical aspects of the product or project. While agile methods address the #1 risk of any project – unclear or volatile requirements – they don’t really answer the question “What to test, and to what extent? What’s more, methods like Scrum tend to emphasize automated component and user story testing and neglect system testing. If they exist at all, system testers often struggle to keep up with the pace of continuous change that is inherent in every agile method.

Risk-based testing represents a testing strategy tailored to these problems. It enables quality assurance efforts to be properly targeted. Generally speaking, it is the ideal strategy if you’re short of time, money or simply if the testing project itself is high-risk.

The basic idea consists in concentrating the testing effort on those features that have the highest risk of failure. Therefore, the first thing to do is to perform a risk analysis of the workflow, the associated user stories and/or requirements. Usually, each risk is classified in a category, for example High, Medium and Low. Those “risk levels” define the priority and the intensity of the tests to perform.

However, it is often difficult to define precise criteria for the test intensity. A good practice is to apply coverage criteria for equivalence classes, boundary values, decision tables or structural elements of a model.

But before we have a closer look at the risk-based test strategy, let us consider the risks analysis first. Risk analysis is a collective effort. It is important to involve both business analysts and technicians in risk analysis. The former are experts in the risks associated with product use, while the latter have a good idea of the technical difficulties likely to lead to failure. Unfortunately, communication between those two parties is far from being obvious. Especially in larger companies, there are still silos between business and IT departments. Finally, there is the Babylonian language confusion between those who know the system operation codes by heart and those who have coded the same as an array.