How to estimate test effort

Estimating the test effort

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email
Share on reddit
Share on tumblr


How would you like to have all the software testing knowledge you need in one comprehensive eBook to transform your career?

Regardless of the software testing technique or techniques used, the Test Manager must incorporate that software testing technique into the project and software test process. During test analysis, test design and test implementation, the allocation and prioritization determined during test planning must be applied even though this is a common breakdown in the test process for analysis and/or modeling to occur. From this point the question appears on how to estimate test effort. Without doing this, a test manager cannot handle the process of estimating the test effort in software testing.

Test effort estimation involves predicting the amount of test-related work needed in order to meet the objectives of testing a project, release or iteration leadership and is also one of the software testing basics for the test manager. Factors influencing the test effort may include:

  • Product characteristics
  • Development process characteristics
  • People characteristics
  • Test results

Two of the most commonly software testing techniques on how to estimate  test effort are:

  • metrics-based technique: estimating the test effort based on metrics of former similar projects, or based on typical values
  • expert-based technique: estimating the test effort based on the experience of the owners of the testing tasks or by experts

In Agile development, burn down charts are examples of the metrics-based approach as effort is being captured and reported. Then used to feed into the team’s velocity to determine the amount of work the team can do in the next iteration.

Within sequential projects, defect removal models are examples of the metrics-based approach, where volumes of defects and time to remove them are captured and reported. This provides a basis for estimating future projects of a similar nature.

Test Estimation Best Practices

Some general tips would be:

  • Add some buffer time as many unpredictable things may happen. This will help you cope when such events occur
  • Account resource planning in estimation like holidays, leave of absence and your teams or interdependent teams availability
  • Use past experience as reference as these play a vital role while preparing good estimates due to possible similarities cross projects, products, organization or even industry
  • Stick to your estimate as it may go wrong, especially in the early stages of the project, but will require constant re-check and make modifications when needed (major change, assumptions are different, etc.)

Work Breakdown Structures (WBS)

WBS focuses on breaking down the test project into small pieces which are then allocated to team members and effort is estimated for each task. At the end of this exercises, the effort estimation is validated prior to final confirmation. By doing this, the test manager is properly estimating the test effort.

  1. Divide the whole project into small pieces
  2. Allocate each task to team member
  3. Effort estimation for tasks
  4. Validate the estimation

1. Divide the whole project into small pieces

WBS - divide the project

2. Allocate each task to a team member

WBS - allocate the task

3. Effort estimation for tasks via the Function Point Method

A. Estimate the size of the task

  • size of the task depends on the actual size of the system under test
  • the size reflects the amount of functionality that is relevant to the user (higher number the more complex the system is)
  • Divide functional points into 3 groups to finish the task

WBS - effort estimate

  • based on each group, the Test manager has to give enough weight age to each module
  • more complex the function point, more effort is required to test it

B. Estimate duration of the task

  • after classifying the complexity, estimate the duration to test them
  • Duration = how much time needed to finish the task

WBS - effort estimate 2

  • Total Effort = effort to completely test everything
  • Total Function Points = total modules
  • Estimate per function point = average effort to complete testing for one function point. Depends on productivity of the member in charge

The end result will look something like:

WBS - end result

This will translate in the total effort required for the task to be 170 man-hours.

Once this is determined, the Test Manager should assign resources to determine how long the task will take and this will depend on the team’s experience.

C. Estimate cost for the tasks

  • This will help answer the question: how much does it cost?
  • The cost per hour should be multiplied with the effort estimate and then an overall view should be calculated for the overall WBS budget

4. Validate the estimate

  • Once you create an aggregate estimate for all testing tasks, this will be forwarded and presented to the stakeholders that will review and approve it
  • You may explain to them your estimation logically and reasonably so that they can approve your estimation plan

This article is based on the ISTQB Advanced Syllabus version 2012 and it also references the ISTQB Foundation Syllabus version 2018. It uses terminology definitions from the ISTQB Glossary version 3.2.

Follow & Subscribe

Get updates and learn from the best

Test Conditions

Test Conditions

Software test conditions are part of testing basics and represent an item or event of a component or system that could be verified.

Read More »

A Test Manager's Guide

Whether you want to be a better test manager, or gain useful knowledge of the software testing as a whole, A Test Manager's Guide is the software testing book for you.

A Test Managers Guide

How would you like to have all the software testing knowledge you need in one comprehensive book?