Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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

share|improve this question
add comment

4 Answers 4

up vote 6 down vote accepted

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? Development 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 impleted? Considering the code coming in to test and how stable it will be, as well as bug fix 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 additoin 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.

share|improve this answer
    
I think that this is a great list, however, if this is for an enterprise application, don't forget to also look at learning the business logic behind the functional requirements (often forgotten and helps speed up future testing LoE), and time for UAT if it is a part of the QA testing process. –  Lyndon Vrooman May 5 '11 at 22:39
    
Very true, although I haven't been in that world. I've done small companies and start-ups where people are all fired up to get projects going. Usually from presenting the idea to the group then scheduling all in the same meeting. –  MichaelF May 6 '11 at 11:45
add comment

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

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.

share|improve this answer
3  
+1 The black swans articles are definately must read –  Bruce McLeod May 6 '11 at 6:23
    
Links are TRUE masterpiece! Thanks soooo much! –  Peter L. Aug 8 '13 at 17:35
add comment

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.

share|improve this answer
add comment

I agree with the points above:

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

  • 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 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 also 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, possibility of having some blockers)
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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