How to Estimate Testing Effort: QA Planning Guide

The two-day estimate omitted half the work

A team estimated “two days of QA” for a subscription upgrade. The number covered executing happy-path cases in one browser. It did not cover clarifying proration rules, creating billing accounts, waiting for a deploy, validating webhook retries, retesting fixes, or checking the existing cancellation flow. On day two, execution was only beginning.

The failure was not inaccurate arithmetic. The estimate described the wrong unit of work.

A useful testing estimate states what will be delivered, under which assumptions, with what uncertainty. Begin with an evidence outcome such as:

Now stakeholders can challenge the boundary. “Test the story” cannot support that conversation.

Fix the scope boundary before calculating

Collect the smallest input set that exposes complexity:

• acceptance examples and unresolved business rules
• changed services, interfaces, schemas, flags, and shared components
• supported browsers, devices, locales, roles, and payment types
• required test levels, including API, integration, UI, accessibility, and exploratory work
• existing automation and reusable data
• environment availability and deployment cadence
• release date, rollback options, and impact of failure

Mark each item as known, assumed, or unresolved. An unresolved tax rule is not a testing task yet, but it can delay design and cause rework. Put it in the estimate as uncertainty with an owner and decision date.

Separate included work from excluded work. If performance, security, production verification, or a legacy browser is out of scope, say so. Exclusion is a planning decision, not a footnote added after time runs out.

Also define the completion point. Does the estimate end after the first execution, after one defect-retest cycle, or after release support? Teams often agree on the start and silently disagree on the finish.

Decompose effort into observable work packages

Estimate activities that produce artifacts or decisions. A practical breakdown is:

Then split by feature risk or technical boundary. “Execution: 18 hours” is hard to defend. “Invoice upgrade cases: 4 hours, including currency and failed webhook recovery” can be reviewed by the service owner.

Avoid estimating case count before designing the cases. Ten end-to-end scenarios can require more setup than a hundred pure validation checks. Use the driver that controls effort: data combinations, environment transitions, interfaces, devices, or stateful workflows.

Automation is not simply execution multiplied by a scripting factor. Include framework discovery, testability changes, data APIs, code review, CI diagnosis, and initial stabilization. Reusing a sound fixture may make a new check small; introducing a new identity provider may make a short scenario expensive.

Use team evidence instead of universal rates

Historical work is useful only when the comparison is explicit. Find two or three completed changes with similar interfaces, risk, and delivery conditions. Compare planned and actual effort by work package, not just total days.

For each analogue, ask:

• Did the requirements stabilize at the same point?
• Was the tester familiar with the domain?
• Were fixtures and automation already available?
• How many candidate builds required retesting?
• Did waiting time reduce productive capacity?
• Which omitted activity caused the variance?

Use a range when evidence varies. A three-point estimate records optimistic, most likely, and pessimistic effort for a package. The values are reasoned scenarios, not confidence theater:

• optimistic: expected inputs arrive and the first candidate is testable
• most likely: normal clarification and one correction cycle occur
• pessimistic: the named dependency or integration risk materializes

If the organization has little history, run a short discovery spike. Measuring one representative data setup and one automation path is better than debating abstract productivity.

Model rework and uncertainty visibly

Keep base work, expected rework, and contingency separate. One understandable model is:

Total effort = base activities + expected correction cycles + explicit contingency

Base activities include work expected even when the implementation is correct. Correction cycles include defect investigation, retest, and affected regression. Contingency covers named uncertainty that cannot yet be resolved.

Do not add a hidden percentage to every line. Link contingency to a risk:

Calendar delay and effort are different. Waiting two days for an environment may consume one hour of QA effort but move the finish date by two days. Report both. Otherwise managers may assume adding another tester removes a dependency delay.

Contingency is not capacity to spend on unrelated scope. When a risk expires, return the reserve or consciously trade it for new work.

Work a scenario from inputs to range

Consider an illustrative subscription change handled by one tester with developer support. After discovery, the team creates this estimate:

The values are not a benchmark. They show the conversation. The pessimistic setup value is high because the payment sandbox has a known reliability risk. The correction range is wide because the change spans billing and entitlement ownership.

The team publishes 50 hours as the most likely effort, plus the optimistic and pessimistic totals of 32 and 80 hours. It does not convert 50 hours directly into “six days.” First it accounts for meetings, support duty, code review availability, and sequencing.

The estimate also carries assumptions: the API contract is final by Monday, a deployable build arrives Tuesday morning, two currencies are included, and load testing is excluded. If any assumption changes, the number is reopened.

Convert effort into a feasible schedule

Capacity is not headcount multiplied by eight hours. For each person, subtract known ceremonies, leave, production support, and work already committed. Then map dependencies and skills.

Some tasks can run in parallel: fixture preparation and test design, or UI automation and API exploration. Others cannot: retesting waits for a fix; final visual evidence waits for stable content; a single shared account may serialize scenarios.

Build a short schedule with milestones:

1. risk and rules agreed
2. data and environment proven
3. first candidate assessed
4. high-risk coverage complete
5. correction cycle complete
6. release recommendation issued

Give each milestone a date range and prerequisite. A finish range is more honest than a precise date built on unresolved inputs.

Adding people helps only when work is separable and onboarding cost is low. Two testers cannot safely halve a stateful end-to-end flow if they share one sandbox and one specialist reviewer. They may still improve throughput by splitting API evidence, browser coverage, and defect reproduction.

Re-estimate from actual progress, not percentage complete

At the first daily checkpoint, compare completed outputs with assumptions. “Testing is 60 percent complete” says little when the remaining work contains the riskiest integration.

Report:

• packages completed and evidence available
• packages remaining with updated ranges
• assumptions that changed
• new defects and expected correction effect
• current blocking dependency and schedule impact
• scope options if the release date cannot move

When time compresses, trade coverage by risk. Options might include deferring a low-use browser, replacing broad regression with targeted automated evidence, or moving a reversible feature behind a flag. Never quietly reduce the stated outcome while keeping the original confidence claim.

After release, compare estimate and actual by package. Record why variance occurred: missing scope, wrong complexity, unavailable environment, excessive correction cycles, or inefficient test design. Update the analogue library and team rates. Do not punish accurate reporting of newly discovered work.

The mature outcome is not estimates that always match actual hours. It is early visibility into what controls the range, fast revision when inputs change, and a release conversation where cost, schedule, and residual quality risk are all visible.