Test Estimation Techniques in Software Testing
Thomas Hamilton
⚡ Smart Summary
Software Test Estimation Techniques approximate how long testing will take and how much it will cost. A four-step process — break down tasks, assign owners, estimate effort, and validate with stakeholders — turns vague timelines into a defensible plan management can approve.
What is Software Test Estimation?
Software Test Estimation is a management activity that approximates how long a testing task will take and how much it will cost. Producing a credible test estimate is one of the most important responsibilities in test management because it drives schedule, budget, and resourcing decisions.
Why Test Estimation Matters
Clients always ask two questions before signing off a test engagement:
For small projects these questions are easy to answer. For a larger project — say testing the Guru99 Bank website — you need a structured technique to defend the answer.
What to Estimate?
- Resources: people, equipment, facilities, funding, and anything else required to deliver the work.
- Time: the most valuable resource on any project — every release has a deadline.
- Human skills: the knowledge and experience of the team. Stronger testers finish faster than a less experienced team.
- Cost: the project budget — how much money it takes to deliver the planned testing.
How to Estimate
The common software test estimation techniques are:
- Work Breakdown Structure (WBS).
- Three-Point estimation.
- Wideband Delphi.
- Function Point or Testing Point Analysis.
- Use-Case Point method.
- Percentage distribution.
- Ad-hoc method.
The four-step process below combines several techniques to arrive at a defensible estimate. The example uses the Guru99 Bank case study.
Step 1) Divide the whole project into sub-tasks
Use the Work Breakdown Structure technique to split a complex project into modules, sub-modules, and ultimately the smallest meaningful tasks. Estimates are far more reliable at the leaf level than against vague headline projects.
Apply the technique to break the Guru99 Bank project into five smaller tasks:
Each task is then split into sub-tasks until every line is detailed enough to estimate.
| Task | Sub-task |
|---|---|
| Analyse software requirement specification | Investigate the requirement specs. |
| Interview developers and other stakeholders to learn more about the website. | |
| Create the test specification | Design test scenarios. |
| Create test cases. | |
| Review and revise test cases. | |
| Execute the test cases | Build the test environment. |
| Execute the test cases. | |
| Review test execution results. | |
| Report the defects | Create the defect reports. |
| Report the defects. |
Step 2) Allocate each task to a team member
Assign every sub-task to the most suitable owner.
| Task | Owner |
|---|---|
| Analyse software requirement specification | All team members |
| Create the test specification | Tester / Test analyst |
| Build the test environment | Test administrator |
| Execute the test cases | Tester, test administrator |
| Report defects | Tester |
Step 3) Effort Estimation for Each Task
Two complementary techniques work well at this stage:
- Function Point Method.
- Three-Point Estimation.
Method 1) Function Point Method
The Test Manager estimates Size, Duration, and Cost for each task.
Step A) Estimate the size of the task
Take the task “Create the test specification”. Its size depends on the functional size of the system under test — the more functions, the more complex the system. Function points are typically classified into three groups: Complex, Medium, and Simple.
Based on complexity, the Test Manager assigns a weight to each function point:
| Group | Weighting |
|---|---|
| Complex | 5 |
| Medium | 3 |
| Simple | 1 |
The Guru99 Bank website is split into 12 function points. Their complexity is summarised below.
| # | Module | Applicable Roles | Description | Weighting |
|---|---|---|---|---|
| 1 | Balance Enquiry | Manager, Customer | Customer: view balance of own accounts only. Manager: view balance of every customer under supervision. |
3 |
| 2 | Fund Transfer | Manager, Customer | Customer: transfer funds from own account to any destination. Manager: transfer funds from any source to any destination. |
5 |
| 3 | Mini Statement | Manager, Customer | Last five transactions of an account. Customer: view own accounts only. Manager: view any account. |
3 |
| 4 | Customized Statement | Manager, Customer | Filtered transactions by date or value. Customer: own accounts only. Manager: any account. |
5 |
| 5 | Change Password | Manager, Customer | Customer: change own password. Manager: change own password (not the customer’s). |
1 |
| 6 | New Customer | Manager | Add and edit customer details (address, email, telephone). | 3 |
| 7 | New Account | Manager | Saving and Current accounts; a customer can hold multiple of each. Manager adds new accounts for existing customers. | 5 |
| 8 | Edit Account | Manager | Edit details of an existing account. | 1 |
| 9 | Delete Account | Manager | Delete an existing account for a customer. | 1 |
| 10 | Delete Customer | Manager | Delete a customer only when there are no active accounts. | 1 |
| 11 | Deposit | Manager | Deposit cash into any account at the branch. | 3 |
| 12 | Withdrawal | Manager | Withdraw cash from any account at the branch. | 3 |
Step B) Estimate duration for the task
Once complexity is set, estimate the duration required to test each group.
- Total Effort: total effort to test every function of the website.
- Total Function Points: total modules of the website.
- Estimate per Function Point: average effort per point; depends on team productivity.
Assume the team’s estimate per function point is 5 hours/point. The total effort for the Guru99 Bank example is:
| Group | Weighting | Function Points | Total |
|---|---|---|---|
| Complex | 5 | 3 | 15 |
| Medium | 3 | 5 | 15 |
| Simple | 1 | 4 | 4 |
| Function Total Points | 34 | ||
| Estimate per point | 5 | ||
| Total Estimated Effort (person-hours) | 170 | ||
The total effort to complete “Create the test specification” is around 170 person-hours. Once effort is known, you can assign resources to determine duration and cost.
Step C) Estimate the cost for the tasks
This step answers the second client question — “How much does it cost?”. Assume an average team rate of $5/hour. The task above takes 170 hours, so the cost is 170 × $5 = $850. Apply the same calculation across every WBS task to arrive at the project budget.
The more accurate the estimate, the better you can manage the project’s budget and ensure every dollar earns a return.
Method 2) Three-Point Estimation
Three-Point Estimation is a structured technique in which the Test Manager provides three values per task — the optimistic, most likely, and pessimistic effort — based on prior experience or best guesses.
For “Create the test specification” the three values might be:
- Best case: 120 person-hours (~15 days) with a strong, experienced team.
- Most likely: 170 person-hours (~21 days) with a typical team and resources.
- Worst case: 200 person-hours (~25 days) with a less experienced team and extra rework.
Compute the weighted average using the PERT-style formula:
The value E is the weighted average — the headline estimate for “Create the test specification”.
To express the confidence around E, compute the Standard Deviation:
For the Guru99 Bank example the estimate works out to 166.6 ± 13.33 person-hours — a range of 153.33 to 179.99 person-hours.
Step 4) Validate the estimation
Aggregate every task estimate from the WBS and submit the plan to the management board (CEO, project manager, key stakeholders) for review and approval.
Walk the board through the estimate logically so they understand the assumptions, the chosen techniques, and the contingency you built in.
Test Estimation Best Practices
Add buffer time
Plans rarely survive contact with reality — team members leave, tests take longer than expected, dependencies slip. Build a reasonable buffer into every estimate so the schedule absorbs minor surprises.
Plan for resource availability
Account for planned leave, training, and on-call rotations. Estimates that ignore availability look great on paper and collapse in delivery.
Use past experience as a reference
Historical data from similar projects is invaluable. If you tested a comparable website last year, learn from its actuals, the issues encountered, and the buffer that saved the day.
Stick to the estimate — but revisit it
Estimates are not contracts; they are best guesses. Revisit them at known milestones and adjust only when requirements change materially or new information shifts the picture. Negotiate any change with the customer transparently.
Software Test Estimation Template
Download the Software Test Estimation Excel (.xlsx)
Other Estimation Techniques
In addition to WBS, Function Point, and Three-Point estimation, several other techniques are widely used:
- Wideband Delphi: iterative consensus estimation by a panel of experts.
- Use-Case Point Method: derives effort from the number and complexity of use cases.
- Percentage Distribution: allocates a fixed percentage of total project effort to testing.
- Ad-hoc Method: expert judgement when historical data is missing.
Bottom-Up vs Top-Down Estimation
A practical view of estimation also breaks down into two complementary strategies:
- Bottom-up estimation: based on tasks at the lowest level of the WBS. Multiple stakeholders, experienced staff, and contributors combine their numbers to reach an accurate total. Ideal when the work is well understood.
- Top-down estimation: classifies the project by size and complexity and compares it with completed projects of similar shape. Also uses average effort per test case and scales by the projected number of cases. Useful early in a project when detail is scarce.
Most teams blend the two — top-down for the headline number, bottom-up for confidence — and overlay the result with sophisticated models when budgets justify the effort.
