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
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.