Page 202 -

tests will uncover a defect that the senior managers decide must be fixed before the soft-
ware is shipped. This is why testing tasks are necessary, and why the project manager
must fight for time to finish testing the software.
Testing tasks cannot be cut any more than programming tasks can. Yet, when the project
is late, senior managers and project stakeholders will often put a great deal of pressure on
the project manager to do exactly that. Sometimes they will insist that regression tests be
replaced with smoke tests (or cut entirely); other times, they will cut out environments,
performance tests, or other activities that are critical to ensuring the software functions. It
is the project manager’s responsibility to resist this and assure the quality of the software.

One way that software quality is often compromised through time pressure is by putting
pressure on testers to make overly aggressive estimates, and then to work overtime to
meet those estimates. This happens in testing more than it happens anywhere else in a
software organization, simply by virtue of the fact that testing activities are the last ones
performed on the project, and the fact that few people really understand what it is that
testers do. The key to avoiding this is for a project manager to use a repeatable estimation
process (see Chapter 3), to resist the urge to cut quality tasks from the schedule, and to
constantly stand up for the fact that the time that was estimated is what will actually be
needed to test the software.
For example, if it’s known that one iteration of regression tests takes three weeks, and the
stakeholders choose during triage to repair defects and cut a new build, then it must be
made clear to them that they are making the decision to spend three more weeks testing
the software. There are two options at that point: either release the software as is, or bite
the bullet and take the three weeks. One effective way to explain this is to point out that
had the last iteration of regression testing not been done, the team would not even know
about the defects that they want to fix, so not testing is a big risk.

Another common misguided request is that testers cut out any test cases that are not seen
as representative of typical user behavior. For example, in the test case example in
Table 8-2, the five bullet points in the requirement being tested require at least five differ-
ent test cases. A manager putting pressure on the tester may insist that only one of the
tests for that requirement be executed. Yet that manager would never go to the program-

mer and suggest that they only implement one of the five bullets. (This is especially likely
with negative cases and boundary cases.) The bottom line is that if a feature is important
enough to build, then it’s important enough to make sure that it works properly.

The project manager must fight for the estimated time frame. If the estimates are overly
aggressive and the testers need to work overtime to meet their own goal, that’s fine. The
testers should not have agreed to the inaccurate estimates. However, it’s important not to
routinely undercut the tester. It’s very common for a manager under pressure to require, for
example, that the testers come in on weekends to meet a deadline, or to arbitrarily cut down
the amount of time that it takes to run a regression test. This is unfair. It’s no different than
telling a programmer who needs three weeks to build a feature that she only has two.
Something will give and, in either of these cases, it will lead to problems with the software.

194 CHAPTER EIGHT