Process · Test Estimation
Estimate testing the way projects actually work.WBS, schedule, budget, approval, in that order.
Test estimates fail either because they skip the work breakdown or because they skip stakeholder buy-in. This process does both, in sequence, so the resulting schedule and budget survive contact with management.
- Sub-steps
- 20
- Deliverables
- WBS, schedule, budget
- Output gate
- Management commitment
An estimate without a work breakdown is a guess. A work breakdown without stakeholder review is a fantasy. Both fail for different reasons; this process solves both.
Key takeaways
Four things to remember.
01
Decompose until tasks are real
Each leaf task must be measurable, have start and end criteria, one responsible owner, and a bounded duration. If it does not, keep decomposing.
02
Sanity check at every level
Subtask, task, activity, phase. Compare against prior project data and industry metrics. Document discrepancies instead of smoothing them over.
03
Review with owners and with the team
Hidden assumptions and dependencies surface in conversation, not in spreadsheets. Walk the WBS with the people who will own each task.
04
Earn commitment by negotiating scope
When management will not fund the full estimate, negotiate which testing to drop, not how fast to go. Scope conversations are honest; velocity conversations are not.
Why this exists
The problem this process fixes.
Most test estimates arrive at management as a single number, with no breakdown, no assumptions, no linkage to risk. They get cut in half. The team spends the rest of the project explaining why the half that remained was not enough.
This process produces an estimate that resists that fate. It forces explicit decomposition, sanity checks against prior data, and an iterative negotiation with management about scope rather than velocity.
The checklist
23 steps, in order.
- Phase 1
Working one-on-one or as a group with the assigned test team, develop the work-breakdown-structure and estimated schedule.
- 1.A
Decompose the test project into phases.
- 1.B
Decompose each phase into constituent activities.
- 1.C
Decompose each activity into tasks and subtasks until each task or subtask at the lowest level of composition satisfies the criteria below.
- 1.D
Taking risk priority into account, set up dependencies, resource assignments, and dependent tasks internal to the test subproject. Document dependencies, resources, and tasks external to the test subproject (i.e., those that involve collaborative processes).
- 1.E
Sanity check the durations and efforts at the subtask, task, activity, and phase levels. If possible, augment professional judgment and gut instinct with previous project data, industry metrics, and so forth. Identify and, if possible, resolve discrepancies between the test subproject schedule and the project schedule. Where discrepancies cannot be resolved, document the obstacles.
- 1.F
Review the work-breakdown-structure and schedule with the individuals to whom you've assigned responsibility for each task, taking special care to surface any hidden assumptions or dependencies.
- 1.G
Review the work-breakdown-structure and schedule with the entire test team along with any subject matter experts available within or outside your organization.
- Phase 2
Use the work-breakdown-structure and schedule to develop a budget.
- 2.A
Extract from your work-breakdown-structure a complete list of resources. For each resource, determine the first and last day of assignment to the project. If you have resources shared across multiple test projects within a given time period, understand the percentage allocation of each resource's assignment to each project during various time periods.
- 2.B
Identify any incidental resources required to support these resources.
- 2.C
Categorize the resources into staff, travel, tools, test environments, and, if applicable, outsourcing costs. Total by time periods and categories.
- 2.D
Sanity check the budget details and totals. If possible, augment your professional judgment and gut instinct with previous project data, industry metrics, and so forth. Identify and, if possible, resolve discrepancies between the test subproject budget and the overall budget. Should resolution prove impossible, document the obstacles.
- 2.E
Amortize budget items that are long-term investments, documenting the reuse opportunities and the period of time over which you expect to recoup the costs.
- 2.F
If required or desirable, analyze return on investment. If the return on investment is negative, review your assumptions about amortization in 2.E and repeat this step if necessary. If the return on investment remains negative, review those items on your estimated work-breakdown-structure that consume the most money while contributing the least return, tracing back to the quality risks. Document the money losing activities.
- 2.G
If permitted by your management, review the budget with your test team. Take special care to identify any missing resources, especially incidental ones. Iterate steps 2.D through 2.F if necessary.
- Phase 3
Obtain management support for the estimated schedule and budget.
- 3.A
Present the benefits of the test subproject.
- 3.B
Outline the time and money commitment required to receive those specific benefits.
- 3.C
Understand and attempt to resolve any objections to the estimate through iteration of steps 3.A and 3.B.
- 3.D
If management commitment to the proposed budget and schedule cannot be gained, discuss specific areas of testing to be deleted, setting cost and/or schedule goals to be met to obtain management support.
- 4
Repeat steps 1 through 3 if necessary, fine-tuning the estimated schedule and budget, until resources and management commitment adequate to the (possibly adjusted) scope of the test effort are secured.
- 5
Check the approved budget and schedule documents into the project library or configuration management system. Place the document under change control
One more thing
In a well-formed WBS, each leaf task has: measurable status, clear start and end criteria, one or more deliverables, resource and duration estimates, short duration, independence from other tasks, one responsible owner, a mapping to the quality risks, and a position in the schedule aligned to risk priority. Anything less and the estimate will not survive the first change request.
Take it with you
Download the piece you just read.
The library is free. Tell us who you are so we can send you updated versions. One form; this browser remembers you after that.
In the library
Pair this with.
Process · The Master Framework
Four phases, applied in order, every project.
The top-level testing process used on every engagement. Four phases contain twelve sub-processes, each of which is documented in its own checklist in this library.
Read →Process · Quality Risk Analysis
Prioritize risk before you prioritize tests.
Testing without a prioritized quality risk analysis is testing by politics. This six-step process produces a risk register with explicit stakeholder consensus, the basis for every downstream testing decision.
Read →Process · Team Building
Hire deliberately. Grow people continuously.
The test team is the product. This process structures hiring as a reversible, repeatable loop and pairs it with an always-on skills and career-path program.
Read →
Keep reading
Related reading
- Primer
Careers in Software Quality: Roles, Skills, and First Steps
What testers, test automation engineers, quality engineers, and test managers actually do, the skills each role uses, and practical first steps for students and career changers, including the ISTQB Foundation certification.
Read → - Primer
Errors, Defects, and Failures: What a Bug Really Is
Everyone says 'bug', but testers use three precise words: error, defect, and failure. Learn the difference, why it matters, and how severity and priority decide which problems get fixed first.
Read → - Primer
How Software Gets Attacked: Common Vulnerabilities in Plain English
The most common ways attackers break into software, explained without jargon: trusting input, broken access control, weak sign-in, misconfiguration, and outdated components. Each one comes with the defense that stops it.
Read → - Primer
How to Report a Bug So It Actually Gets Fixed
Finding a bug is half the job. Learn how to write a bug report a developer can act on: a clear summary, exact steps to reproduce, expected versus actual results, and the habits professional testers use to make every report count.
Read → - Primer
Security Testing Basics: Finding Weaknesses Before Attackers Do
An introduction to security testing for new testers and developers: thinking in threats, designing abuse cases, testing access control, the role of automated scanners and penetration tests, and the rules that keep security testing legal and ethical.
Read → - Primer
Staying Safe Online: Passwords, Sign-In, Phishing, and Updates
The everyday security habits that stop most attacks: strong unique passwords, multi-factor sign-in, spotting phishing, keeping devices updated, and sharing carefully. Written for students, families, and anyone starting out.
Read →
Practices
Where this leads
- QA & testingSoftware testing
Software quality consulting since 1994: we test the releases that matter, coach your team on the method, and measure how its testing matures.
Book a call →