by a user to identify the riskiest ones.
Step 2: Design and then assign test cases to each functionality listed in Step 1.
Step 3: Size (in hour or minutes) the QA effort required to run the test cases identified in Step 2.
Step 4: Sort test cases in ascending order of effort so you have the test case with the minimum effort first.
Step 5: Start running test cases in the order established in Step 4 until you run out of time.
A Word about Automation
Ideally, you always want to lower the risk in the shortest period of time in order to release versions more aggressively. One way to shorten your QA cycle and still having the same confidence level in the software is to automate with QA tools for both functional and unit testing the minimum required QA effort to reach Zone A in Figure 2.
Let's say I want to implement two new features in my software. I have the choice of implementing the two features in the same version or implementing each feature in two successive versions. From a QA standpoint, having two successive versions with the same confidence level has a huge impact on the workload unless you automate the test cases listed in step 4 of the above methodology.
Looking at Figure 3, where the relationship of Figure 1 and Figure 2 have been superimposed, clearly shows that lowering the risk to 50 percent can be achieved in a shorter period of time if testing prioritization has been done with risk in mind.
Steve Wakeland: Testing as a component of an organizational IT risk management strategy. Cutter IT Journal, August 2002