For the sorts
of figures and ???proof ??™ you need, look at section 4.6.
1
Specifications, manuals, and prototypes
: anything created to help build the deliverable.
Introduction
3
3.
It??™ll take too long.
This might be just ???
it costs too much
??? in another guise. The argument may be
couched in terms of
???getting the developers the information they need fast.???
In reality it doesn??™t
matter how fast you get the information to the programmers if most of it??™s missing because test
coverage was terrible. The question remains the same:
what is the risk
? Look at Chapter 3.
If, though, the complaint is that developers are told about bugs too late for them to be able to
fix in an agile manner, then it needs investigating. How long does it take you to run a full system
test (as a proportion of the time they spend building the software), and how good is your coverage?
4.
???Testing??? is never ready
. Often true. The test team which is ready for system test is one which has
had a stable and unchanging requirements specification 4 months before system testing was due
to start, and a stable test environment for 3 months beforehand (assuming it uses automated
tests). It is rare that requirements are so stable that every one is already covered by a test when
testing begins: often some tests are being written and reviewed while other tests are being run.
Yes, it??™s the customer??™s fault. What does that buy the test team? They just have to get ready as best
they can.
Pages:
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84