Page 201 -

that a programmer could have just loaded the software into a debugger in the same envi-
ronment that the tester originally found it in, recreated the problem using the same test
data, and fixed it on the spot.
Another example of a grey area is a critical crash in the software that makes an important
feature of the software essentially impossible to use, and that is immediately apparent on
installation. For example, the crash may occur as soon as the feature is launched. This is a
common argument between programmers and testers: the tester immediately rejects the
build, but the programmer may insist that it was perfectly reasonable to send such a bro-
ken build to QA. What the programmer may not realize is that the tester may have spent
several hours setting up the test environment (imaging machines, redoing the network,
installing database software, etc.), only to abort the test within five minutes. And, because
the install has been done already, the entire environment will have to be done again. This
is clearly an inefficient use of time. The programmer could have taken a few minutes to
compile the build and launch the software—he would have found the problem immedi-
ately. This is why it is important that there are quality-related activities like unit tests and
smoke tests in place that are always performed by the programmer (and passed) before the
build is turned over to the testers.
Decisions about who is responsible for quality tasks should not be made based on an argu-
ment about who is responsible for what. It should not be about what programmers or
testers feel should or should not be in their job descriptions. Instead, the decision should
be made based on what is most efficient. If a task will take two hours for a programmer
but three days for a tester, then clearly that task should be assigned to the programmer.
This is why the project manager needs to have a solid understanding of what it is that the
testers do, and of what’s involved in setting up the test environment. That way, if there is
an argument about whether or not a programmer should take on a certain quality task,
the project manager can demonstrate why it is much more efficient for the programmer to
do so—or choose to assign the task to the tester, if that’s what makes sense. The most
important part of this is for the project manager to make optimal decisions that have the
smallest impact on the schedule.
Manage Time Pressure

The most common complaint about testing that project managers hear from senior man-
agers is that the testers are wasting time, when a build could be released today. It is often
very frustrating for a senior manager to hold a CD or see a web site that looks complete,
only to be told that he has to wait for the testers to finish their jobs. The features seem to
work, the software seems to do what it needs to do, and everything looks correct. Can’t
the software be rolled out now?
It is possible that even the very first build that gets created could be ready to be shipped
before a single test is executed. In fact, this is what the QA team is hoping for! If the team
did an excellent job of defect prevention through requirements gathering, unit testing,
inspections, and reviews, then it is possible that not a single defect will be found that is
serious enough to prevent the software from shipping. But it is very unlikely for this to be
the case; few (if any) experienced testers have seen this. It is much more likely that the

SOFTWARE TESTING 193