Manage the Risks and the Process

Treating people fairly and building a strong team spirit make the difference when people are called on and asked for an extraordinary effort to resolve the crisis.

Pray for good fortune. We need all the good fortune we can get.

When Haste Can Make Waste
Despite the good intentions behind these ideas on how to speed the testing and development processes, unless we are careful they can be counterproductive. Just ask anybody who has installed the latest hot software product or product upgrade and lived to regret it.

In the words of James Bach: "Finding the important problems fast is about as axiomatic as it gets in this business." James is correct. The whole idea of risk prioritization is this: since we can't test everything, we have to perform triage. In this triage, the perceived risks and vulnerabilities of the system are used to focus the depth and intensity of the testing in the areas where the payoff in finding bugs is likely to happen most quickly.

Nevertheless, I have been around testing projects that were run with a "get the biggest bugs fast" philosophy, but that were ultimately less than successful.

The basic issue here is the short-term versus the long-term perspective of what constitutes success, like the tortoise and the hare. Imagine, for example, that a general before going into battle says to the assembled troops: "Find and kill the king first and then the most important enemy generals as soon as possible. And eliminate their most threatening warriors and leaders before we bother with the remainder who are the unmotivated followers."

It's a good strategy. If we want to win the battle, we would agree. Though the country where the battle occurs may be in ruins for decades after, and the victory could contribute to a new war against the resentful survivors in twenty years, that's totally irrelevant in the short-term view on the day of the battle. If we look at bug eradication as war, and many argue this is the only legitimate view, then this quick-kill approach is the one that we need to take.

Imagine another situation, a software development project where the team leader says: "Getting the most important software modules done as fast as possible is the most important thing in this project." We might choose as quality professionals to disagree with this statement, for several valid reasons.

On a software development project, these reasons can include concern that (a) the system design is not very good in the rush to code (for example, the opportunities to build in defect detection and recovery processes have been overlooked), (b) the apparently easy, minor, and simple software components might receive less care in their construction, (c) the system documentation may be a skimpy afterthought, (d) the system maintainability and potential to reuse components on other future projects may not be very good, and (e) items of importance to the user, such as the usability of the system, might be compromised in the rush to get the most important software modules done as fast as possible.

In testing projects, the attitude of "let's get the biggest bugs first and fastest" might lead to these side effects:

• There is little time to plan-we have to get going and find those bugs! In the long run, this means the testing may be more haphazard and possibly less reliable.
• There is evidence that with intuitive testing methods, the test coverage is likely to be unknown and overestimated: the actual coverage is much lower than what the testers think it is. See the discussion of the dismal results with