A risk-based testing approach enables testing teams to utilize their resources well. It is a futuristic model of testing because it uses testing resources in a way where they can have the most impact, no matter constraints are because of budget, schedules, or any unexpected situation like COVID-19.
Risk-Based Testing Basics
In every software, project objectives should be defined at earliest before starting anything. These objectives may include, certain budget, fixed development hours, or any specific release date for the software product.
The risks of a software project depend on the nature and domain of the project. The risk profile of a healthcare application will be different from that of an online shopping application.
Internal and external risks can affect your objectives. Unexpected events can impose new risks on the project. For example, if a key developer decides to leave in the middle of the project that can take away the knowledge which will take time to produce an appropriate replacement.
The risk depends also on the type of development. If the code is complex, it is a critical component of the software or the first of its kind, the risk will be higher. But if the development is on the noncritical functions of the software or code is well understood, the risk will be less.
It is important to identify and consider relevant risks to the software project. Some risks are very hard to predict because they are unrelated to the project.
What is Risk-Based Testing?
Risk-based testing is a testing technique that uses risk assessment to support testing resources allocation. The objective is the efficient use of testing resources and minimizes the effect of potential risks which poses a threat to the organization.
RBT needs to think of two major aspects: The likelihood of a bug’s presence in the code and the impact of that bug on the organization. Applications are developed by putting together the code from many contributors who can have different expertise and experiences. Open source code libraries may be used. All these factors increase the chance of a bug to occur.
RBT can be used to focus most of your efforts on the areas of the software application that are expected to have a bug which has a big impact.
Assessing Risks
RBT needs to assess risk and prioritize our tests as per the risk factor. Here are three criteria to consider while assessing risk.
Criticality
Criticality means the measurement of the impact of a software bug. Most applications have a high critical code, the rest of the application depends on that. If a bug appears in the core critical part of the code, it will impact multiple sections in the application and will produce more defects. Criticality can be helpful while measuring the impact of the risk. If a bug appears in the most critical area of the software, the result will be far more severe than if it had in some other area which was not critical.
Churn
Churn means the number of changes a given file or module undergoes. Application areas where developers make changes very frequently are more prone to defects. If churn is very high, risk-based test planning should consider additional testing, more unit/integration/UI tests should be added.
Complexity
Complexity is also an important component of the possibility to find bugs. More complex code has more possibilities to contain bugs and simpler code has fewer possibilities to produce bugs. There are many methods to find code complexity, you can use cyclomatic complexity. Cyclomatic complexity is the number of possible paths a function or method has. This number determines the number of test cases that should be executed to test a function.
Adopting RBT
Now that we understand the RBT, here are a few steps to get started with it.
- Start with the static risk assessment of the software application. Create a list of major and critical components of your software application. During risk assessment consider criticality, churn, and complexity for each area as you will assign high, medium, low risk for each function. Review and discuss the assessment with your team.
- Map your test coverage against the assessed risk. For all high and medium risk areas, you should have enough test coverage. Each risk should be addressed with appropriate tests like Unit, Integration, End to end tests.
- You need to work with management and development teams if new development affects key functions and risk assessment.
- Create your test plan allocating more testing resources to the areas of high risk.
- Keep an eye on execution and outcomes, learn from your experience, communicate with the team, and adjust plans accordingly.