??? Read [Hooks] for an excellent and simple explanation of what happens if you don??™t write good
requirements specifications. Note the NASA diagram showing how failure to get the requirements
right leads to big cost overruns.
If people simply want to insist that requirements change and they must be free to change them
as the market evolves, then:
??? Remember that there has to be a cut-off date after which no changes can be made to a release
(if you are ever to test it sufficiently).
??? Ensure that there is someone tasked with both keeping the requirements up-to-date and
distributing copies to all stakeholders in a timely fashion (possibly someone with an interest
in keeping things up-to-date, like the testers).
Otherwise, do you really want to work for people so badly in need of taking Software Engineering 101?
19.
The testers never find the important bugs.
This is a serious criticism: if, despite having adequate
specifications, your team is failing to find serious bugs which users later discover, and you were
able to complete all your tests, either you or your team or both are no good. But take heart: at
least someone is worrying about bugs.
20.
The testers never find all the bugs anyway.
Probably true. To test such that every possible bug is
found would probably bankrupt the company. To test until every severity 1 or 2 bug is found and
fixed is essential. See Appendix C for a classification scheme.
Pages:
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91