??? All bugs of a given priority are fixed before a release is made. Assuming that it be agreed that all
severity-1 and -2 bugs, plus some proportion of severity-3 and -4 bugs are fixed before the next
release be made, it is pointless making a release with only some of the severity-1 and -2 bugs fixed,
since the failure to fix other bugs may leave big problems in the code. Alternatively, when the
developers finally fix them, the fixes may themselves provoke further bugs. A really silly variant
of this argument is ???we plan to make another release to customers soon. The outstanding bugs are
so deep in the system that the customers won??™t have had time to find them before we make the next
release.??? Result: when they fix the outstanding bugs they uncover/create further bugs which delay
the fix so long the customers have plenty of time to discover the original problem.
It would be nice to have the following tools:
??? Code coverage analyzer (see section D.10 in Appendix D) to allow you to see which lines of code
had been executed after some set of tests have been run.
??? Dynamic analysis tool (see section 7.9) to see what the code is doing, and allow you to advise
developers on which bits to optimize, and the testers on which features may contain the most bugs.
4.6.4 Management
??? Independence: The test manager must be functionally independent of development. Safety-critical
development standards emphasis this.
Pages:
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194