How do you estimate testing effort?

I combine a work breakdown with three-point estimates, then sanity-check the result.

1. List the tasks. For a feature, that’s more than running tests:

• understanding the story and asking questions;
• test design: scenarios, cases, charters, the regression set;
• environment and test data setup;
• execution on each device or browser we test on;
• bug reports and follow-up;
• retesting fixes and regression around them, usually in more than one round;
• status updates and the summary;
• a visible buffer for late builds and blockers.

2. Three numbers per task. Optimistic, most likely and pessimistic. The PERT formula (O + 4M + P) / 6 gives an expected value; the sums of O and P give a range.

3. Cross-check. How long did something similar take last time? Some teams also compare with the dev estimate using their own historical ratio, but only as a check: a small change to payments can need far more testing than a big text change.

4. Say it with assumptions. “About five days, three to eight, assuming the build is on staging Monday and we test on four phones.” Rounded, with a range, never “28.17 hours”.

5. Re-estimate as soon as scope or an assumption changes, and compare estimate with actual afterwards so the next one is better.

In scrum teams the whole team often estimates stories in story points with planning poker. There, my job is to make the testing part visible: devices, data, payment sandboxes, risky integrations.

Learn more: Estimating Testing Effort