The obvious
classifications are: Critical, High, Medium, and Trivial. OK, what do they mean? Does Critical
mean that the customer loses data or that an operator loses their life? Does High just mean Critical
(but there??™s a workaround)? It would be good to ensure the developers have some basis for
determining the fix priority too. See Appendix C for a classification scheme but remember that
what matters in the end is how a bug will be perceived by the end user.
??? Authority over the testing staff. This isn??™t obvious either. Those organizations which operate by
feature teams may pride themselves on their intellectual agility because each team is equipped
with a business analyst, some programmers, a lead, and a tester. It can be a good way to work.
But when a release is made it is imperative that the distributed testers work as a team to test that
release, exchange ideas between themselves, and are not distracted by pleas from the developers
to test some newly-fixed bug. See section 9.3.
??? Access to statistics: people will ask you questions such as those in section 1.4 and you need to be
able to get answers based on statistics gleaned from the code (the configuration management
tool), the bug tracking tool, and the test management tool.
4.6.3 Test Environment
You must have a stable test environment with the following tools:
??? Bug-management tool (otherwise it will be impossible to discuss bugs let alone fix them).
Pages:
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192