"How much time do you need to check this feature?" — a question you'll hear within your first weeks on the job. Answering "I don't know" is not an option; answering at random is dangerous: the release will be planned around your estimate. Effort estimation is a skill nobody teaches at school, but it trains like a muscle. Let's break down how to answer this question deliberately.

Any estimate beats no estimate

The beginner's first fear: "I've never done this — how can I estimate it?" You can. Even if you're off by several times, you gain experience: next time a similar task will be estimated more accurately. An estimate that doesn't exist gives you nothing; an estimate that missed gives you calibration material.

The second rule: an estimate must be defensible. Not in the sense of "always write out the details," but "be ready to explain why exactly this much." Thinking through the arguments, you understand the work itself better — and often correct the estimate before you've even voiced it. And if the person assigning the task dislikes your estimate, you'll have something to defend it with.

Optimism is ruinous

People systematically underestimate unfamiliar tasks. But even having sized the work itself accurately, beginners forget something else: you won't be able to spend 100% of your working time on the task. Email, meetings, colleagues' questions, reading documentation, sudden urgencies — all of it eats the day. The practical rule: out of eight working hours, no more than six actually go to the assigned task. Estimated the work at 12 hours of pure time? That's two full days, not a day and a half.

The second correction is a buffer for the unforeseen. The longer the horizon, the bigger the buffer: from 5–10% for near-term tasks to 30–40% for distant forecasts. A buffer is not "inflate the estimate several times just in case": deliberate inflation destroys trust just as chronic optimism does.

And the third: learn your personal distortion factor. Most people consistently err in one direction — some always underestimate, some overestimate. Comparing your estimates against reality time after time, you'll notice the pattern ("I underestimate by about 1.3×") — and will be able to apply the correction.

How to learn: estimate everything

The simple way to learn estimation is to estimate. The training algorithm:

  1. Form an estimate. However crude — at first it just has to exist.
  2. Write it down. In writing, always: otherwise memory will helpfully whisper "well, that's roughly what I thought."
  3. Do the work at your normal pace, without bending yourself to fit the estimate.
  4. Compare the actual result with the estimate.
  5. Analyze the deviation: not just "off by a third," but what exactly caused it.

Repeat on anything: how long a new route home will take, reading a book, clearing your inbox. The cost of a mistake in training is zero, while the experience you accumulate is real.

Decomposition: from the "elephant" to estimable tasks

A big piece of work ("test the payment module") can't be estimated in one go — it must be broken into parts, each of which you can see whole. In project management this is called a work breakdown structure. For testing the path is:

  1. Break the requirements down to a level where a checklist can be written.
  2. For each checklist item, estimate the number of cases and "tester actions": write the cases, execute them, file bugs.
  3. Account for repeat passes: some cases will find defects, and after the fixes they'll have to be executed again. A rough guide: simple functionality — 1–1.5 passes, medium — 2, complex — 3–5.
  4. Multiply by the time per action — taken from your own productivity.

Your own productivity can't be computed by a formula — only measured: track how many cases you write and execute per day or week. The longer the measurement period, the more accurate the number — all the distracting factors are already "baked in." A stylized example: over a month a tester wrote 300 cases and executed 1000 — so their speed is roughly 1.4 cases per hour for writing and 4.5 for execution. Now the estimate "22 cases with 1.2 passes" turns into concrete hours — and into an honest answer of "two days with a margin."

Where this applies

Estimation is needed not once a year at big planning sessions but weekly: taking a task into a sprint, promising a verification date, answering the manager's "will we make Friday?" And one rule on top of all the arithmetic: realized you won't make it — say so immediately. Warning the team two days ahead gives colleagues a chance to adjust; a "surprise" on deadline day creates a problem for everyone.

Where beginners stumble:

  • They estimate pure time and call it a deadline. 12 hours of work is not "tomorrow by lunch" but two working days: the rest gets eaten by meetings and correspondence.
  • They're afraid to name an estimate ("what if I'm wrong"). You will be wrong — and that's fine: a recorded miss calibrates the next estimate.
  • They bend the work to match the named figure — speeding up or stretching out. In training this breaks calibration: work at your normal pace.

What to learn next. Decomposition rests on checklists and test cases; where the estimate fits into the overall picture of the work — in the test plan article; how to report actual results — in the reporting and metrics article.