You need to determine the amount
of extra work some requirement change will cost because you have to write extra tests for
it. Even if the developers cannot imagine the effect of a change, you can. Managing
requirements changes simply requires that you declare that there are times when changes
can be made economically, and times when they can??™t. Create time windows wherein
changes can be accepted, and deadlines by when they must be agreed. Assess every change
against a schedule, and keep the price of change firmly in front of the project manager.
Conflicts between users/users with
negative attitudes towards the
project
The underlying causes of these are usually political, with group A believing that the system
will somehow cause them some slippage downwards with respect to group B. The
ostensible basis of such a conflict may be objectively determinable such as ???
(the proposed
system) doesn??™t give us what we need
.??? In this case the test group can either take details, or
show group A their fears are met by some set of tests.
Users not committed to the project If project management suspects some user group of being less than committed, the test
group can become a litmus test by requesting help from that user group in determining
the everyday use of the system.
High level of technical complexity The wise project manager will choose a strategy involving prototypes and single-thread
integration. The wise test manager will encourage this and make test staff available to create
informal test fragments to test prototypes.
Pages:
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145