Risk-based testing (RBT) is a particularly useful area of software testing that allows businesses to prioritize the rest of their testing strategy.
In RBT, businesses will design and execute various tests based on the biggest defined risks. This, in turn, allows companies to root out the most threatening faults in their products or features early on in their lifecycle, allowing the instigation of preventative measures.
RBT uses risk to rank the testing of features, models, and functionalities based on the probability of faults and failures within them, and the impact said faults and failures would have on the user. By doing so, risk-based testing forces businesses to prioritize their testing efforts. RBT thus also allows for circumstances where testing every single functionality isn’t possible due to time constraints, yet still creates a situation whereby a found fault wouldn’t significantly hinder a user’s ability to operate the software in question.
When to use RBT
Risk-based testing is most useful in situations involving stringent limitations on time and cost. If a business simply can’t afford to thoroughly test every area of risk, then RBT can help to optimize the use of the available resources.
Likewise, if there is a new project (or one that is noticeably more complicated than others) containing a lot of unknowns, then implementing an RBT strategy can ensure the most basic and crucial areas of risk are mitigated.
Lastly, RBT is particularly useful for highlighting areas most vulnerable to SQL injections. SQL injection attacks can by-pass regular security and authorization measures to access data – this being the case, RBT’s risk analysis can help to direct attention to those items most in need of protection.
The importance of RBT
Increase customer focus – With RBT, businesses can better contextualize risks from the customer’s perspective. With customer input, the prioritization of risk impact can be more suited to their needs. After all, what a developer finds important may not be as important to the average user.
Maintain expected quality within expected time – This is more or less the aim of RBT. When there’s a short timeframe for testing, it’s important to prioritize which areas will have a larger impact on the overall product. With this prioritization, businesses can rest assured that the quality of the software hasn’t been compromised due to a rushed testing phase.
Optimize efforts of QA testers – QA testers is one of the most demanding roles in software development. With ‘quality’ being such a high priority, QA testers are needed more and more. However, with RBT, QAs can find most of their efforts directed to the areas most in need, instead of being spread all over.
The Approach of risked-based testing
There are different approaches to risk-based testing – the complexity of which is ultimately defined by the business themselves.
However, the important thing to remember is that, sometimes, running test after test won’t yield any more valuable information – which is why quality over quantity is key. A balance between testing effort and the benefits of the results should be sought out, which is why RBT is such a useful strategy.
The approach of RBT can also change depending on the risks involved and the complexity of the task at hand. That said, here is a general outline of the RBT approach:
- Identify risks – Members of the team should discuss the risks they have identified within any and all product features. This is done before any implementation, although more can be added once it is underway. These risks form the basis for the assessment in the next stage.
- Risk analysis and assessment – RBT, as an approach, aims to highlight high-value risks so testers know where to spend the most time and effort. The risks thus have to be analyzed and assigned a severity.
All identified risks should be quantified and given a priority, which can be as simple as assigning each risk a number. From here, the chances of the risk occurring, and its potential impact, should be decided. The most typical way of doing this involves a rating system. E.g. the probability of a risk occurring is represented with a number from 1 to 5 (1 being a low probability and 5 being an almost certainty). The same system can then also be applied to impact (1 being low impact, and 5 being extremely high)
From this categorization, the ‘risk factor’ can be calculated. Once each team has completed their assessment, working out the risk factor is simply a matter of multiplying the probability by impact, with the areas of the highest risk factor being the top priorities. When this has been established, the team has to begin thinking about what testing strategy will return the most value for the business and the user.
Test Planning, Design and Execution
The risk analysis should have defined the areas of the highest risk to the business. From here, it is the test manager’s job to come up with a strategy – which involves deciding which level of testing to perform in which areas. The specifications of the test should take the identified risks as inputted data to ensure they can be properly mitigated. The tests should then be carried out in descending order, from the highest risk factor to the lowest.
The types of tests can vary from project to project, but it’s common for the areas with the highest risk factor eg a 12 and 15, to be given the most full and thorough testing with the areas of a lower risk factor, for instance a 1 and a 5, to be given exploratory testing only. Ultimately, this ensures the test effort and the test-period timeline match up.
Monitoring and reviewing
Monitoring and reviewing based on the information gained by the tests is a crucial step in the RBT approach. Ultimately, the areas where risk was assessed should be looked at again in order to see if additional steps need to be taken. Please note, this may be applicable if: any areas failed the tests, any bugs were discovered or if any new risks were found during testing.
This article was written by Henry Umney of ClusterSeven.