Risky Business: Using Risk Analysis to Prioritize Testing

[article]

has the same rating, so it may be necessary to limit the team to a specific number of "highs."

Step 5: Assign numerical values corresponding to the relative values assigned in steps 3 and 4.
We typically assign a value of three for high, two for medium, and one for low. Other teams choose different scales such as ten for high, five for medium, and one for low. It is relatively unimportant which scale you use, but once you choose one, you must remain consistent throughout the exercise.

Step 6: Compute the risk priority.
Add the values assigned to the likelihood and impact together for each feature and/or attribute. For example, if the withdraw cash feature was assigned a value of high (or three) for likelihood of failure and high (three) for impact, then the risk priority would be six, which is the highest risk rating using this scheme. Some teams may choose to multiply the numbers together instead of adding them. This will have very little impact on the actual prioritization of the features, but once you choose a scheme, you must remain
consistent throughout.

Step 7: Review/Modify the values.
After the initial risk priority has been assigned, it can be modified based upon other knowledge, such as cyclomatic complexity, failure history, degree of change, etc. For example, if we had assigned a high likelihood of failure to the withdraw cash feature and a review of our defect logs shows that, in past releases, this feature has operated virtually without flaw, we may choose to lower the likelihood of failure and modify the risk priority accordingly.

Step 8: Reorganize the list of features and attributes in order of risk priority.

Step 9: Establish a "cut line."
If time and resources do not allow enough time to address all facets of the system, it  ay be necessary to establish a "cut line" that separates features to be tested from  features not to be tested (or maybe tested less). At the end of the day, software risk  analysis is used to prioritize what to test first and, in some cases, what may not be  tested at all.

Step 10: Consider ways to mitigate risk.
In some instances, you may decide that the risk rating of certain features is unacceptably high. In this case, you could consider some type of mitigating activity such as a code inspection, additional testing, etc., to reduce the likelihood of failure and hence reduce the overall risk.

Mitigated List of Priorities for ATM Features/Attributes

Risk analysis is an important part of testing. Few organizations have enough time and resources to address every feature to the level of detail that they would like. Risk analysis allows us to intelligently choose where to apply the bulk of our effort. Once a risk analysis has been conducted for a particular product, it is not necessary to completely start over for the next release, but rather just revisit the results of the previous risk analysis and update the features, likelihood, and impact columns.

Good Luck.

About the author

Rick Craig's picture Rick Craig

Rick Craig is a consultant, lecturer, author, and test manager, who has led numerous teams of testers on both large and small projects. In his twenty-five years of consulting worldwide, Rick has advised and supported a diverse group of organizations on many testing and test management issues. From large insurance providers and telecommunications companies to smaller software services companies, he has mentored senior software managers and helped test teams improve their effectiveness. Rick is co-author of Systematic Software Testing and a frequent speaker at testing conferences, including every STAR conference since its inception. 

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!