Test Estimation

Add a Comment

Comment by Sanjay Kumar on June 10, 2009 at 7:25am

Its covering the scope of your testing and making a better estimate about each aspect you have to cover under a cycle of testing like time constraint, resources etc etc

Sanjay
www.softwaretesting4u.com
http://rightcareerguidance.blogspot.com/

Comment by Satish Pulikollu on February 21, 2009 at 6:18pm

Its Just an estimate.. Only come out when u really know what each functionality is and how much time it would take... Thats Estimate..

Comment by Mark Crowther on November 18, 2008 at 5:59pm

I've used the "testing is 40%" of development as a rule of thumb, but it's just that, a rough measure, a ballpark, etc.

The problem with estimation is making accurate estimates, drawn on accurate previous estimates, compared to accurate actuals measurements, then being able to apply the collection to a project that looks pretty much the same. In which case you'll just go... "looks like 40% of development time to me".

I wrote a paper on estimation a while ago and proposed a set of models, one of which was "Pick a percent". It works, annoying as that may be. Mainly because organisations typically do projects of a similar type I'd suggest.

Mark.

Comment by Jamie Gagnon on November 17, 2008 at 5:13pm

One thing I struggle with where I am based is, What ever the estimate is, it's too long. Quite often deadlines are imposed even before I am brought up to speed on what the project is. I think one of the biggest factors in estimation needs to be selling the estimate to the project manager.

I base a 2 level estimation rule in my testing.

Level one: Info only Estimate - After attending meetings etc I gather information and based on knowledge I offer an estimated for work by my team. this estimate covers.

- Fact Finding
- Initial draft Test Plan Outlines-
- rework
- test case creation
- Knowledge of product
I advise that this figure is purely a high level estimate and will increase or decrease depending on what my team discover during the fact finding stages.

2. Final estimate - this is based on all the information gathered and the knowledge required in order to conduct the test. I discuss this with the testers and make strong our case.

This normally gives the Project team a good idea of what is expected and usually you get buy in.

Comment by Arun Vijayaraghavan on November 10, 2008 at 3:46am

Yes, I agree with Sherilyn. Never go by the assumption that testing effort is 30% development effort. There are some functionalities that need only .5 PDs for development, but require atleast 3 PDs for testing. Below is a simple example of such scenario:

Change Request: Signature change in all documents printed and sent out to the customer

Developer needed to change the name of the person signing in the database. This didnt take much time as he knew the schema and table where this value needed to be changed. Including unit testing, it just took 0.5 PDs for the developer.

When this Change request came for UAT, we had to derive all test scenarios and test cases where this signature change would affect the printed document. The impact was on for 120 documents which ment 120 test cases. The estimated effort for preparation/executing of 120 test cases was nearly 5 to 6 PDs.

So its better to go with POC approach for initial estimation and then use the TPI (Test Process improvement) to re-iterate the estimates. I agree there would be deviations, but never take 30% as thumb rule.

Thanks,
Arun
www.focustesting.com

Comment by Sherilyn Tasker on November 9, 2008 at 7:32pm

Quote" Testing effort is 30% of development effort"
Now there's a dangerous rule of thumb to apply. (unless your team leader came up with it based on actual project data from your company)
Every project should be estimated on its own merits, you can not assume a "one size fits all" mentality.
If you have the data, using previous projects actuals is an excellent place to start when estimating. This could help you to develop your own "rule of thumb" relating to certain types of projects you might do and you may well see a pattern forming in the ratio between development and testing time but it would be risky to take that as gospel. Accurate estimation is a time consuming exercise which is seldom given the time it deserves.

Comment by Arun Vijayaraghavan on November 9, 2008 at 5:23am

Hi guys,

I understand that test estimation either be based on previous project experience or based on Proof of concept method. I would choose the latter since its more transparent and needs less convincing. Kindly read through the article listed in the below hyperlink:

http://blog.focustesting.com/post/Test-Estimation---When-you-fault-with-it-you-potentially-loose-Millions-%24s.aspx

Thanks,
Arun
www.focustesting.com

Comment by Janesh Kodikara on November 5, 2008 at 1:35pm

Hi
This is just a rule of thumb. There are number of factors to be considered.
I would list down some of them. But you need to use your past experience with similar products with your testing team.

1) What is the expectation of testing project (Objectives, Test All features with Functionality , Performance etc)
2) What are testing activities involved (Test documentation , Release Management , Planning , Document Review)
3) Testing types involved (Functionality , Usability , Portability etc)
4) Your teams' skills ( Are they familiar with similar product , They know the testing process/concepts etc)
5) What's the quality of the releases
6) How many tests cycles to be expected? We get a feature completed releases? Do we need to do regression testing . Need to automate regressions or manual

Also you need to carefully see if the development effort is done correctly.
Changes to the development effort will need change in test effort too.

Try following approach
-- Break you Test Objective into high level tasks
-- Berakdown then into lower tasks till you can give estimates
-- Sum-up them to get a final figure
-- Use this for few project
-- Compare actual and planned tasks
-- Improve your estimation based on this


Cheers
Janesh



Cheers
Janesh