Effort Estimation in Testing

← back to the section

On Monday the manager asks: "How long do you need for points payment?" You run it through your head — open the cart, switch redemption on, look at the total — well, a day. The manager writes it down: testing finishes on Tuesday.

On Tuesday it is not finished, and on Wednesday it is not either: the developer was fixing rounding, a new build arrived, and everything you went through on Monday had to be gone through again. On Thursday it turns out that points break order cancellation — another half a day. You worked four days and wasted not a single hour, but the word said on Monday was untrue, and the release was planned around that word.

"I'll check it in a day": a day is one pass

When you answer "a day", a short film plays in your head: you enter the shop, put an order together, switch redemption on, look at the total. The film lasts minutes, the work it describes lasts hours, and one pass really does fit into a day. Testing just does not end with that pass.

Defects are the norm: each one has to be reproduced again, described, given a screenshot and a build number — 15–20 minutes apiece. After the fix a new build arrives and is walked through again: a rounding fix touches the order total, and the total is card payment, the customer email and the refund. How many such rounds there will be is unknown in advance, but a rough guide works: a simple feature — one pass and a bit, a medium one — two, a money-related one — three and up. Add the beginning and the tail: read the requirement, break it into checks, order the data, and at the end write the result down. So "a day" is the estimate of one pass along the happy path: one row out of eight got counted.

Paying with points: 18 hours part by part

Let us cost out a real task: BON-7 — points can cover no more than half the order total, 1 point = 1 unit of currency. It came out as 18 checks: redemption at checkout, partial redemption, the half-the-total limit, and the refund of points when an order is cancelled.

• Read the requirement — 2 h. The task, the mock-up, a question for the analyst: a balance larger than half the order — round up or down (requirements review)?
• Write 18 checks — 3 h. A checklist plus four detailed cases for the money-related situations; the number of checks is the size of the task.
• Prepare the data — 2 h. A customer with 500 points, orders of 600, 3400 and 12 000 (different classes against the limit), a test card. The cancellation data is prepared by another team: not your hours, but your date.
• First pass — 4 h. Eighteen checks at 12 minutes each, including the time to work out whether it is a defect or you set something up wrong.
• File defects — 1.5 h. About four bug reports at 20 minutes plus the conversations with the developer.
• Three rebuilds — 3 h. Rounding, then the half-the-total limit, then the refund — and each time you re-check the fix and what sits next to it.
• Regression around — 1.5 h. Card payment, the cart total, the receipt email: neighbours are picked by connection, not "just in case".
• Report and the release conversation — 1 h.

That is 18 hours of clean work — the very task a day was promised for: the promised day would have gone entirely into "first pass", after which testing only starts. A broken-down estimate is discussed line by line: drop regression around and that is ninety minutes less plus the risk of breaking card payment; cut the rebuilds and that means agreeing that fixes come in batches.

Hours of work and days on the calendar are different numbers

You added the hours up and got 18 — and it is easy to say "that's a bit over two days". But a working day also holds meetings, questions in the chat, helping a colleague: no more than six hours out of eight go to the assigned task, so 18 hours is three working days.

Hence the habit: quote hours and work the date out separately. Hours describe the volume of work; the date is a commitment, and it includes what is not yours — when the build arrives, when someone prepares the customer for the cancellation case, how long the analyst takes. It sounds like this: "There's 18 hours of work, three of my days; I start when build 4.18 is on the environment; I need the cancellation data by Wednesday or that part moves out."

Where the numbers come from: analogy and three points

Where did "4 hours for the first pass" and "20 minutes per defect" come from? From last time: the actual cost of a similar task already has baked in what intuition forgets — your speed, the slow environment, your team's habit of fixing defects in batches. For estimating by analogy to work you need a recorded fact (what the task was, what you quoted, what it came out at, why they differed) and similarity by traits rather than by topic: not "also about payments", but the same number of screens and roles, the same order of magnitude of checks, money touched the same way. Then the correction out loud: "last time it took 14 hours, here there are five more checks and a refund — so about 18." A dozen records will also show your own bias, something like "I underestimate by half".

One number says nothing about how sure you are: "three days" after half an hour of analysis and "three days" off the top of your head sound the same. So you give three: optimistic — 2 days (two defects, both fixed in one build), realistic — 3, pessimistic — 4.5 (the data arrives on Thursday, one defect is a blocker). The weighted average is the three-point estimate: the extremes once each, the realistic one four times, divided by six — (2 + 4×3 + 4.5) / 6 ≈ 3.1 days. The team hears the realistic number and the condition that leads to the pessimistic one: "Three days; if the cancellation data is not ready by Wednesday, four and a half" — and that risk goes into the risks of the test plan. A spread of two to one is itself a signal that you do not know something about the task, and an hour of analysis helps more than any formula.

The margin for the unknown — and what it is not

An estimate is made when the least is known about the task, and something always comes up: if not a defect then an environment taken by another team, if not that then a requirement that changed on Wednesday. That gap is covered by a margin — it is about the unknown that exists statistically, not about "what if I am slow".

The size depends on how well you know the territory: a feature you have tested three times needs 10 %, an unfamiliar area with a new payment gateway 30–40 %, and the further the horizon the bigger the margin. The main rule is that it has to be visible: a hidden margin ("I'll say four days though I counted three") breaks trust just like chronic optimism — the team starts dividing your numbers by one and a half. A visible one sounds like a condition: "Three days; if something we cannot see right now comes up, three and a half." And it is added once: if the rebuilds and the defects already carry a margin and then you multiply the total by 1.5, you have counted the unknown twice.

Talking about the date: set for you, or slipping

"The release is on Friday, you have two days" — the date is announced, and your eighteen hours will not change it. "I won't make it" gives the manager no decision; something else does: "In two days I'll cover redemption and the half-the-total limit — 12 checks out of 18. The refund on cancellation and cart regression will stay unchecked; cancellation is a money scenario, I would not leave it out." What will be done, what will not, and what it costs are all named: the manager still decides, but now with open eyes. The order of cutting is set by risk: money, irreversible actions and frequent scenarios first, rare and cosmetic ones last. And the agreement is written down — in a week nobody will remember that cancellation was deliberately skipped.

Changing your own estimate as you go is normal; staying silent until the last day is not. Renegotiating is fair in two cases: the scope changed ("take a look at delivery while you're at it" — the answer is not "no" and not "fine", but "delivery instead of what, or does the date move?"), and the unknown surfaced beyond what the margin covered. Speak in numbers: "11 of the 18 checks are done, four cancellation checks stuck behind a blocker that has been with the developer since Tuesday; if the fix lands today, I finish tomorrow at midday." Then the team has a choice: add a second person, postpone a part, ship without cancellation. And do not squeeze the work to fit the number you named: rushing to hit "two days" means testing worse, and the recorded fact comes out dishonest.

In short

• "I'll check it in a day" is the estimate of one pass along the happy path; the work also holds reading the requirement, writing the checks, the data, defects, re-checks after fixes, regression around and the report.
• The number of rebuilds is a decision, not a fact: a simple feature — one pass and a bit, a medium one — two, a money-related one — three and up.
• No more than six hours out of eight go to the task, so 18 hours of work is three working days. Quote hours and work the date out separately.
• Analogy needs a recorded fact — quoted, actual, why they differed — and similarity by traits rather than by topic.
• Three points show confidence as well as time; a wide spread between the extremes means you do not know the task.
• The margin is visible and added once: 10 % for familiar ground, 30–40 % for unfamiliar. To a date set from above the answer is not "I won't make it" but "this fits, this stays unchecked".

What to read next

• Test plan and test suites — where the list you are costing comes from, and how risks are written down.
• Checklists and test data — how to break a feature into checks and what data preparation involves.
• Test result reporting — the numbers that measure the actual cost and back a renegotiated date.
• QA in Agile and Scrum — where estimates are heard every week and how they reach the sprint plan.