7 September 2015

What is Risk-Based Testing?

Over the past 5 years, I have spoken with more than 200 CIOs and perhaps a 1000 test experts. Being from the field of software testing, one of the questions that make it a point to ask them, is, “What do you think is the purpose of testing?”

I am surprised at the divergence of answers that I get: a vast majority of testers respond that they test to find and report bugs, so that the developers can fix them.

CIOs, on the other hand are almost unanimous in their desire of knowing the state of readiness of the software. They contend with a very high level of uncertainty about whether or not to introduce updates and/or enhancements into production, because one change can lead to a completely unforeseen impacts in many areas.

Reducing Quality Risk

I have previously read that, “the purpose of testing is to reduce the uncertainty about quality of the system.” In other words, the purpose of testing is to reduce the quality risk of an IT system. Therefore, it is only logical that any testing exercise starts with an assessment of quality risk and where it emanates from.

Risk = Probability of a problem occurring * Impact of the problem should it occur

In our case, the probability of a problem occurring is a direct consequence of what has changed in the system. This, therefore, depends upon the factors such as:

The extent of change in a system

How recently was it changed

Has it been tested by another team (e.g. for packaged software)

Though no one individual knows all of this, the IT team as a whole has a fairly accurate picture of this.

Similarly, people in business – the end users, internal customers, functional consultants would know enough to assess the impact on business if the IT systems of a business process were down for some time (say 12 hours).

The challenge for risk based testing boils down to collecting and analysing the information that is dispersed in different parts of the organisation.

Qsome solution for risk based testing

At the beginning of the test phase, the QA manager can launch 2 surveys – one to collect information about the probability of failure from mostly technical staff; and the other to collect information about the impact on business from those who know about the usage of the system for business processes.

The system then analyses the survey data and stack ranks the testing priorities, starting from the highest risk processes first. The risk ranking guides the complete testing project, from resource planning all the way up to reporting.

The reports that the system generates for senior management, also are based on the risks. A clear picture of the quality risks enables them to take better informed decisions.

Conclusion

Preto's 80:20 principle has immense value in almost every sphere of business. By making risk-based testing practical and real, the Qsome team commits to optimizing the complete testing process for our customers.
If you want more information about our software testing services and leading-edge testing tools, or help in achieving any of the above, get in touch: