Everything involves risk. Testing is no exception.

Any software tester can tell you that risk and testing are related, but many still do not know what risk-based testing actually is. Risk-based testing is much more than “testing based on risk”, though that is still the definition heard most often.

Let’s start by sorting out what “business risk” means.

If someone asks you “how risky is it?”, they are asking you to quantify the potential of losing something valuable. If it’s personal risk we are talking about, that “something valuable” could be anything from loss of life, to loss of pride, etc.

Business risk means losing something valuable from a business perspective. This could include loss of faith of clients, loss of reputation, loss of money, etc.

When it comes to testing, that risk potential arises from software errors causing a condition or capability required by a stakeholder, i.e. a requirement, not to be met or possessed. Depending on the complexity of the software, the requirements could range from the tens to the thousands. Any time there is a discrepancy between the intended and the actual behavior of the software, it is the result of a software error. If you are going to diminish risk through testing as early as possible in the development process, you have to first be able to estimate the threat of damage caused by these discrepancies on the level of your requirements. The problem with such a risk-based approach is that it usually takes a professional and a huge amount of time – time that Agile teams often don’t have when trying to continuously test to keep the DevOps cycle flowing. For many teams in this sticky situation, the answer is to either test everything exhaustively, or test at random. As we all know, neither of these solutions are actually very helpful though.

Simplifying Risk-Based Testing Whitepaper Graphic Chart

Download the Whitepaper to find out more about Simplifying Risk-Based Testing

Download the Whitepaper to find out more about Simplifying Risk-Based Testing