Everyone wants lower costs, shorter schedules, and higher quality in software testing and QA—but you can’t have it all. Upper management wants cost and schedule savings, but you can’t just sacrifice quality, either. Could Risk-Based Testing be the ideal compromise?
| Risk-Based Testing revolves around a simple concept: you can’t achieve 100 percent coverage in functional testing, so you need to concentrate your limited efforts on mitigating as much risk as possible. Unfortunately, determining and quantifying that risk is probably the single-largest impediment to implementing a Risk-Based Testing plan. |
When it comes down to it, a lot of software testers and QA personnel are stuck between a rock and a hard place.
On one hand, we’re the last line of defense. Tasked with safeguarding the user experience, we ensure that the applications we review are free of costly defects that undermine productivity and embarrass our organizations. However, at the same time, we’re also increasingly hamstrung as we face growing pressure to do that job as fast as humanly possible (if not faster) without raising costs.
That’s because our three primary deliverables—cost, quality, and time-to-market—exist on a zero-sum continuum. You can’t improve one or two without compromising at least one of the others. Here’s another way to look at it: if you want to find every single defect in a system, it’s going to take an inordinate amount of time to do so—or an incredible sum of cash to keep the project on schedule. No matter your goals, compromise is key.
So, bearing that in mind, let’s consider what’s probably the most common challenge we face: lowering costs and hastening time-to-market while still delivering a quality product. To keep costs down and shorten our schedule, we’re going to have to test less; but we can’t just release a defect-laden mess, either.
Fortunately, in these circumstances, Risk-Based Testing is our ace-in-the-hole. By being judicious about what we test, we can still prevent critical outages and maintain key functionalities—all while saving time and money by testing less overall.
In its simplest form, Risk-Based Testing revolves around a simple concept: you can’t achieve 100 percent coverage in functional testing, so you need to concentrate your limited efforts on mitigating as much risk as possible. Traditionally that’s accomplished by focusing your QA activities in two main areas:
- The parts of the application with the highest probability of failure
- The areas with the highest impact of failure
Unfortunately, determining and quantifying that risk is probably the single-largest impediment to implementing a Risk-Based Testing plan. Without objective analysis, you’re essentially shooting in the dark—and that’s not a viable option when you’re trying to test less in the first place.
This is a common challenge for our clients—and one that we’re more than happy to help with. Our proprietary approach blends a combination of metrics, code analysis, interviews, and more into a risk-based roadmap of your software system’s most-fragile components—enabling us to zero in on what’s most important without wasting a second.
The upshot here is that you get the most “bang for your buck” out of testing. By ensuring that the most important functionalities work properly and thoroughly testing the most-fragile components, you can avoid most rework while still meeting your cost/schedule goals. You’ll still have to deal with some defects elsewhere, but that was the plan all along—making a somewhat bitter pill all that much easier to swallow.
After all, it only takes a spoonful of sugar to help the medicine go down. And considering the lower costs and shorter time-to-market of a risk-based testing approach, that’s pretty sweet result for anyone.
Cheers,
Mike Hodge
Lighthouse Technologies, Inc
Software Testing | Quality Assurance Consulting | Oracle EBS Consulting
