Testing always faces time and resource pressure. The fast-paced business environment makes accelerated time-to-market crucial for survival. Project managers seeking to release the product before their competitors. consider testing a hold-up. Many project owners regard testing as a cost centre and squeeze resources.

The limited time and resources on offer make comprehensive testing unviable. The option before testers is to run limited and important tests within the available time and resources.

Risk-based testing (RBT) prioritise testing on the likelihood of failure of any specific feature, module, or functionality. They base the priority on how the failure affects the end-user and the business.

Increasing the number of tests does not solve software stability or integrity issues. Rather, understand the objectives of the release, or what the customer seeks. Ensure the robustness of such critical functionality.

Features of Risk-based testing (The “What” of RBT)

Risk-based testing focuses on key risks.

The traditional approach to testing identifies defects in the entire software code. Risk-based testing finds errors in specific areas of the product code, where failure will have the most devastating impact. For instance, a wrong calculation in billing software may ruin the business, whereas a wrong date format, even though an embarrassment, may not have such ruinous implications.

Prioritizing Risks (“When” to Conduct RBT)

Risk-based testing priorities features or functions having the maximum impact on the end-user or customer. The most critical functions increase cost, dissatisfy the customer, or cause bad user experience, when not working. Unearthing such risks early in the product or feature life cycle allows prompt mitigation.

How is Risk-Based Testing Done (The “How” of RBT)

Risk-based testing starts with risk analysis. The “Risk Analysis procedure” ranks tests on the severity of the risks. It finds out the most defective or risky areas having an adverse impact on the business.

There is no standard process or template for risk analysis. The stakeholders of the project, including the project owner, product managers, business analysts, architects, testers, and customer representatives analyse project features, use cases, user stories, functionality, test cases and other requirements. They brainstorm on the importance of each feature.

The stakeholders brainstorm by:

• Gathering inputs on the most used functionality.
• Consulting with domain experts.
• Analysing data from the previous versions of the product, or similar products.

Business managers, project managers, and other sponsors distinguish the “High value” items such as product features, functionalities, requirements, user stories, and test cases, from “Low Value” items in the project.

The stakeholders assess each high-value item for “Likelihood of failure” and “Impact of failure” in a 3×3 grid.

Business specialists assess the “Impact of failure” of the selected features and functionalities. They categorise the impact as “Minor,” “Visible” and “Interruption” along the horizontal axis of the 3×3 grid.

Impact of failure includes loss of revenue, market share, cash flow, quality issues, bad user experience, or anything else.

Technical experts assess the “likelihood of failure” of the short-listed items in production. They categorise each functionality as “Likely to fail,” “quite likely to fail,” and “unlikely to fail” along the vertical axis in the 3×3 grid.

The “Likelihood of risk occurrence,” may be because of:

• The development team not grasping product features well
• Poor project architecture and or design
• Incompetency of the project development team
• Resource issues, such as inadequate tools, under-staffing or obsolete technology
• Lack of time to design the project.

Testers prioritise the top right corner of the grid, or the column depicting the “high likelihood of failure” and “high impact of failure” items. They move on to the other grids as time and resources permit. The ‘low value’ tests, grouped in the bottom left corner, have the least importance to the customer and get the least priority. The depth of testing also correlates to the priority. Testers undertake a thorough test for the top priority items. They determine the extent of the test for lower priority items based on time and resources.

Advantages of Risk-Based testing (“Why RBT”)

RBT is popular because of the many benefits it delivers over conventional and automated approaches to testing. RBT:

• Improves testing productivity. Prioritising tests based on the risk and the impact of such risk on the business optimize testing resources and results.
• Pin-points the level of quality risk, allowing the enterprise to make smart release decisions.
• Shortens the testing life-cycle and speeds up the product’s time-to-market. In many situations with tight deadlines, RBT ensures on-time delivery of the product.
• Reduces testing costs.
• Detects potential problem areas early, allowing effective remediation.
• Improves customer satisfaction, with priority given to risks hurting the customer.

Is RBT the Panacea Every Time(“Where” is RBT Applied)

Risk-based testing, though having several advantages, is selective testing.

Agile and DevOps seek to test everything, test continuously, and test repeatedly. These approaches depend on the automation of tests. All tests go through an automated CI and CD pipeline for every change in the code. RBT is the best choice when it is not possible to have 100% automation.

RBT is not a panacea for issues plaguing testing. RBT suits:

• Situations where there is a constraint of time, cost, or resources.
• Complex situations, such as rolling out an unknown technology with a lot of uncertainties and challenges. Trend-setting R&D projects have several unknowns, making comprehensive testing a non-starter.
• Situations where resource onboarding is too late to make comprehensive testing possible
• When defects manifest late in the product late-cycle. The root cause of such defects is unclear specifications. Comprehensive testing delays the rollout, making it unviable.
• Scope-creep, or situations with a poorly defined scope.
• Instances when the focus is to detect vulnerabilities to SQL injection attacks

Risk-based testing is handy to improve the efficacy of the project, as long as there is clarity on how to use it, and when to apply it.