Back to the news
Dev Smartesting

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.

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.

Stay tuned!

AI Generative

How to Test with Generative AI

AI Testing Smartesting

Testing with Generative AI is here – let’s learn to work with it now It’s no secret that AI, and…

Tracking memory leaks using Cypress

Tracking memory leaks using Cypress

Dev Gravity Gravity

TLDR; Last week, we were notified by our colleague Christiano that the Gravity application was facing quite a huge problem…

The Pesticide Paradox

Shifting-right: beating the Pesticide Paradox in Automated Testing

AI Gravity Testing Gravity

More tests does not necessarily lead to higher quality Before delving into the Pesticide Paradox, let’s provide a brief overview…