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:
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.
|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.