Software Test Estimation Techniques (Test Effort Estimation Complete Guide)

For the success of any project, test estimation and proper execution is equally as important as the development cycle. Sticking to the estimation is very important to build a good reputation with the client.

Experience plays a major role in estimating the “Software Testing Efforts”. Working on varied projects helps us to prepare an accurate estimation of the testing cycle.

Obviously one cannot just blindly put some number of days for any testing task. Test estimation should be realistic and accurate.

This tutorial will include some important pointers that will be very helpful to prepare accurate test estimation in a very simple manner.

Software Test Estimation Techniques

Test Estimation Process

“Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.” [Reference: Wikipedia]

We all come across different tasks, duties and deadlines throughout our lives as professionals, now there are two approaches to find the solution to a problem.

The first approach is a reactive approach whereby we try to find a solution to the problem at hand only after it arrives.

In the second approach which can be called a Proactive Approach, we first prepare ourselves well before the problem arrives with our past experiences and then with our past experience, we try to find a solution to the challenge when it arrives.

Estimation can thus be considered as a technique that is applied when we take a proactive approach to the problem.

Thus Estimation can be used to predict how much effort with respect to time and cost would be required to complete a defined task. Once the testing team is able to make an estimate of the problem at hand, then it is easier for them to come up with a solution that would be optimum to the problem at hand.

The practice of estimation can then be defined more formally as an approximate computation of the probable cost of a piece of work.

Also, read => 7 Factors Affecting Test Estimation of Selenium Automation Project

Basic Pre-requisites

Given below are the Basic Prerequisites for the Test Estimation Process.

#1) Insights gathered from working with past experience: It is always a good practice to spend some time, recalling past projects which posed challenges similar to the current endeavor at hand.

#2) The available documents or artifacts: The test management repository tools come in handy in these types of scenarios as they store the requirements and clarification documents. These documents can be referred by the testing team to clearly define the scope of the project.

#3) Assumptions about the type of work: Past working experience helps in making assumptions about the project. This is where hiring experienced professionals matters most. Testing managers can pick the brains of these people to deliver the desired results.

#4) Calculation of Potential risks and Threats: The testing team also needs to visualize the potential risks and threats and pitfalls which lie may lie for the team in the future.

#5) Determining whether the documents have been baselined: The testing team also needs to determine if the requirements have been baselined or not. If the documents are not baselined then it is important to determine the frequency of the changes.

#6) All responsibilities and dependencies should be clear: The organization should clearly define the roles and responsibilities for all those who would be performing the estimation process.

#7) Documentation and tracking of the estimation records: All the relevant information to the estimation process should be documented.

#8) Activities to be performed during the test estimation process:

  • Organize a team that will perform estimations.
  • Decompose the project into project phases and subsequent constituent activities.
  • Compute the estimation based on previous projects and professional experience.
  • Prioritize possible threats and come up with approaches to mitigate those risks.
  • Review and document the relevant parts of the work.
  • Submit the work to the relevant stakeholders.

Most Prominent Test Estimation Techniques

Some of the most important techniques for test estimation are:

  • Test point estimation
  • Work-phase based estimation
  • Use case point estimation

How and where do we use these techniques:

#1) Test Point estimation is a simple and easily understandable estimation technique that is widely used across the software testing spectrum. Iterative phases and simplicity are the most important features of this particular technique.

#2) Work-phase based estimation is the estimation technique which is used whereby a guess estimate is made on a particular phase (normally the shortest and simplest of the phases) and then the testing team gradually adds on other phases into the initial estimation and finally comes up with an appropriate estimation.

#3) Use-Case Point estimation technique is the estimation on the use cases where the unadjusted actor weights and unadjusted use case weights are used to determine the software testing estimation.

Details of Test Point Estimation Technique

The test point estimation technique is done by following the steps listed below:

test point estimation technique

(The following weights, which may vary from project to project, could be considered under this paradigm – Some of these weights are the weights for the programming language based upon the complexity of the code, application weight based upon the type of application and test weights which are assigned based upon the different phases of software testing.)

Unprocessed Test Points are multiplied by CWF to obtain the testing size in the Test Point’s Size.

Productivity Factor indicates the amount of time for a test engineer to complete the testing of one Test Point.

Testing Effort in Person Hours is computed by multiplying the Test Point size by the Productivity factor.

For the computation of the test point estimation technique, we consider the following variables.

  • Test requirement complexity

Test requirement complexity

  • Interface with other requirements

Interface with other requirements

  • Total number of verification points

Total number of verification points

  • Baseline test data

Baseline test data

We then need to consider weight vectors for each of the data variables and organize them in the following manner.

weight vectors for the data variables

Adjustment factor = Average of (product of complexity weight and factor weight) / 30

Adjustment Test Point for Test case design = Total Test Point X (1 + Adjustment factor for Test Case design)

Adjusted Test Point for Test case execution = Total Test Point X (1 + Adjustment factor for Test Case execution)

Total Test Point (normalized) X (1 + Adjustment factor for Test Case design/execution) = Adjusted Test Point for Test Case design/execution

Total effort in Person Hours (PH) = Number of Normalized Test points / Productivity (in Normalized Test points per Person Hours)

Test Estimation Examples

Let’s try to apply the above formulation to another practical use.

Suppose we end up with a test requirement whereby we have 5 test scenarios to test.

Now let’s say Test scenario 1 has got 5 test expected results, test scenario 2 has 6 test expected results, test scenario 3 only 2 test expected results, test scenario 4 9 test expected results, test scenario 5 also 9 test expected results, respectively.

We classify the test scenarios in three classes i.e., complex, simple and moderate based upon the total number of expected results present in these three classes.

Complex classes will have more than 7 expected results whereas the simple ones will consist of less than 5 expected results and the moderate scenarios would consist of between 4 to 7 expected results.

We thus classify test scenario 1 and test scenario 2 as moderate scenarios, scenario 5 and scenario 6 as complex ones and test scenario 3 as simple.

We will now apply test points to all these scenarios. We applied 5 test points for complex classes, 3 for moderate ones and 2 for the simple scenarios.

We multiply the assumed test points with the total number of expected results in all these test scenarios. So we end up with the following approximations:

Scenario 1: 3 test points * 5 test expected results = Adjusted test points = 25
Scenario 2: 3 test points * 6 test expected results = Adjusted test points = 30
Scenario 3: 2 test points * 2 test expected results = Adjusted test points = 4
Scenario 4: 5 test points * 9 test expected results = Adjusted test points = 45
Scenario 5: 5 test points * 9 test expected results = Adjusted test points = 45

So considering that we need to apply for, say, 5 Person Hours for each adjusted test point we end up getting the following approximate result.

Test Scenario 1: 25 adjusted test points * 5 Person Hours = 125 Person Hours
Test Scenario 2: 30 adjusted test points * 5 Person Hours = 150 Person Hours
Test Scenario 3: 4 adjusted test points * 5 Person Hours= 20 Person Hours
Test Scenario 4: 45 adjusted test points * 5 Person Hours = 225 Person Hours
Test Scenario 5: 45 adjusted test points * 5 Person Hours = 225 Person Hours

So the total approximate person-hours is: 745 Person Hours

Use Case Point Estimation Method

Use-Case Point Method is based on the use cases where we calculate the overall test estimation effort based on the use cases or the requirements.

Given below is a detailed process of the use case point estimation method:

Use case point estimation method

An example of the same is that, in a particular requirement we have 5 use cases, use case 1, use case 2,…, use case 5 respectively. Now let us consider that use case 1 consists of 6 actors, use case 2 consists of 15 actors, use cases 3, 4 and 5, 3, 4 and 5 actors respectively.

We consider any use case which involves the total number of actors as less than 5 as negative, any use case with the total number of actors is equal to or more than 5 and less than or equal to 10 as positive and any use case with more than 10 actors as exceptional.

We decided to assign 2 points for the exceptional use cases, 1 for the positive ones and -1 for the negative ones.

Thus we categorize the use cases 1 and 5 as positive, use case 2 as exceptional and use case 3, 4 as negative respectively based on our above-stated assumptions.

So the Unprocessed actor weights = Use case 1 = (total number of actors) 5 * 1(the assigned point) = 5. Similarly

Use case 2 = 15 * 2 = 30 .

Repeating the process for the rest of the use cases we receive the Unprocessed actor weights = 33

Unprocessed use case weight = total no. of use cases = 5

Unprocessed use case point = Unadjusted actor weights + Unadjusted use case weight = 33 + 5 = 38

Processed use case point = 38 * [0.65+ (0.01 * 50] = 26.7 or 28 Person Hours approximately

Work-Phase Breakdown Technique

The work phase breakdown technique can be described in the following steps.

  • Break down the overall work into phases.
  • Start with the simplest phase and assign an approximate estimation value to it.
  • Then proceed with identifying the next possible phase which can be commenced once this phase is completed.
  • Derive a possible set of approximation values that could be applied to this phase and choose the maximum value amongst all the derived approximation values.
  • Sum up the approximated estimation value by adding the current phase effort estimation value to the already existing value.
  • Continue with steps 3 to 5 until all the phases identified in the first step are exhausted.
  • Accept the final approximate estimate value as the ultimate.

Suppose in a requirement there are 5 required phases. In the initial phase 1, we assume that the total effort needed is 35 person-hours and then we commence the next phase 2 for which we have 4 comparative assumptions of 35, 45, 55 and 65 respectively.

We consider the 65 person-hours which is the maximum value here. In phase 3 , 4 ,5 we come up with estimates (12 , 33, 43 , 54) , (15 , 10 , 7 , 8) and (2 , 16 , 5 , 13) respectively. By applying the said principle we end up with 185 Person Hours respectively.

I am putting information on – How to estimate testing efforts for any testing task, which I learned from my experience.

9 General Tips on How to Estimate Testing Time Accurately

Factors Affecting Software Test Estimation, and General Tips to Estimate Accurately:

#1) Think of Some Buffer Time: The estimation should include some buffer. But do not add a buffer, which is not realistic. Having a buffer in the estimation enables us to cope with any delays that may occur. Having a buffer also helps to ensure maximum test coverage.

#2) Consider the Bug Cycle: The test estimation also includes the bug cycle.  The actual test cycle may take more days than estimated.

To avoid this, we should consider the fact that the test cycle depends on the stability of the build. If the build is not stable, then developers may need more time to fix it and obviously, the testing cycle gets extended automatically.

#3) Availability of All the Resources for Estimated Period: The test estimation should consider all the leaves planned by the team members (typically long leaves) in the next few weeks or next few months. This will ensure that the estimations are realistic.

The estimation should consider some fixed number of resources for a test cycle. If the number of resources reduces then the estimation should be re-visited and updated accordingly.

#4) Can We Do Parallel Testing? Do you have any previous versions of the same product so that you can compare the output? If yes, then this can make your testing task a bit easier. You should think about the estimation based on your product version.

#5) Estimations Can Go Wrong – So re-visit the estimations frequently in initial stages before you commit it: In the early stages, we should frequently re-visit the test estimations and make modifications if needed. We should not extend the estimation once we freeze it unless there are major changes in requirements.

#6) Think of Your Past Experience to Make Judgments! Experiences from past projects play a vital role while preparing time estimates. We can try to avoid all the difficulties or issues that were faced in past projects. We can analyze how the previous estimates were and how much they helped to deliver the product on time.

#7) Consider the Scope of Project: Know what is the end objective of the project and list of all the final deliverables. Factors to be considered for small and large projects differ a lot. Large projects typically include setting up a testbed, generating test data, test scripts, etc.

Hence the estimations should be based on all these factors. Whereas for small projects, typically the test cycle includes test case writing, execution and regression.

#8) Are You Going to Perform Load Testing? If you need to put considerable time into performance testing then estimate accordingly. Estimations for projects that involve load testing should be considered differently.

#9) Do You Know Your Team? If you know the strengths and weaknesses of individuals working in your team then you can estimate testing tasks more precisely. While estimating one should consider the fact that not all resources may yield the same productivity level.

Some people can execute faster when compared to others. Though this is not a major factor, it adds up to the total delay in deliverables.


Software test estimation is a practice that requires the involvement of experienced professionals as well as the introduction of industry-wide best practices like test case point and use case point methods.

It is also important to adopt an open mind for customizing the required processes. The successful implementation of these processes leads to an overall improvement in the testing process.

This is a guest article by Author “N. Sandhya Rani”.

Recommended Reading

71 thoughts on “Software Test Estimation Techniques (Test Effort Estimation Complete Guide)”

  1. I agree with Smruti points while estimation. We can consider few more depends on your project
    6. Browser compability
    7. Security testing(basic security detail testing based on SOW)
    8. Flow of the system


  2. Adding to the above discussion – Time for Compatibility should be calculated, whether it is OS or Browser compatibility

  3. Hi,

    Informative article. There is a lot of practicality in tips given.
    My viewpoint given below hopefully adds value….
    Add buffer time:- I believe, this is required to absorb the foreseen and unforeseen risks during planning and execution of test efforts. Previous experience with the older version of the product helps here. Buffer time can be added to estimates, as risk management effort in consent with client. We need to convince client about the risks foreseen based on the previous project experience. Client might say yes if the buffer time added is realistic. For e.g. if offshore team is working on a project, then remote connectivity might slow down the pace of execution or cause downtime if getting disrupted. The previous experience may count here and can be added as buffer time for an activity.E.g. test case execution time increased by some factor if done offshore.
    Talking to team who has worked upon the previous project version adds value by coming up with foreseen risks.
    To stick to estimated and agreed timelines, I believe, it requires:-
    1) Team co-ordination with dedication
    2)Continuous monitoring of progress on project activities
    3)Client support for achieving the goal of the project
    4)Sustained motivation of team members
    5)Monitoring of risks encountered and corrective actions
    And the list goes on…..:)

  4. If 100 test cases are there.. How do we estimate ?
    Question : – 1. how to we calculate effort estimation for test designing.
    Question : 2- How do we calculate effort estimation for test execution.

  5. Thanks Sandhya,
    Really Nice article..
    By which we can consider the points while preparing the estimate.
    And agree to Amit too…It took long time to read all the comments than the actual topic. :)

  6. I wanted to bring to your attention that in agile methodology, the estimation technique could be your past experience because once the sprint plan is published than those resources will be engaged till the release of the project so there capacity of 160 hrs (4 weeks) by default is charged till project ends. So number of resources can be considered based on estimation and then there loading will be default 160 hrs till project ends.

  7. In order to gain knowledge on the estimation process, I think we need to revisit once the project is complete to compare the estimated value Vs Actual value. This would give us the confirmation whether we are on the right track or should we work on the estimation to include or exclude certain factors.

  8. @All,

    By going through the article, it gives an idea more of pre-requsites before starting an estimation fo the testing effort.
    The article gives provide checklist which needs to be considered while doing estimations.

    I would request Sandhya to come up with more elaborative estimation techiniques that would be helpful for the new joiners who would be insterested in estimations.

    Regarding Comments from ALL: I would appeal to the community to rather provide valueable inputs on the topic as per their experience and help All in this initiative rather finding faults and ego hurtings….

  9. Just two cents from my side:
    Disclaimer: I am just mentioning my own experience of evaluating testing efforts for any project. It may not suite someone and may make sense for others. Please ignore, if my post does not help anyone.

    @Pradeep Soundararajan: I really liked your post on your blog site :)

    Factors affecting Testing Estimates

    1) What is the total development time for that particular feature. Development time actually guides two things; (A) Complexity of Application / Feature and (B) Development Length of the Application or Feature. We consider approximately 20% as testing time for an application which takes 2 – 3 man months for development.

    2) An application above 3 months of development time shall have 2% added for testing over and above 20%, for every one months of effort being added in development. This is needed to do multiple regressions of the builds.

    3) We spend 3% of testing time in writing test plan and acceptance test cases.

    4) We spend 5% of testing time in writing Bug Reports. Thus leaving 12% of time for actual functional testing for an application of length of 2 – 3 man months.

    5) If Automation is included then writing acceptance test scripts will take additional 5% of time over 20%.

    6) Who is the development team certainly matters for us. If any less experienced developer is scheduled to work on a module, we increase the testing time to certain extent. Estimates for that depends on my past experience with that development team.

    7) Are we using any established CMS for building the website. If yes, then we reduce the testing efforts from 20% to 18% or so, though this decision totally depends on the complexity of the project.

  10. In my experience, some time must be allowed for out-of-the-box testing, that is, subjecting the product to random scenarios that are spontaneously thought of by the Test team. This process helps the Test Engineer/Analyst to break free from the mould of the test cases, process etc and authentically attempt to break the product. A previous assignment I had worked on scheduled this random testing procedure by the entire test team. The result was some hidden defects that test cases could not uncover.

  11. Sandya – Your article is simple and practical.

    Estimations should always be given practically. Its not a good practice to rely on theory concepts (formulas). Formula based estimates fails most of the times because those are made with fixed set of rules. Rather we can use these formulas as a base reference to compare with our Customized estimates.

    Clients will always like commitment. They will be happy to see if our actual outcome is quite near to estimated hours.

    @ Mr.Pradeep Soundararajan – It seems you are studying a lot than thinking practical. Please come to practical world man.

    Google Inc

  12. Hi,
    Very good article!
    For the people who actually provide estimates on recurrent bases your article makes sense.

    For the once that didn’t read the ISTQB Foundation syllabus it might be a bit difficult to comprehend that estimating your own work is something that is based solely by work experience. If you work and you are keeping an eye on metrics you will know how long it will take you to test a certain item.
    In order to make it simple i use to brake the system in a list of testing targets/areas [at high level at first] then i re-view the list with the production team/testing stakeholders, then i take each item and think to a use case which will exercise that item, and then i think how long it will take me to execute that use case, add 20% buffer, and multiply with the number of test session i think i will need to perform on each environment = High Level Estimates.
    When the project development progresses and more information is available, i make a risk analysis on each item and i develop more use cases for the high risk areas. Based on that i update the High Level Estimates and communicate to the PM. If the estimated time exceeds the project plan, then i do an assessment with the PM and the Dev Lead to optimize the tests [bsed on risk priority or other conventions].

    Hope it helps!


  13. @Pradeep Soundararajan – you Sir need to learn how to provide feedback. Bullying someone with good intentions is not doing you any good.

    You can be as good as it gets on your domain (which i doubt it since professionals never brag about themselves) but without knowing how to communicate your ideas in a diplomatic and proactive manner it makes you worthless within your organization.

    In this case, i would prefer to have in my team a junior with good intentions than an expert with a bad attitude.

  14. Agree with @Pradeep Soundararajan –

    I am not totally agree with point “Sticking to the estimation is very important to build good reputation with the client.”

    Before writing the article please make sure that you are not spreading the wrong information.

    I am not asking you to stop writing but keep in mind that spreading correct message to the world.

    – Iyer Swami

  15. In one of the interview, panelist asked me a question. how do we estimates when the requirement itself is not clear /not given. Thanks in advance.

  16. @Amit I agree with your comments, this article is simple and conveys the idea.
    @Amit good comment on Pradeep Soundarajan’s comment.

    @ Pradeep Soudararajan

    In our own words “Please be more valuable to the community of software testers.” It applies to you too. Why do you keep bringing cricket example in testing? Testing is not a game Sir, so stop quoting examples from cricket….

    For your other comment

    “at least discuss it with people like me who would test your ideas up front before you consider writing more.”

    You lack communication skill, that is all I can say…

  17. Good Article!
    I would add a line item called “Humanize” to the textbook effort estimation methods and bring all these points under that line item. It is because of certain people like that I observed in the comments here who blindly followed the text book methods and abused the writer, engineers working at the task level spend sleepless nights and their weekends working at office.

  18. Hi Sandhya,

    Above all thanks a lot for these tips/guardrails for estimating test efforts.

    The following three points which you mentioned in your article are the ones where all estimations went wrong and we need to work overtime, on weekends on holidays to fix it right – to maintain a good business relation with our clients, and relentlessly to say project level escalations if it goes beyond the testing budget in a fix-bid project:

    – Buffer Time
    – Considering the Bug Lifecycle – this includes defects retesting, regression and smoke testing time frames
    – Considering the different forms of testing beforehand as per the client requirements (viz. Performance/Automation/Security/Localization (language based)/Environment Compatibility testings

    Apart from the above mentioned points the taking into consideration the availability of resources (expertise in the testing project technology) is also recommended – say the tool used is PEGA BPM but currently there are only 1 resource expertise in that tool from testing domain but the requirement is for 4, so the rest 3 we need to hire and its a long time process, its good to know beforehand to plan accordingly.

    Moreover, the one you mentioned are not any technique for testing effort estimation rather some best pratices to make it better, to ensure a successful quality delivery of a project and certainly increasing the revenue of the company for that FY by getting more testing projects.

    Debojit Das


Leave a Comment