Simplify Risk Based Testing: Keep it RIL

keep-it-ril-graphic

Risk Based Testing (RBT) can sound intimidating, but the underlying concept is quite simple. RBT helps prioritize testing to obtain a higher level of quality. Sure you can create some complex equation to rank your tests, but that leaves room for error. I don’t know about you, but I like to keep things simple.

So what is risk? The general definition of risk is the possibility that something bad or unpleasant will happen. Risk associated with testing refers to the possibility a user will encounter something that shouldn’t happen. I want to keep this as broad as possible, so I won’t name this “thing” a defect or bug, because depending on the scenario it may not apply. But there is one thing that risk has in common across the board… and that is risk can be broken down into two components – impact and likelihood. With that said, risk can be turned into a simple equation:

Risk = Impact * Likelihood

I’m a big fan of mnemonics, so I remember this by “Keep it RIL”. Get it?! Like “Keep it Real!” (I know I’m lame…).

Now that we’ve got an equation, let’s discuss how to define impact and likelihood and, more importantly, how to quantify them:
Impact refers to the effect the “thing” will have on the user. Is it an annoyance caused by an extra click on a webpage? Is it hindering user experience by timing out? Or will it cause a zombie apocalypse?

Likelihood refers to how often the effect is expected to occur. Has the feature been changed recently? Is it complex? Does it dependent on a complex component? Has it frequently had an effect on the user in the past? You might notice I use likelihood instead of probability; this is because in testing, there are too many variables in play to consider everything. Probability refers to the possibility of known outcomes based on a fixed number of parameters (like flipping a coin). Likelihood refers to the possibility of outcomes receptive to known and unknown variables (like whether or not it will rain next week).

To quantify impact and likelihood we are going to keep with the theme of simplicity by ranking each on a scale of 1-5. For impact, a rating of 1 is a negligible effect like a small lag and 5 is more serious like and effect that hinders the user from interacting with the product.

For likelihood the numbers can streamline the use of percentages. 1 – (0-20% unlikely to have an effect), 2 – (20-40%), 3 – (40-60%), 4 – (60-80%), and up to 5 – (80-100% very likely to have an effect). Impact and likelihood ranking can rely on a variety of factors, so they should be quantified by a team that is familiar with the testing process.

Once you’ve quantified impact and likelihood you will “Keep it RIL” and multiply impact by likelihood to receive your Risk Priority Number. Tests with a higher risk priority number (closest to 25) have the greatest risk and will take priority in your testing process whereas the lower risk priority number pose less of a threat.

It’s important to note that your ranking might change over time. Risk priority might shift as new features are added in or as you develop a clear understanding of the impact and likelihood of an effect.

Keep it RIL y’all.

RedditFacebookTwitterGoogle+Hacker NewsLinkedInEmailPinterestShare

Comments

  1. We can also say, Risk based testing is basically a testing done for the project based on risks. Thanks for valuable information.

  2. yes ! software testing based on the projects whom are more exposed to risks needs more intensive and risk based testing. If the risk related to a software is effectively managed, than it is possible that software will perform well and transform desire results. Testing is fun especially when you have to maintain the quality for a significant period of time.

  3. interesting with this topic, i want to make a small shop office software,
    but i need more information about thats risk before do

  4. thank you for giving such a useful blog
    it will be really helpful for us
    FOR MORE ABOUT testing :-
    http://crbtech.in/Testing/

  5. yes ! software testing based on the projects whom are more exposed to risks needs more intensive and risk based testing. Valuable information! Looking forward to seeing your notes posted. Thank you for sharing the nice article. Good to see your article.

  6. wow, an amazing article about the risk based testing.

    Risk-based testing (RBT) is a type of software testing that functions as an organizational principle used to prioritize the tests of features and functions in software, based on the risk of failure, the function of their importance and likelihood or impact of failure.

Speak Your Mind

*