Prev | Current Page 70 | Next

Peter Farrell-Vinay

"Manage Software Testing"

So there are many politically-adept people
ready with plausible arguments explaining why testing can be reduced, curtailed, or its implications
glossed-over. Here are some of their favorites, followed by a possible rebuttal or work-around. If you
think such politically-adept people are really too dim to bother with, then either you??™ve just left university,
have led a very cloistered life, or have only worked for really great companies.
1.
We don??™t need that level of testing
. Whatever that level of testing is, they don??™t want it. Perhaps
because it??™ll show that the product, or system is bug-ridden, and their job is on the line, alternatively
that it??™ll delay release, and they??™d rather (very temporarily) satisfy a customer (and their
boss) with a timely release than a usable one.
But there are limits to testing, and perhaps your boss knows what they are better than you. Ask
yourself: is the thing I want to test essential? Will a failure matter? Is a failure probable? Is the risk
low-probability/high-consequence? It is better to be boring and explicit than to assume. Remember
the level of testing should always relate to the risk the product or system poses to all the stakeholders.
Put together the case as shown in section 1.5.
2.
It costs too much
. The issue is simply how much they will pay to manage a risk. The risk might
be somewhere between
???will we have any (more) customers if this release fails????
and
???is it worth
spending one more week to find bugs when the few we have found in the last 3 weeks were trivial
????
See Chapter 3.


Pages:
58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82