An Especially Bad Case Of Estimation Gone Awry
Last year a convenience store near my house burned down. After a very long time (the insurance took forever to come through I guess) the wreckage was cleared away and a new building started going up. The exterior walls were done in a flash but the rest seemed to drag on and on. Finally a sign went up last September announcing "Opening late November". Ah - just in time for Thanksgiving!
Except November came and went and construction still wasn't finished. Exterior signs went up, came back down, then went up again. As I walked to the bus each morning I saw equipment and supplies being unloaded and worker bees swarming industriously, but the work didn't seem anywhere close to being finished.
In February they took the sign down.
Here it is mid-April - some seven months after "RTM" - and the store still isn't open.
Many people don't recognize that estimation skills are just as important for testers as they are for developers. Sometimes this is because testing is just a token bit of time between the developers "finishing" and management deciding it's time to ship, and so estimates are a waste of time. Other times it's because the testers don't have a plan and instead bang away until they "have a good feeling" about the application. And often it's because the estimates testers produce are wildly inaccurate.
Estimating accurately is enormously difficult - I would go so far as to say impossible. Joel Spolsky's article Painless Software Schedules is a good starting point. Steve McConnell's new book Software Estimation is packed with useful information as well. Working in an agile fashion helps. My favorite technique, however, is having the entire feature team - developer, tester, program manager, and whoever else is involved in getting the feature built - work together to estimate *all* the costs of delivering the feature - specing it, coding it, testing it, documenting it, etc etc. All of that work is necessary in order to get the feature out the door, so it all needs to be considered when deciding how, when, and whether to build it.
Management may still ignore your estimate, but at least this way you have people with whom to commiserate. <g/>
*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great coding skills required.
