The risk-based testing (RBT) approach follows the principles of risk management, but in a testing context. Let’s make a short introduction of risk management and then go into risk-based software testing. 

Risk Management

Risk management is the identification, assessment, mitigation, monitoring and reporting of potential threats and vulnerabilities to the proper performance of an organisation. Risk management is particularly important in quality management, which aims at optimising a product, service and/or company. 

Risk management is a continuous process, as new risks can appear at any time, so companies usually establish regular meetings to carry out risk management. Risk analysis is a great tool with which to prevent and reduce failures, shorten processes, reduce costs, become more efficient and ultimately improve the quality of the product, service and/or company. 

Stages of the risk management process

1.Risk identification 

In this stage, a list of all the problems that are encountered and may arise is drawn up. In order to identify them correctly during this stage, the head or manager in charge of quality meets with the heads of the different areas and also takes into account the opinion of the clients. Risks can be operational, technical or business risks.  

2.Risk impact analysis 

Risks are quantified and prioritised. The probability of occurrence of that risk and also the impact it would cause is determined by assigning values: high – low – medium. Depending on the values given, risks with high probability and high impact will be addressed first. 

The probability of occurrence of the risk may be due to different reasons: 

• Poor understanding of the function by the product development team. 
• Inadequate architecture and design. 
• Insufficient time for design. 
• Incompetence of the team. 
• Inadequate resources: people, tools and technology. 

The impact of the risk, and therefore the loss it produces, can affect: 

• Impact on costs, with consequent losses. 
• Impact on business, with consequent loss of business or market share, legal proceedings or loss of licence. 
• Quality impact, resulting in an inferior or incompetent product. 
• Poor user experience, resulting in dissatisfaction and loss of customers. 

3.Risk mitigation 

The solution is sought and implemented. This stage involves both the quality department and the department where the risk is located. The quality manager proposes a solution and the relevant department confirms whether this proposal is feasible, as it may vary from one project to another, from one person to another, and from one company to another. 

 

4.Follow-up 

Once the solution has been implemented, it is constantly monitored to see if it has been implemented correctly or if new errors have arisen. This monitoring can be done by the quality team, the department concerned, or both. 

 

5.Reporting

Finally, a report is drawn up on the performance of the implemented solution, whether the risk has been solved or whether new risks have arisen. If the correct solution has not been found or the result is not as expected, we go back to the beginning. 

Risk-based testing o RBT

In software development projects, there are common objectives, including: quality, project scope, cost control and meeting delivery or release deadlines. These objectives can be affected by unforeseen risks that increase, for example, project costs, scope changes, etc. and negatively affect the expected quality of the software. 

This is where this approach becomes important, when deviations occur that affect these objectives. 

With risk-based testing, the aim is to reduce the level of risk, as it is identified in advance and makes it possible to implement solutions or mitigation measures from very early stages of the project. Testing also serves to understand, discover, and provide valuable information that can help create better products. 

Risk-based testing offers: 

• Higher customer focus: RBT will help to further test what customers are most concerned about, highlighting what is most important to the company. 
• Reduced likelihood and impact of negative risks: by focusing testing on the highest negative risks, the likelihood of overlooking major defects decreases and therefore the probability assigned to the risk decreases as does its corresponding risk level. Moreover, as testing also provides feedback to the team, including its developers, the impact of a given risk can also decrease, as the feature being worked on can be done differently or better. 
• Increased confidence: RBT can help find the most important defects first, by focusing testing on the highest risks (or risk areas/features), ensuring that important elements are tested thoroughly and found earlier; in this way, the product and its most important elements (e.g., features) can be launched with a high degree of confidence, while ensuring that they meet the intended quality objectives. 
• Optimising QA effort and costs: RBT can answer questions such as: What should we test, where should we start, when can we stop testing, can we reduce testing effort in any way, how and at what “cost”, if we have more time for testing, how can we best use it, and if we have more time for testing, what is the best way to use it? RBT allows defining the scope of testing, focusing on what is relevant and identifying which tests should be executed and their execution priority, considering time and resource constraints; the total number of test cases can be reduced. RBT allows (risk-based) choice of regression tests and provides some clues for selecting automated tests. 
• Increase the risk level of positive risks: if an opportunity is identified, RBT can be used for extensive testing and exploit it. Using testing as a constructive feedback loop, knowing the opportunities and their relative relevance, can increase the likelihood, impact and overall risk level of opportunities. 
• Make better decisions based on risk: sometimes it may be necessary to ship the product earlier, due to time or budget constraints: RBT can give you visibility of the risks, to make a decision knowing the risk. RBT can be used to overcome risks that block “acceptance” (i.e. customer acceptance of the release). RBT implicitly explains why some tests have been run instead of others, which facilitates communication with other stakeholders and avoids discussions about why some RBT tests have not been run at different levels.

 

The benefits of this approach are therefore:  

• More efficient and optimised use of testing and QA resources. By allocating key resources towards high-risk areas. 
• Facilitates QA work, testing, test design and development, and test preparation activities by prioritisation. 
• Allows the QA team to test high-risk areas first and for the product to ‘fail fast’ and be corrected quickly. 
• Provide clarity on ‘test coverage’ and ‘test scope’ to all stakeholders. 
• Allows the team to decide well in advance on the most effective form of product risk mitigation to be implemented. 
• Allows the team to take appropriate action, either to mitigate or to contingency plan or implement the solution to overcome the failure or reduce its impact. 
• Minimises residual risk in software delivery. 
• Helps improve customer experience and customer satisfaction. 

 

CONCLUSION 

Risk-based testing is an effective tool for the QA team to guide project stakeholders based on project risks, assisting in the continuous identification of risks and their resolution, and helps achieve the group’s goal of total quality in the final product. 

If you want to know more about quality, testing, software development, project management, technology strategy? visit our blog!