I know there are different factors that would make it higher or lower. I'm looking for a base percent to use for estimating the testing of the software.

I need to do this because testers/QA are often not consulted about the estimates used to bill customers for new projects they request: instead my employer uses a base percentage to come up with an estimate, so if the development team effort is estimated at 500 hours, the expected test/QA effort is set at 20% of development effort (100 hours).

I need a set of broad guidelines that my company can use to generate test estimates around these general principles:

  • A flat base percentage of development effort as a starting point
  • Any factors that would increase test effort and by how much (such as needing certification by a third party increases test effort by 50%)
  • Any factors that would decrease test effort and by how much (such as integrating an embedded component that can't be accessed by the test team)
  • Well it is hard to tell , As per my experience QA need at least 1/4 time for testing. For ex: if software is developed in 30 days then testing need at least 7 to 8 days. But still it is totally depends on requirements, deadline and many more factor affect here. Dec 22, 2015 at 5:22
  • its depend upon what methodology or model you are using, like agile ,waterfall,RAD etc Dec 22, 2015 at 6:53
  • If, for example a team never bothered with automation, they will in the end have to spend a huge proportion of effort testing for very little value. So time! = value, it depends.
    – Nathan
    Dec 22, 2015 at 8:55
  • @Shannon, I've expanded the question to aim more at the areas it looks like you're asking for
    – Kate Paulk
    Dec 22, 2015 at 13:18
  • 1
    "I need to do this because testers/QA are often not consulted about the estimates used to bill customers for new projects they request" = big mistake. Dec 22, 2015 at 13:27

4 Answers 4


It depends on the methodology of SDLC we are using, ex: if it is agile development with continuous-integration in place,then it should take 30 percent of development time.

Like 15 days development of sprint, then time taken for testing should be 4.5 working days, if key features of applications automated.

It also depends number of QA resources involved in testing.

  • How can you say that If it is Agile it should take 30% ? Which proportion testers developers are you considering? We not even know what kind of software they are developing. Dec 22, 2015 at 21:39

The short version: If possible go through your organization history and look at total test time for each project and total development time for each project. From this you can calculate the average and typical dev/test ratios.

The long version: It depends on the organization, the development methodology in use, and many other factors including how much legacy code is grandfathered into the application(s) the organization maintains and builds.

That said, there are a number of techniques that help to generate broad heuristics for first-pass test time estimates:

  • Historical Time Taken - As a rule, the typical dev/test time ratio in an organization is relatively stable. There will always be projects that fall outside the norms, but if you can data mine to retrieve actual dev time vs actual test time per project, the outliers become obvious.
  • Is it a Typical Project - A development project that is typical of the organization's projects is usually going to have an actual dev time vs test time ratio close to the organization's historical norm (if in your organization it's normal for testing to take about 1/2 the time development takes, then new projects that don't require anything unusual in dev or test will probably require testing to take about 1/2 the time development takes.
  • Are There External Dependencies - In my experience any dependencies outside the project team's control will increase the amount of test time required and increase the proportion of test time required. Most of this time will involve trying to determine whether that bug is with the third party software or your software (again, my experience only).
  • Potential Regression Impact - Any new feature has the potential to cause regression, but in large, complex applications, particularly applications with a lot of legacy code, there will be areas of the system that are more fragile than others. If the projects interacts with these, test time should increase by at least 50% (more if there is no automated regression around that part of the system). In extreme cases I've seen test time be estimated as much as 300 - 500% of development time.
  • How Automatable Is It - As a general rule new features should be added to automated regression, and the time required for this factored in to the estimates (in my experience this be can anything up to 100% of development time to the test effort depending on how well the automation is designed - I've added new feature support to automated regression with as little as an additional 10% of developer effort where it was a case of plugging in a new routine to handle the new flow, updating a few case statements, and adding some data to the test driver files and baseline files. I've also had to build completely new automated regression handling to cover gaps. The former takes a lot less time).
  • Does the Organization Include Automation Time - This is a big one. If the organization is unwilling to include time to update test automation to cover the new functionality, the ratio will be lower, but the maintenance and manual regression time in the future will be much higher and there's a significant risk of increasing issues with technical debt.

I need a set of broad guidelines that my company can use to generate test estimates around these general principles

Instead of trying to come up with magic formula factors, it would better to use historical estimates and actuals, tempered by smart people using their intelligence.

Find a past project that is similar to the new project.

Think about the factors that could make this project different, and how they apply to this new context.

Ask the people who will actually be charged with carrying out the work what they think.

Then make your estimate.

Too often, we crank projects through a guesstimation machine, then decide that the number is too high. We make up a number we think will sell, and hand over an untenable situation to the testers. Then we wonder why they can't hit the targets and become demoralized.


See: http://www.allthingsquality.com/2011/01/estimation-guesstimation-and.html


I always like to advocate my 33% rule for Agile software development.

The cycle contains three major parts (which should be executed in parallel if possible)

  • Requirements, design, user stories and other documentation
  • Coding (with SOLID patterns)
  • Testing (including unit-tests, integration tests, end-2-end tests and continuous-integration)

If you do not spend an average of 33% on each of the three groups you will create technical debt and should think about the long term consequences.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.