What Is Risk-Based Testing?

The amount of testing knowledge added to the web each day is nothing short of amazing. Unfortunately, the scores of new techniques and ideas can be a bit overwhelming, which is why it’s helpful to revisit the classics once and awhile. And that’s what today’s post is all about. Actually, it’s about risk-based testing, but you get the idea.

Way back in 1999, testing guru (and frequent guest of the uTest blog) James Bach published an essential guide on the topic of risk-based testing, which you can find here (PDF). I’ve extracted a few excerpts that will be a reminder for some, an introduction for others, but extremely valuable for anybody that continues reading.

First off, here’s his definition of how to perform risk-based testing:

  1. Make a prioritized list of risks.
  2. Perform testing that explores each risk.
  3. As risks evaporate and new ones emerge, adjust your test effort to stay focused on the current crop.

And here are some testing heuristics he mentions as part of the “outside-in” approach:

  • Capability. Can it perform the required functions?
  • Reliability. Will it work well and resist failure in all required situations?
  • Usability. How easy is it for a real user to use the product?
  • Performance. How speedy and responsive is it?
  • Installability. How easily can it be installed onto its target platform?
  • Compatibility. How well does it work with external components & configurations?
  • Supportability. How economical will it be to provide support to users of the product?
  • Testability. How effectively can the product be tested?
  • Maintainability. How economical will it be to build, fix or enhance the product?
  • Portability. How economical will it be to port or reuse the technology elsewhere?
  • Localizability. How economical will it be to publish the product in another language?

Lastly, here is James’ summary of the importance – and practicality – of risk-based testing:

If there’s a magic to risk-based testing, it’s the magic of noticing the signs and clues, all around you, about where the problems lie. Some people do this without consciously thinking about it, and maybe that’s good enough. But when a problem slips by you because you couldn’t do perfectly exhaustive testing, you may be called upon to explain why you did what you did. Management may assume that you did a sloppy job, and they may not be impressed with the standard argument that all testing is incomplete. That’s when it’s nice to have that risk list or matrix. With risk-based testing, you can show management that you strive to make the best use of the resources they invest. They’ll respect you for that.

What are some other required readings on the subject of risk-based testing? Leave your suggestions in the comment section below.

Essential Guide to Mobile App Testing


  1. burn says

    This is the most ridiculous form of testing around. They introduced this to my company a while ago.The users are quite useless with very little or no knowledge of the applications. In order for they’re leads and managers to meet targets they simply state that since it is low or medium risk they do not have to test it and on most occasions they don’t. My question why don’t all you useless PROCESS morons do something constructive for once.

  2. Prajakta says

    Hi Mike,

    Thanks for the enormously helpful information. However, would like to add some more here…

    One of the toughest challenges organizations face today involves achieving and maintaining their business’s mission-critical applications at peak performance and scalability levels. Without an effective methodology for predicting system behavior and performance under real life stress conditions, they are exposed to the types of catastrophic application slowdowns and failures that cripple productivity, drive away customers and decimate the company’s bottom line.

    Even when poor performance gets captured in the testing phase, the solution often taken involves throwing additional hardware at the problem, a very expensive and wasteful use of financial resources. As such it becomes imperative that businesses effectively engineer their systems for peak performance.

    At QA InfoTech, the Software Performance Testing experts assure whether a system’s performance meets its goals and requirements, now and in the future. If you seek more information on the same topic, please visit: http://www.qainfotech.com

    Thanks & Regards,

  3. says

    Hello Mike .

    Yes I am agree with your post . Testing of a project always perform on the risk factor .In Risk based testing we always perform Spiral model testing , In which Before the implementation We resolved the Risk ,in every phase of implementation the project.

  4. says

    Hi Mike,

    These are very useful tips that helps testers to brainstorm the product from different angles viz. reliability, compatibility and so on which exposes “THE TIP OF THE ICE BERG” that needs to be paid attention ASAP.

    Also I came across an aritcle http://testmythoughts.blogspot.com/2007/11/risk-driven-testing-risk-based-testing.html

    Above article gives a strategy to prioritize the risk items based on their probability and impact. If the probability of the risk is high and it’s impact on the customer is severe it needs to resolved ASAP.


Leave a Reply

Your email address will not be published. Required fields are marked *