Note that testers will be writing a version of the requirements in the form of their test
objectives. If the requirements are unclear to them, they will be unclear to the
developers, the technical writers, the support team, and the users.
Conflicting system requirements The test group is one of the best placed to identify these early. See the story in section 4.43.
Undefined project success criteria Insofar as a test group is there to answer questions, defining the project success criteria is
a primary task for them. See section 4.18.
Unrealistic schedules and budgets Complaining that a 500 man-day project has allowed 5 man-days for system-test
preparation and execution will not make you loved, but at least this way no one can
complain you didn??™t warn them, and you??™ll have time to prepare your exit. A closelyreasoned
memo to the project manager may be just what he needs to subtly deflect the
blame from himself (???
and then of course the testers always say they need more time
???), and
still render the schedule a little less suicidal.
Failure to gain user involvement This calls for award-winning levels of tact. Talking directly to users can upset the marketing
people (???
We talk to clients
???), the project manager (???
No one talks to clients without my
approval
???), and the client (???
I??™m not having my staff being upset by a lot of silly questions. . .
???).
If in doubt back off. But if there??™s resistance at the client end this is an indicator that
something??™s wrong with the relationship, and if you are to be sure to test the system exactly
as the client??™s staff use it??¦
Continuous requirement changes As with the unrealistic schedules and budgets this is an area where some project managers
need the moral support of an unhappy test manager.
Pages:
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144