When Should You Take a Risk-based Approach to Testing and How To Implement It Right?

Editor’s note: Whether you want to ensure the coverage of critical software functionality or optimize testing efforts without compromising software quality, risk-based testing might be an option for you to consider. Below, Victor Sachuk, Test Manager and QA Consultant at ScienceSoft, shares a risk-based testing roadmap we follow to help our clients achieve their QA goals. If you want to optimize your QA with risk-based testing but doubt you have sufficient expertise to implement the approach successfully, consider our testing services offer.

Say, a customer cannot finish a payment due to a bug that went unnoticed while testing an e-store. Or a patient is prescribed a three-times higher dose of medicine due to a defect in EHR’s order prescription functionality. Though different in magnitude, both cases exemplify product risks.

To minimize risk probability and lessen their impact, I recommend taking a risk-based approach to testing. Risk-based testing (RBT) means managing, prioritizing, and executing testing activities based on the likelihood and impact of risks in different functional software modules. Read on to understand whether risk-based testing is a good fit for your project and learn how to implement it.

Does your project need risk-based testing?

I find it effective to choose risk-based testing in the following cases:

1. You deal with mission-critical software (e.g., online banking application, electronic health records application) and want to make sure that high-risk software modules are defect-free.

You can ensure the quality of high-risk modules by:

• Assigning the most experienced, domain-trained test engineers to test such modules.
• Testing high-risk modules before other application areas, at the point when defects are easier to fix.
• Testing critical functionality with multiple data points.
• Applying advanced software testing techniques, for instance, decision table, state transition diagram.

2. You follow Agile and have to cut down test coverage to stick to sprint deadlines without compromising software quality.

The key to optimizing testing in Agile is streamlining regression testing. For that, organize two regression test suits – a partial regression test suit comprised of test cases covering high-risk functionality and a full regression test suit comprising test cases covering all implemented modules. Running a partial regression test suit of a considerably smaller volume will help you speed up testing while ensuring that critical functionality is covered.

3. You follow Waterfall and have to shorten the testing phase to release on time as development took longer than estimated.

You can start validating high-risk software modules before development is finished. To exclude the chance of regression though, make sure that the test cases executed during development validate isolated software modules that won’t be affected by the implementation of new features.

Not sure if risk-based testing is the right fit for you?

Tell us a few words about your project, and we will help you determine if risk-based testing is the right way to pull off your testing goals.

Get a consultation

ScienceSoft’s risk-based testing roadmap

To implement a risk-based approach to software testing, you may consider the roadmap we follow in our projects:

1. Identify product risks.

Cooperating with software architects and developers, who are well acquainted with an application’s risk areas, our test team analyzes software requirements, design specifications, and other available project documentation and identifies potential risks for all functional software modules.

2. Analyze the risks and prioritize software modules.

Our test team defines risk probability and impact. To state risk probability for a particular software module, we analyze its complexity, dependability on other modules, the technology used for implementation, the experience of developers with the technology, and other relevant factors. To assess risk impact, we analyze the frequency of a module’s usage, its business priority, the cost of rework, potential financial damage, and other factors. According to the identified information, we rank software modules as high-, medium-, and low-risk.

3. Plan, design, and execute testing activities according to the modules’ prioritization.

To prioritize software testing activities quicker, we rely on the following matrix:

*For mission-critical software, for instance, healthcare applications, all functional modules require validation. The coverage of low-risk modules, however, can be minimal.

We assign test engineers with deepest expertise in the required domain to test high-risk modules early in the SDLC and with advanced testing techniques. Low-risk modules, on the other hand, can be validated later in the delivery cycle by test engineers with less domain expertise and using simpler testing techniques (e.g., equivalence partitioning).

4. Monitor and review the risks

Throughout the project, we monitor the risks and adjust testing activities accordingly.

Optimal test coverage with optimal effort

Risk-based testing can help you deliver high-quality software with the optimal effort. If you want to transition to a risk-based approach, consider leveraging ScienceSoft’s professional assistance backed up by 33 years of experience in software testing. If you still doubt whether risk-based testing is the key to solving your testing issues, feel free to consult me.