)
10. Is the structure of the code so entropic that it is better to throw it away and start again? (Are the
numbers of bugs introduced per fix rising? Then identify the features with the largest numbers
of bugs and rewrite the top 20%. Repeat until the rate of bug introduction starts to drop.)
11. Which features have the most/least bugs? (Ensure the bug-management tool lists the feature names.)
12. Which tests have found the most/least bugs? (Ensure the bug-management tool lists the test names.)
13. How many lines of code per bug per release?
14. How many (critical) bugs are found per build? (Are we getting better?)
Answers to these can be found using statistical estimations based on many years of experience of software
development.
This chapter discusses these questions beginning with the question of the complexity of code and the
limits to which it can be tested.
Note that there is no foolproof method of test-case estimating yet discovered. All one can currently
attempt is to use several approaches and see how well, if at all, they converge.
18.12.1 The Difficulty of Estimating System Test Cases
The table in Figure 18.27 shows various counts of words, tests, and test steps. It was derived from a big
project whose requirements specifications were prose-based and feature-specific in that each specification
corresponded to a feature. The tests were written using TestDirector?„? and each test consisted of at least
one test step.
Pages:
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633