"How long will testing take?" — giving estimates without digging your own grave

End of sprint planning, everyone’s tired, and the PM turns to you: “So how long will testing take?” And you say “well, about two days” — off the top of your head, quickly, so you don’t look like the person dragging out the meeting. From there, two scenarios, both bad: either you work evenings stretching reality to fit your number, or you explain why you “promised two days and are still testing on day four.”

The most annoying part: the number you produced in three seconds then lives for weeks. It lands in the release plan and in stakeholders’ expectations, and when something goes wrong, the conversation starts with it: “but you said two days yourself.” Here’s how I stopped giving numbers off the top of my head — and what I say instead.

Why test estimation is a special genre

A developer estimates their own work: here’s the task, here’s the code to write. QA has it worse: we estimate the quality of someone else’s work that doesn’t exist yet.

How long testing a feature takes depends less on the feature and more on the state it arrives in. If it comes in clean — you’re done in a day. If it comes with a dozen bugs — you’re not testing, you’re spinning in a “bug → fix → retest → new bug” loop. You don’t know how many bugs there will be. Nor how many fix iterations. So the honest answer to “how long will testing take?” is “depends on what you hand me.” But nobody accepts that answer, so you need a way to give a number without signing off on risks you don’t control.

An estimate is a forecast with assumptions, not a promise

The main thing I changed: I stopped saying the number separately from its assumptions. Not “two days,” but “two days if the build arrives Wednesday, if there are no more than two fix iterations, if payments weren’t touched.” A number without assumptions is your signature under risks you don’t manage.

Martin Fowler has a good note on the purpose of estimation: an estimate exists not to predict the future but to make a decision. The team doesn’t need the “correct” number — it needs to understand whether you’ll make the date, what to cut, where the risk is. Once you see estimates that way, the fear of “being wrong” lets go: you’re not a fortune teller, you’re giving the business data for a decision.

Decomposition instead of a single number

“Testing the feature” is an unestimatable blob — too big. I break it into parts that can each be estimated:

preparation: test cases, test data, environments, access;
the first pass over the new functionality;
regression around it — what the feature could have touched;
bugfix retests — the part people forget most often;
automation, if it’s in scope.

My rule for retests: each bugfix iteration is not “check the fix in five minutes,” it’s a retest plus a mini-regression around the fix, because fixes break neighboring things. If experience with this team says there are usually two or three iterations — they belong in the estimate as an explicit line item, not as a surprise on day three.

The second pillar is history. The best predictor isn’t intuition — it’s the last similar release: how long it took in fact, not from memory (memory lies optimistically) but from the tracker. If a similar feature took four days with two fix iterations last time — why would this one take two?

Three points instead of one

When uncertainty is high, I give a range instead of a single number: an optimistic estimate (everything clean on the first pass), a realistic one (the usual amount of bugs and iterations), and a pessimistic one (build arrives late, lots of bugs, more affected than it seemed). That’s classic three-point estimation — there’s even the PERT formula (O + 4M + P) / 6, but the formula isn’t the point. The point is that a range honestly communicates the uncertainty a single number hides. “Two to five days, most likely three” tells the team far more than a confident “three days,” after which day four looks like your personal failure.

The buffer: not “×2 just in case” but named risks

Everyone knows the trick: “estimate, then multiply by two.” The problem is that an anonymous buffer gets cut first: “why is this so big? let’s trim it.” And rightly so — an unjustified number can’t be defended.

So my buffer is always named: “+1 day if the build lands later than Wednesday,” “+half a day if the changes touch the payment flow,” “+1 day for a second fix iteration — the last release had one.” A named risk can’t be silently crossed out — it can only be consciously accepted: “okay, the build will definitely be there Wednesday, remove that day.” Great — that’s not trimming the estimate anymore, that’s removing a risk. A completely different conversation.

When your time gets cut

And it will get cut. “There’s no two days for testing, there’s one” — sound familiar? Two traps here: silently agreeing (and taking the entire risk onto yourself) or going “then I’m not responsible for anything” (and souring the relationship).

I do it differently — I negotiate scope, not quality: “In one day I’ll cover payments and the main scenario. Localization and edge cases will go unverified — if something surfaces there in production, we’ll hear it from users. Do we accept that risk?” And here’s the key part: accepting a risk is a business decision, not mine, and it should be in writing. One message in the release channel: what was verified, what wasn’t, what the risk is, who made the call. Not to rub anyone’s nose in it later, but so the risk decision is made consciously by whoever owns it — not silently dumped on QA by default. How to phrase these things without panic or resentment — I covered in the post on delivering bad news to stakeholders.

Antipatterns I’ve been through

A number off the top of your head to look confident. The confidence lasts until the first missed deadline, and a reputation of “gives dates and misses them” is the worst thing QA can have in a team’s eyes. Paradoxically, “I need half an hour with the requirements, then I’ll tell you” sounds more professional than an instant “two days.”

A silent “okay” to a cut. If the time was cut but scope and risks weren’t re-negotiated — you just silently took someone else’s risk onto yourself.

“Testing ends when the bugs end.” Sounds principled, but it’s not an estimate — it’s a refusal to have the conversation. The bugs will never end; the real answer lives in exit criteria: what must be verified and what must not be broken for the release to ship.

Confusing “I’ll spend three days” with “it’ll be done in three days.” Three days of pure work turns into a calendar week: waiting for the build, waiting for fixes, parallel tasks, the developer’s sprint review. People usually ask about the calendar — and we often answer about effort. Say explicitly which one you mean.

Estimating before seeing the requirements. “Roughly how long?” for a feature that’s one ticket title is fortune telling. The minimum worth negotiating: half an hour to read the requirements and ask two questions. The estimate after that will be different — and it will be yours.

Checklist before you say a number

I’ve seen the requirements, not just the ticket title
The estimate is decomposed: prep / first pass / regression / fix retests
Bugfix iterations are explicitly included (based on team history, not hope)
There’s a similar past release to sanity-check against — actuals from the tracker, not memory
Instead of one number — a range, or a number with assumptions
The buffer is named: which risk, what it costs
It’s clear what I’m quoting: effort or calendar time
If the time gets cut — I know what drops out of scope and who accepts the risk

The number you say is the only thing everyone will hear and write down. The assumptions it depends on are the only thing that will save you later. Never say one without the other.