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 SearchSoftwareQuality.com. She offers ideas on soliciting input from team members and rolling up estimates for final numbers to give to your project manager.
