??“ Were expected to both find the bugs, and identify them in the code so the developers merely
had to make the change. (If true, immediately refuse to continue such a policy. Its purpose is
simply to inhibit testers from finding problems. Developers are far better placed to know which
pieces of code are likely to contribute to a problem or even which features were, er, left unfinished.)
??“ Were unable or unwilling to examine scripts in an effort to determine likely sources of bugs
??? The tests:
??“ Did not cover all the features of the product
??“ Were not configuration-managed
??“ Were unrelated to the release they were used on
??“ Were not prioritized or related to the risks the project ran
??? The users are in revolt.
See also the checklist in section B.7 in Appendix B.
4.6 Arguments You Need to Win
These are so obvious you may feel they??™re not worth raising. Surely no company would be so silly??¦
4.6.1 General
??? Assess the risk to the company of the system failing and get a test budget which reflects this risk.
??? Get an agreement between testers, developers, and management:
??“ On the classification of bugs, their priorities, and severities
??“ On test priorities (limits the occurrence of the question ???why didn??™t we find this bug earlier????)
??“ On the maximum number of each kind of bug which can remain in a released system (and
yes, this means it can??™t be released if this is exceeded)
??“ On the baseline against which testers test
??“ On the amount of unit testing to be done and who will do it
6 Best said privately to a stressed test manager struggling with a complete lack of specifications and a thoroughlybuggy
release in which anyone can find bugs.
Pages:
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190