One Missing Factor in Test Estimation

Quick Testing Tips provides a handy list of factors you want to take into account when creating estimates.

The author leaves out one critical piece of the testing process, the biggest Sigma Eta Tau Phi (to use the QAic notation) that will ultimately determine the amount of time you need to spend in any test cycle completing a set number of tests on an application: the number of defects you find.

It’s very easy based on past experience to know how long it will take to perform certain operations and to write pass or fail in your Excel spreadsheet. However, encountering the bugs, backing up one, two, or three test conditions to recreate and confirm the existence of the bugs, and then creating a detailed defect report in the inexpensive, open source (and hence buggy) piece of .Net your organization installed could take the jackal’s share of the time. Also, much of the insect’s share.

That’s why I hate estimation, and try to give a range when estimating. Six Web pages with one form? Eight hours to infinity!

If you work with the same team doing the same kinds of work, I guess experience can help you dial into some scientific numbers. However, employee turnover, new technologies (read: unproven things your developers are learning on the fly), and differences in the applications or projects adds too much variation for me to make comfortable predictions.

You can’t have science without proper experiments, and IT development is all experiment group, no control group.

No Responses to “One Missing Factor in Test Estimation”

  1. strazzerj Says:

    Well said.

    Most of the time when you are asked for an estimate, they are really asking “When will you be done?”

    Without knowing what you will encounter as you test, that’s a pretty tough question to answer accurately. It’s guesstimate time…


wordpress visitors