Risk Based Testing in Software Testing

What is Risk-based Testing?

Risk-based testing is a software testing methodology where the functionalities are tested on the probability of risk from higher to lower. The risks are categorized based on impact on the application, defect clustering, business result, and complexity.

When to Implement Risk-Based Testing?

• Any long-term project on development and maintenance. The longer the project, the tougher, the management of it.
• Project involving research & development. Any new innovative approach is challenging to manage.
• Large scaled projects with a huge budget, large teams, bigger databases, and heavy load.
• Projects following incremental and iterative models.

Types of Risks

Risk is any unprojected event that could change the designed series of tasks. These risks can change the series of projected events, costs, timelines, and, ultimately, functionalities.

Risks are of two types:

1. Positive risks: Positive risks that could bring better deals in the future. Investment in better technology and features could bring more traffic to the product.

2. Negative risks: Risks that, on failure could bring huge losses like issues in the team, economic recession, war, climate changes, etc. These add threats to the cycle of the project.

Characteristics Of Risk-Based Testing (RBT)

• Risk-based Testing matches the order of Testing Always from test cases with the higher risks to the lower ones. This also helps minimize the risk because the riskier for the business is already well-tested.
• More efforts to higher the risk value Once the higher-risk ones are sorted, the entire cycle eases out. Higher risks are mostly to new functionalities or requiring tons of R&D.
• Risk identification is a continuous cycle Risk needs to be broken down into sub-parts as the big chunk of risk would also have smaller units in it. Also, after every task is done, the risk changes to the upcoming one as that is the priority. Also, some tasks that were the low priority of risk can have tons of complications in them as well

Risk Management Process

1. Risk Identification: Risk identification is a brainstorming session where everything is considered requirements, SDLC planning, cost, time, resources, `previous experiences, etc. At this stage, a spreadsheet of risks is maintained. And risks are further divided into smaller sub-risks which is called risk breakdown.

2. Risk Analysis: The risk Analysis session prioritize the risk based on frequency, impact, significance to the product, budget, etc. The product lead and technical lead do this session. After this, we have a sheet with risks in the order of priority.

3. Risk Response Planning: We have a sequential list of risks based on priority. Here comes the crucial element of how to handle the risks. The SDLC process would be altered to manage the risks figured. Risk mitigation is a process to reduce the impact of the risk by following the measures, which includes more effort on heavier risk tasks. Risk Contingency is associated with having a backup plan in case risk gets out of control. The measures to take are associated here.

4. Risk Monitoring: The entire cycle is done to minimize risks. But these risks need to be closely monitored as risks would never be eliminated. Quantitatively measuring the risk at every stage and checking up on the status comes at this phase.

Risk-based Testing Approach

1. Analyzing the requirement phase closely: When the client brings a new project or a requirement to add/update, a functional requirement document is prepared with lists of all the function and non-function requirements. An RTM(Requirement Traceability Matrix) is maintained. All the risks associated with the process are identified at this stage.
2. Finding risks in the development cycle: A SDLC cycle is developed around functionalities. An action plan of execution is done. Sprints are divided, the staff is trained, duration is set. Since the process is getting even more magnified images, we now have sub-tasks. We now have definable risks.
3. Developing a Test cycle around the risks: The testing cycle is developed so that features with higher risks are getting more effort to contain the risk.
4. Risk Contingency Test plans: In case risks are unavoidable or cannot be eliminated, what possible measures can be taken so that the risk is minimized are planned at this stage. The below example would clear the picture.

RBT Approach Example:

Suppose a new payment gateway is being developed where international transactions can be done directly via UPI. If we try to send money to a person in the USA, that can be done directly from the bank, and the app does all the international conversions. Let's look at the RBT process here.

• Requirements are analyzed. Indian transactions would be taxless, and international would be done as per the RBI rules. The risk here is that RBI should approve the app developed. As validation could only be done post application is developed.
• During the one-year development cycle, many risks could be involved. Technical challenges include a smooth interface, default calculating current prices, maintaining atomicity in transactions, etc.
• If the government doesn’t permit such an app, then making this app a competitor of Gpay, PhonePe, etc., would be a backup plan.
• In Indian transactions, USP would be providing EMI integration with many banks with special notifications for timeline payment.

Prioritization and Risk Assessment Matrix

A risk Assessment Matrix is a tabular matrix between an event's probability of occurrence vs. the event's severity. It helps to consider all the factors and label the risk. Risk is categorized based on frequency (how frequently the event is occurring), probable (how likely it would occur), occasion (is it an occasional or occurs a few times), remote (occurs sometimes or not), improbable (occur rarely or not), eliminate (is it impossible to get rid of).

Severity is on the higher to lower, termed Catastrophic, Critical, Marginal, and Negligible.

Risks are high, serious, medium, and low in these combinations.

Results, Reporting and Metrics

Test Reports Document:
The test report document should contain the following headings:

• Document Date, Tester, Module
• Test Case Scenarios
• Test Case(mention status Passed/Failed/Skipped)
• Steps Done
• Bug Found
• Create a Test Coverage Report at the end

Metrics Preparation:

• Test Coverage Percentage
• Pass Percentage
• Fail Percentage
• Defect Percentage
• Risk Identification Percentage
• Defect Detection Efficiency Percentage

Benefits of Risk-Based Testing (RBT)

1. Risk Based Testing helps to focus on the areas where the risk is maximum to lower the overall risk in the project.
2. Risk Based Testing targets project completion by maintaining backups for failure at any stage.
3. RBT improves productivity and helps in cost-cutting.