It has been a common practice now, where the testing cycle is been squeezed time and again either due to development has used up the testing time or due to the pressure of a quick time to market, it’s usually the Quality assurance team who are pushed to meet ends and ensure quality delivered on time. This is where RBT comes into the picture, that is Risk-Based Testing. Almost for every project or product, RBT is the lifeline to nurture quality.
So, let’s Jump into What is Risk Based Testing?
Risk-Based Testing is a testing approach usually carried out to assess the risk associated with the Application under test in terms of its impact and the probability of its occurrence(the likelihood of its occurrence). Based on the two parameters we derive modules or features that need more prioritization than the others and can be taken out for testing in comparison to the others in case of time or budget constraints. So in a more simplified way, we usually assess the risk in terms of the business criticality, defect-prone areas, the frequency of use and of course the visibility for the AUT.
So Risk-based testing approach can be implied at the start of the project as well as at any later stage where the need may arise. It’s always a good approach to ensure all modules or features have been prioritized in terms of there impact and likelihood from the start of the project during test artefacts creation as it helps the testing team during regression.
So basically, the risk is calculated as:
Risk= Impact * Probability of occurrence
We can categorize these risk assessments across modules, something like below:
 |
| Risk Calculation |
In the screenshot above, impact and probability of occurrence have been rated on a scale of 1-5. As you can see modules like Transactions, Category listings and Bookings have higher risk factors compared to others. While creating or cherry picking test cases for regression suite, more emphasis can be given to these modules. Having said so, we can further drill down this RBT technique to test cases also, which helps us provide more clarity on the same.
So I will extend the above scenario for test cases belonging to each module.
|
| Risk calculated with the number of test cases across each module |
The above screenshot is an extension of the previous one with few modules added and an extra column, denoting the number of test cases across modules.The change of strategy here is we will now pick test cases across modules with different risk factors and put them in different quadrants.So let’s say my category listing has 40 test cases, now since it has a higher risk associated, it is not mandatory all of them needs to be executed, only the ones with higher impact and probability and maybe medium impact and medium probability can be picked up for execution. The same goes out for let’s say login, so login even though have lesser risk associated yet in few test cases its impact and probability would be higher as compared to others and can be taken into account in a regression suite.
 |
| The risk-based quadrant |
In the screenshot above, we have marked the test cases based on there lower to higher impact and their probability of occurrence from less likely to often. You can see the test cases lying in the rightmost quadrants are the crucial ones and needs to be executed in every regression suite, whenever required, whereas the ones belonging to the leftmost quadrants are of less impact and probability and can be put as out of scope. So in the diagram above all greens are marked as in scope and important for execution ranging from priorities P1 to P3[left most quadrant to the middle ones to the lower ones etc] and red ones denoted as out of scope for the current regression suite.
It is important to mark priorities across test cases since as the time shrinks, one can start executing from P1 test cases to P3 and with less short of time, one can skip the lower priority of test cases. Having said so it is even more important we judge the time and budget constraints and take such risk decisions appropriately. Time and Cost are important factors and may change your quadrants selection criteria.
I would also like to emphasize on factor like defect-prone areas. For example, sign-up/login as a feature rates higher in terms of business criticality for an e-commerce application and also in terms of frequency of use. Let’s say if it turns out to be a defect prone area, then the risk associated with the sign-up/login module will much higher and becomes a crucial parameter to be added in a regression suite. The only concern with this approach is, defect-prone areas can only be evaluated post analysis of defects from system testing. This approach cannot be extended from the scratch as compared to the above two.
Risk-based testing holds an important role in today’s STLC process, as we move towards shrinking testing cycles. It’s important we assess these risk beforehand until its too late and system coverage becomes impossible and we discover bugs all around the corner.
Before I close my article, one of my favourite quotes from Mark Zuckerberg:
“The biggest risk is not taking any risk… In a world that changing really quickly, the only strategy that is guaranteed to fail is not taking risks.”
