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.
The basic concept of risk-based testing
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.
Risk analysis using models
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.
Smoke Testing, Sanity Testing, and Regression testing: the Trifecta Understanding the differences between Smoke, Sanity, and Regression Testing is crucial…
Historically, software testing was confined to pre-production environments to validate the application against the written requirements. (also known as requirement-based…
The surge of Large Language Models (LLM) like GPT has undoubtedly revolutionized the way we approach natural language understanding and…