HOW LONG DOES IT TAKE TO CATCH A FISH?

- An Arsenal of Bad Answers –


I tried to not pick up my pen – really I did… I battled with it for an entire week. But I cannot resist the call any longer. I promised myself a long time ago that I would NOT NOT NOT make comments on Michael Bolton’s articles. I’ve told myself that if I start down that road, my entire existence might end up consisting of nothing but pathetic and futile counterpoints to someone else’s warped perceptions of What is Right.

If you are reading this you must, you positively MUST, go read Michael Bolton’s article on stickyminds.com called “An Arsenal of Answers”. I believe he had the balls to put it under management.

The original concept – the question to be answered – was how long it would take to test a given product or projects. To sum up 3 pages of Boltonese, the answer is “I don’t know”, with a dash of “it’s not my responsibility” thrown in.

And an eager commenter tells him he’s covered one of the hottest topics in testing in a brilliant way. And that testing never ends. It just gets transferred to the customer. Uh-huh. Maybe that’s what happens to your customers…

I think what bothered me the most about this article is that NO ONE CHALLENGED IT. Granted, it could be that some people have already had the inestimable pleasure of attempting to argue with Michael Bolton and found it to be akin to arguing with a particularly pompous piece of igneous rock, but c’mon – are you all going to allow those kinds of statements to stand on stickyminds.com?

So back to the article. Michael said the manager might REALLY be asking:

When will the testers be able to declare the product ready to ship?
When should I ship the product?
How much time would you like to have to test the product?
What can we do to speed up testing?
When will we know we’ve found the most important problems?
How long should the test phase last?

Answers to these were that the testers won’t be able to declare the product ready to ship, that the product could be shipped whenever they like, that we’d like as much time as they’ll give us for testing, that we won’t know when we’ve found the most important problems, and that there is no such thing as a test phase.

Um, maybe, just maybe, someone is asking you how long it’s going to take you to do your job. And if YOU don’t know, how in hell do you expect THEM to know? Virtually the only advantage to passing off your estimation and scheduling responsibilities off to someone who has never done your work is that you can point fingers at them later when you run out of time or do a poor job.

Most project managers or management personnel are going to find the virtual answer of “How long does it take to catch a fish?” to be both unprofessional and frustrating. They aren’t looking for philosophical dissertations. They’re looking for rough timeframes. Give them some. If you cannot at the very least give estimates based on past experience, then your best bet is to inform your clients you don't know how long it takes you, or your team, to do their work. That you can't tell when the most important problems have been found. That you don't know what a test phase is.

Look, everyone on a project feeds into the initial project plan/schedule. Developers have to give estimates. DBAs have to give estimates. Architects have to give estimates.

YOU have to give estimates. The elements of your job are no more ephemeral or difficult to pin down than any else’s. I get really tired of the whiny ridiculousness of how impossible it is to nail down the elements of our jobs. Art vs. science. Actually, a lot of the stuff going around now makes it seem more like magic. What a crock. Sure, you can't guarantee you'll find one error every 32.5 minutes. But if you're experienced, you can ESTIMATE how long it'll take you to test a new screen, feature, or system.

Overall, you're in QA/QC, dammit. Be brave.

Get over yourself. Be a grownup. Commit…..