Information Technology Reference
In-Depth Information
First, you know the total defects discovered from the prior project testing results.
If the next development project is of comparable size and complexity, then the total
defects discovered last time is a reasonable initial predictor of the total defects you
will discover next time. The size of the total defects will give you a viable basis for
a fi rst estimate of your test effort and resources if you have already derived rules of
thumb for average numbers of defects discovered per test script, average numbers of
test scripts per test case, and average time it takes to write and validate each test sce-
nario. A word of warning at this point. The development manager, not understanding
the sources of your prediction, may take the initial predictors as absolute and liter-
ally require your test team to fi nd the same number of defects again. At most, this
attitude will become a self-fulfi lling prophesy, and the testers will fi nd creative but
not necessarily useful ways to discover that many defects. At least, this attitude will
inhibit you from making adjustments to your predictors as the development project
proceeds and you gain more information. Techniques for making these adjustments
midway through the project will be discussed shortly.
Second, you know the curve of the defect discovery from the prior project test-
ing results. As the test team begins executing testing scenarios and discovering de-
fects, you should start plotting the next project defect discoveries on the same graph
as the prior project curve as shown in Figure 12.12.
Figure 12.12
Defect tracking log comparison
Because no two projects are identical, the plot of the current project defect dis-
covery will fall to either side of the prior project curve. Project A is an example of
the curve for your next project if you started fi nding more defects faster than you
did at the same time in your prior project. Recall that such a situation is a desirable
trend, implying that your testing approach this time may fi nd more defects over the
life of the development.
The real value of predictors is to cause you to ask the right questions, not have
the right answers. In this case, an early indication of more effective testing should
cause you to ask why. What was consciously done differently in either the planning
or test execution startup this time that is giving your testing effort this boost ? One
possible answer is an investment in automated testing tools that is paying off with a
Search WWH ::
Custom Search