Manage Learn to apply best practices and optimize your operations.

How to estimate for testing on a new software project

What do you do if you have a new project and no historical data for reference, and you need to estimate for software testing? Test experts Karen N. Johnson and Mike Kelly explain.

What do you do if you have a brand-new project, you have no historical data for reference, and you need to estimate...

for software testing? Test experts Karen N. Johnson and Mike Kelly tackled that question from their recent webcast, "How to plan your software tests."

There are a number of methods for estimating software projects. Those are no different for software testing. In his book Software Estimation: Demystifying the Black Art, Steve McConnell goes into a lot of detail around many of those techniques and some of the common problems people encounter when applying them. It's an excellent resource if you find yourself doing a lot of estimating.

In general, Mike and I both tend to approach the work top down if the project is entirely new. First we ask questions that gain clarity around what we are suppose to test and what the goals for that testing are. Once we understand the scope, we break the application up into its various parts and look at different quality criteria for each part. We build a list of the tests that we might perform.

Once we have that initial list, we can start to look at the order of magnitude for each type of testing we have identified (high, medium, low). Once we know how much testing we might do for an area or type of testing, we ask ourselves how much work there may be in developing and executing that testing (which depends heavily on what approach we are taking with our testing). If you lay out your high-level estimates against the magnitude of work, you can start to get a better idea of how much testing you have in front of you.

At the end of the day, you will most likely just have to time box many test activities. You'll want to know up front where you want to cut off certain activities so you can focus on others. More likely then not, you've already got an idea about some of your constraints (time, budget, resources, etc.). Those all play a big part in the estimates, regardless of historical data.

Mike illustrates an example of how he does estimates for a new project in his blog post on estimating testing using spreadsheets. It's a simple example, but it gives you an idea of how you can approach a new project and start breaking it down.

Karen has replied to a similar question on She offers ideas on soliciting input from team members and rolling up estimates for final numbers to give to your project manager.

This was last published in January 2008

Dig Deeper on Software Testing and QA Fundamentals

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Yes, breaking it down and working backwards from the hard deadline is the best approach for testing. A good thing is to include defect counts into your estimation scheme explicitly - if the actual number goes above assumed you can give an early warning.
We are constantly asked to estimate things that we have no point of reference for, and we generally aren't given the time to break down the tasks to the point that we'll have an idea of tests to perform, etc. I just go with my gut, and then notch my estimate up a bit, because there are inevitably complications and unexpected things that arise during the project work.