Estimating a testing project

Question

How do you estimate a testing project? What are the things to be take care of while estimating the time for a testing project ?

Answer 1

Many times you don't have time to create the test plan, I have at times been in project planning meetings where a grand scope has been given and Engineering is then asked then and there - to give an estimate. Basically then its a sort of guessing game, which is what estimates are, and if you are being asked to give one you can be sure it will be wrong. That is what an estimate is. Although this will all depend on what sort of process you are using, but if this was a full-up project starting at the beginning with Dev and Test working in parallel I think of the following:

• Is this new technology? The Development Team will need to learn it, extending their time so you will need to learn it to test
• How often will builds come? Are there milestones? Is there a new build process that will need to be implemented? Considering the code coming in to test and how stable it will be, as well as bugfix builds
• Does this require new tools to test? You'll need time to acquire/build as well as setup/train the tools...then take some trial runs to see if things work as expected
• How many resources will you be allowed to have? Will they be shared? This means context switching and loss of resources (emergencies, vacations, people leaving, new hires), you need to plan properly

These are the ones that I would think of in addition to what glowcoder mentioned, they will be a part of any project, and the more documentation you have to provide the longer things will take as well.

Answer 2

There's an excellent series of articles about test estimation that everybody involved in producing or using test estimates should read:

• Project Estimation and Black Swans (Part 1)
• Project Estimation and Black Swans (Part 2)
• Project Estimation and Black Swans (Part 3)
• Project Estimation and Black Swans (Part 4)
• Project Estimation and Black Swans (Part 5): Test Estimation

It starts by exploring a Monte Carlo simulation for a project, showing how a relatively small number of surprises can have a big impact, carries on to talk about strategies for managing that impact, and finishes up by looking at testing in particular.

Answer 3

The first thing to look at is similar testing jobs that took place. For a similar change, how effective was the testing job given the time provided? History is the best place to look for estimates in all fields.

A testing project should have a test-plan before doing your time estimate. Each element in the test plan should have an estimated time for completion. The estimate for the project is simply the sum of the time for each element, plus some overhead for things not directly related to the test:

• project management
• discussion, feedback to developers
• preparing results
• technical difficulties

If you're coming up with estimates without having a test plan, you're setting yourself up to get the estimate wrong.

Answer 4

I agree with the points above:

Some things that I faced in my projects and that we need to consider are:

• The experience that QA and DEV teams have, in the field, with the technology, etc
• Identify the risks
• Be clear on what will be tested and what will not be tested, otherwise, people can assume that some features have been tested, and in the last minute the team has to do extra work in order to verify the features that were not tested early in the game
• Also, during the estimations need to consider the worst-case if it is possible (if issues are found if it is needed to do researches in order to understand the feature, the possibility of having some blockers)

Answer 5

Along with the answers mentioned, this article is also helpful in estimating a testing project.