How do we prioritize the features to test first and evaluate which modules need more testing effort than others? The answer is risk-based testing.
This is a type of testing approach that is focused on mitigating risks and prioritizing the testing effort accordingly. It involves assessing the risks based on software complexity, impact on the customer, and history of production problems. Finally, arriving at a risk score that determines the level of testing effort needed for each module.
For example, say you are testing two requirements. Requirement A is to build a payment functionality so that customers can make a payment via the web page, and requirement B is to ensure the font size throughout the webpage is to be changed from size 14 to 16. If requirement A is not implemented correctly, it is a high impact on the business and customer as none of the payments for your services may go through. This may result in a huge financial loss and a bad customer experience. If requirement B does not work as expected, it is an issue but the customer or the business is not financially affected and may even go unnoticed by the customer.
So, if there are three days to test the above requirements, it would make more sense to allocate a majority of the time for testing requirement A and the remaining time (if any) for testing requirement B. This way you are prioritizing the testing effort based on risks and impact.
How to Perform Risk-Based Testing
Risk-based testing consists of two stages:
- Getting clarity on what needs to be tested
- Conducting a formal risk analysis
Getting Clarity
The members of a development team should develop a common understanding of the different features that have to be tested as part of the application.
Some questions that help in the process are:
- What features have to be tested?
- How much time you have to test?
- How many resources you have for the testing effort?
- What are some of the high-risk areas of the application?
- What should be outside the scope of testing?
- What metrics will be used to measure testing progress?
Once there is a clear understanding of the answers to these questions, a team is ready to conduct a risk analysis.
Conducting a formal risk analysis
The first step toward risk-based testing is doing a formal risk analysis. Begin by:
- Targeting different modules to test
- Identifying different risks associated with each module
- Gathering scores related to impact, complexity, and history of production problems
- Calculating risk scores
The next step is to identify different types of testing to be performed and how much effort should be dedicated to each module based on the risk score.
For example, say we have a flight-booking application. There are various features that the application offers, but the impact on the customer if some of the features do not work varies.
If we do a formal risk analysis, these are things we may identify:
- Module: Something we might want to test or test for
- Risks: Direct, concise descriptions of potential problems and their impact
- Impact rating: The business representatives’ severity rating of the potential impact on the customer from 1 to 5, where 5 = worst impact and 1 = least impact
- Technical rating: The solutions architect or tech lead’s rating of the likelihood of a problem occurring in the module based on complexity, churn, dependencies or other technical aspects of the implementation from 1 to 5, where 5 = highest likelihood and 1 = least likelihood
- Historical rating: The problem subject matter expert’s rating based on historical production problems from 1 to 5, where 5 = highest likelihood and 1 = least likelihood
Module |
Risks |
Impact Rating |
Technical Rating |
Historical Rating |
Module Rating¹ |
Risk Score² |
|---|---|---|---|---|---|---|
Flight search |
*Customers are not able to search for required flights*Customers are not able to search for flights with more than one adult*Customers are able to search for flights for dates that are past the current date*Customers are not getting the same search results in the desktop, mobile web, and mobile native apps*Prices do not change when I add minors to the trip |
5 |
5 |
5 |
5 |
25 |
Flight booking |
*Customers are not able to book round-trip flights*Customers are not able to book one-way flights*Customers are not able to book multi-city flights*Customers are not able to book flights in incognito mode*Customers are not able to book Basic status flights |
5 |
4 |
3 |
4 |
20 |
¹ Max of technical and historical ratings
² Impact rating × module rating
After identifying the risk scores, we can start prioritizing our testing in terms of:
- How much manual testing effort is needed
- What flows have to be automated
- What regression tests have to be run
- How many exploratory testing sessions would be needed, and on what flows
In this way, testing is focused on high-risk modules, which have a bigger impact on the customer and the company. This method also helps find critical defects as soon as possible.
We only have a certain amount of time for testing, so it pays to use that time wisely. If you’re looking to make your testing more impactful, start testing based on risk.
Source: https://www.ranorex.com/blog/risk-based-testing-approach/?utm_source=hootsuite&utm_medium=Blog&utm_term=&utm_content=&utm_campaign=
