Coping with the Time Crunch
Coping with the Time Crunch
The single most common thing a tester has to deal with is being 'crunched' on time.
Because testing tends to be at the end of a development cycle it tends to get hit the worst by time
pressures. All kinds of things can conspire to mean you have lest time than you need. Here's a list
of the most common causes:
·
Dates slip things are delivered later than expected
·
You find more defects than you expected
·
Important people leave the company or go off sick
·
Someone moves the end date, or changes the underlying requirements the
software is supposed to fulfil
There are three basic ways to deal with this :
·
Work harder the least attractive and least intelligent alternative. Working
weekends or overtime can increase your productivity but will lead to burn out in
the team and probably compromise the effectiveness of their work.
·
Get more people also not particularly attractive. Throwing people at a problem
rarely speeds things up. New people need to be trained and managed and cause
additional communications complexity that gets worse the more you add (see
"The Mythical Man Month" by Frederick Brooks).
·
Prioritise we've already decided we can't test everything so maybe we can
make some intelligent decisions about what we test next? Test the riskiest things,
the things you think will be buggy, the things the developers think will be buggy,
the things with highest visibility or importance. Push secondary or 'safe' code to
one side to test if you have time later, but make everyone aware of what you're
doing otherwise you might end up being the only one held accountable when
buggy code is released to the customer.
The fourth and sneakiest way is also one of the best contingency.
At the start, when you estimate how long it is going to take you to test, add a little 'fat' to your
numbers. Then, when things go wrong as they invariably do, you will have some time up your sleeve
to claw things back.
Contingency can either be implicit (hidden) or explicit (planned in the schedule). This depends on
the maturity of your project management process. Since teams have a tendency to use all the time
available to them, it is often best to conceal it and roll it out only in an emergency.
29
