4 and section 8.2.1, and Do It Yourself.
3.
Baselines.
Have we identified the baseline documents (or whatever)?
a. Who owns them?
b. Are they going to change?
c. How much warning will we get before they change?
d. Are they sufficient for use as a baseline?
e. Have we reviewed them?
f. Have we fed our review comments back to the owner?
A faulty or missing baseline is the first sign that things will go wrong. Another is that the
document (or whatever) is insufficient for testing against. ???
Bang the table???
by reviewing whatever
is there and commenting clearly and succinctly on its shortcomings. This is not simply selfprotection,
but a wake-up call to management that there are going to be problems.
Testers need to be in the requirements loop. Having the test team review all the requirements
is one of the smartest things management can do. The test team need those specifications, are
going to use those specifications, and will be more likely than developers to find fault with them.
They need to review all the changes, too. The person who says, ???
I can??™t see any reference to X???
is
on the way to earning a year??™s salary by seeing a problem now rather than just before the system
testing started.
4.
Existing systems.
Sometimes a system is built to replace another. The old system may be all you
get to use as a baseline. If so, write a requirements specification as discussed in Chapter 8.
5.
Real-world data.
Pages:
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124