)
2. The tool used: yes, a bad workman blames his tools but maybe the compiler gives misleading
messages, maybe the development environment is poor, maybe the allegedly reusable code is, er,
terrible, maybe the unit testing tool doesn??™t cover all the input ranges it promised to. Ask the
developers.
3. The people involved: if each developer has a particular area of responsibility, then it shouldn??™t be
difficult to work out that Fred or Freda is in need of, er, further development.
4. The feature involved: some features are buggier than others (surprise). This too is data which can
be got from the bug reports.
See section 7.6.1 and section 18.9.8. Also read [Reason] for a fascinating account of human error.
2.7.4 Which Features Are the Most Buggy?
Providing bugs are feature-related this is simple and can result in pie-charts like the one shown in Figure
2.1. Using such charts it is easy to prioritize the development effort in bug fixing as well as reviewing
where testing effort is best applied (the buggiest features have the greatest number of changes, which
often implies the greatest number of newly-introduced bugs).
Beware though that feature A may exhibit more bugs than feature B, because you have more tests for
feature A.
The Big Questions You Need Answers To
25
2.7.5 Are We Creating More or Fewer Bugs?
This can be determined by:
1. Relating the number of bugs found per build to the number of changes (creates, updates, and
deletes) of each build.
Pages:
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129