Thanks:  0
Likes:  0
Dislikes:  0

1. Estimation

This is with regard to effort estimation.
Suppose there are 10 features in a web application and we can come up with approx 100 test cases totally.
How can we calculate the time spent/test case so that we get to estimate the effort required for testing one complete cycle.
Anybody with inputs please respond ASAP.

Thanks
Rajesh

------------------

2. Re: Estimation

Be carefull with mathematically based estimation methods.

We have found time and again that such metrics have errors margins roughly equivalent to those error margins encountered by an experienced member of staff making an educated guess.

I am talking roughly 20% to 40% margin of error here.

If a task is going to take 20 to 30 days you are better off getting on with it than spending your a couple of days working out that it will take between 21 and 29 days!

Jules

------------------

3. Re: Estimation

There's no magic formula that we can provide for you. The only reasonable thing to do here is draw upon your experience.

In the past, how long has it taken you to carry out 100 test cases? Are these test cases like past test cases, or are they simpler or more complex?

If you or your team have not had any experience with these types of tests cases, then break the task down a bit. Execute 10 test cases and note how long it takes. Then multiply by 10.

Then you will begin to build an experience base upon which to draw for the next set of estimations.
------------------
- Joe (strazzerj@aol.com)

[This message has been edited by jstrazzere (edited 08-23-2001).]

4. Re: Estimation

"The only way to make an correct estimate is to give it after you've finished."

There are so many factors in a testcycle, that without knowing the organisation I find it impossible to give any good advice.
What I can say is that I would keep the folowing factors in mind:
- The time it takes (who?) to do a release into the testing environment.
- The stability of you platform & program while testing.
- The avalability of those that can get the program running properly. (Network/ Server/ Hardware/ Builders/ Ect. Personel)
- The tools you use
- The way you use those tools
- The way you write your testcases
...the list goes on...

------------------

5. Re: Estimation

hmm .. this is tricky ... i base it all on experience .... check how many low, medium and high complexity test cases are .. and before to add time for CM and Bug Fixing... as all of this is included in QA time ... usually during estimation, for simple applications it takes around 30% of the development effort ... and for higher complexity applications it takes up 40% .... but there is no hard and fast rule ... it depends all on experience and type of testing ... good luck to u

------------------

6. Re: Estimation

hi
I agree with all that we need to have a good historical data to be able to base a reliable estimate.

having said that would also say that it is better to arrive at a process productivity value that is also taken into account alongwith the effort/time estimate exercise.

basing estimates on the productivity of individuals will give notoriously unreliable results as well as lead to undesirable padding

regds

------------------

7. Re: Estimation

How often do I have the following conversation with Project Manager?

PM: How long will it take to test xyz?
me: between 30 and 40 days
PM: Can I put down 35?
me: no, if you can't put down 30 to 40 then put down 40
PM: but that's too long!
me: ok - put down 30 then
PM: <happily> great! can you do it in 30
then?
me: probably not
PM: so why did you say 30?
me: Why don't you put down whatever you like then I'll just take as long as it takes
PM: <Frustrated> so what do I put?
me: <resigned to same sh*t different day> 35!
PM: <wanders off looking happy>

------------------

8. Re: Estimation

Not too long ago I had a Project Manager say to me "We've got this new project, the requirements are not yet defined and we are not yet sure how much development effort we will need, can you give me an estimate for how long testing will take?"

Following on from other posts, the best you can do is to keep a record of your past estimates, a record of the actuals, deterimine how close you have been to your estimates, analyse why you were not as close as you would like and get better as you go along.

Magic formulae can help to validate, or at least do a sense check on, your estimates, but you need to use these formulae with care and factor in the peculiarities of the project.

------------------

9. Re: Estimation

It is very hard to apply a standard formula and determine a time estimate. Its hard anytime to provide a time estimate without a good understanding of what the project is going to entail. Use history and experience to estimate as best you can.

------------------
Will Riley

10. Re: Estimation

One solution that you could try, and this is not something that you could do in the short term unless you have tracked this metrics for some other reason.

Determine, over a time period you feel comfortable with (the longer the better) the average number of tests a single resource can execute in one day,week,month,year (pick one).

Then determine the average number of test cases per requirement. Again over time, the longer the better.

(# of Requirements * # of test cases per day)/(# of test cases run per resource (by day) * # of resources) = Time needed to test

(200 requirements * 3 avg test cases per requirement)600 / (10 test cases run per resource * 3 resources)30 = 20 days

Forgive me if the equation isn't written correctly but hopefully the idea made it across.

------------------
ER,

Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•
Search Engine Optimisation provided by DragonByte SEO v2.0.40 (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.