Thanks:  0
Likes:  0
Dislikes:  0

# Thread: How to estimate time for testing in test plan

1. ## How to estimate time for testing in test plan

How can one estimate how much time a particular test will take in particular module while preparing test plan.Is there any method?
thanks

2. ## Re: How to estimate time for testing in test plan

The formula below was posted by Linda Wilken about a year ago:

If it is after test requirements are developed, but before test cases are written:
(# test requirements) /3 = # test cases
(# test cases) X 2 hours = amount of time required to develop test cases
If it is after test cases are written:
(# test cases) X 1/2 hour = time to manual test
(#test cases) X 1 hour = time to develop new automated tests
(time to manual test) X 1/3 = run debugged automated tests
If it is during testing itself, you can take the above figures and determine the current error rate by dividing the number of errors found by the number of tests run. For example, 35 errors found by 200 tests executed = 17.5%. Apply this number to the number of scripts left to run for an expected errors figure. Add the known errors to the expected errors. Assume you'll have to run at least one script to verify each error, again using the 1/2 hour per test figure.
Here's an example of the whole process:
I've identified 2000 test conditions.
2000/3 = 667 test cases
667 test cases X 2 hrs = 1334 hours to document test cases
667 test cases X 1/2 hr = 334 hours to manually test
667 test cases X 1 hr = 667 hours to automate
tests

(334 hours to manually test) X 1/3 = 112 hours to rerun automated scripts
Thus far, 250 scripts run, 42 errors found.
42 errors divided by 250 = 16.4% error rate
417 scripts left to run X 16.4% error rate = 68 anticipated errors
42 + 68 = 110 bugs/retests
110 tests X 1/2 hr = 55 hours
Time left to test = (417 X 1/2 hour) + 55 hours = 263 hours

3. ## Re: How to estimate time for testing in test plan

I'll admit I go as much by experience as by any mathematical scheme however some ideas are:

I try not to make Test estimates without first seeing at least a preliminary Development estimate. Start with dev time and divide by 2. So if it took 40 days to bring something to Code Complete, it will take an additional 20 days to test and debug. Naturally this thinking depends completely on your organizations definition of Code Complete.

Then:

Adjust up for negative risk factors, there are many.

Adjust down for any gimmies, such as large amount of proven reused code.

There's a lower limit defined by how many build cycles I figure it will take to debug. Example perhaps 5 cycles at 5 days each = 25 days, so can't go lower than that in terms of elapsed time.

There's other considerations concerning availability of resources which could extend the estimate.

Some features can be developed much more quickly than tested and some are the reverse. It comes down to understanding the requirements.

Of course all this is best done for all independently estimable features then combined for a total (while considering dependencies). A lot of small guesses added up will be more accurate than one large one.

One has to remain clear about the difference between 'total' time and 'elapsed' or 'real' time. You can't usually just add up the estimates and arrive at a completion date because of feature dependencies and resource limitations.

And I'm probably leaving a lot of stuff out, like for example it's critical to do the exercise with others such as the folks who will be helping do the work. Oh and getting input from the developers is a very good idea as well, their advice and general confidence level could cause an up or down bias on estimates.

4. ## Re: How to estimate time for testing in test plan

Hi,

In addition to the above replies I have some more to add.
Estimates also depends on the weightage of the test cases, there may be test cases which requires less time to design and execute where as few takes more time. I belive we should also give importance to the test case weightage.
I have a small example which i use to estimate, hope it may be helpful. Feedback on the same are welcome,

1. List the functionalities
2. Break down to sub-functionalities
3. Now you get a fair idea of how many test cases can be written of MAJOR, MEDIUM, MINOR. List down the same numbers (approximate)
a. MAJOR - With more number of test steps and critical functionality
b. MEDIUM - With comparitively less test steps and moderate functionality
c. Minor - Usability/User Interface Test cases, like checking the field validations, messages etc.,
4. Consider 3-5 number of MAJOR test cases to be written per hour (Mainly depends on the complexity of the functional requirements)
5. Consider 5-8 number of MEDIUM test cases to be written per hour (Mainly depends on the complexity of the functional requirements)
6. Consider 8-15 number of MINOR test cases to be written per hour (Mainly depends on the complexity of the functional requirements)
7. Summation of step 4,5 and 6 gives the total estimated hours for test case designing. You can add buffer time over that as needed
8. For test case execution repeat step 4,5 and 6 with the following numbers,
a. MAJOR - 6-8 test cases per hour
b. MEDIUM - 8-12 test cases per hour
c. MINOR - 12-25 test cases per hour
9. Summation of step 8.a,8.b and 8.c gives the total estimated hours for execution. You can add buffer time over that as needed

Hope this helps. Kindly provide the feedback

5. ## Re: How to estimate time for testing in test plan

For example:- I am working on a Test Plan of some Project. I have the Function Points of this project. It has already been developed but at the client side.Some modules are complex too in this project.

Is there any proven technique to calculate Testing Effort Estimation based on Function Points? The calculation should not be based guess work.

[ 03-11-2004, 04:58 AM: Message edited by: Harsh Bala ]

6. ## Re: How to estimate time for testing in test plan

Vivek,

And now for a completely different opinion...

If you are using Use Cases as the basis of documenting your system's requirements...

You can estimate the complexity of each use case as HIGH, MEDIUM and LOW.

Then, you can use your use cases to create test cases. Just add the columns "input" "expected output" and "pass/fail" beside your actors and steps.

Once you have the number of use cases, and their complexity, you can use project history to create a "rule of thumb" to describe the amount of time to test each use case.

For instance:

HIGH COMPLEXITY USE CASE - 20 hours to create and execute test case.

MEDIUM COMPLEXITY USE CASE - 15 hours.

LOW COMPLEXITY USE CASE - 10 hours.

Fine tune these metrics with the completion of each project, and after a few projects you should have 95 percent reliable estimates.

Terry

(Hey, try www.softreq.com a free requirements gathering tool!)

7. ## Re: How to estimate time for testing in test plan

Originally posted by Harsh Bala:
Is there any proven technique to calculate Testing Effort Estimation based on Function Points?
<font size="2" face="Verdana, Arial, Helvetica">Look up the Capers Jones equation. This is rule of thumb presented during an IFPUG conference by the aforementioned. It is not strictly a "testing effort" estimation since it deals only with the number of test cases as an absolute measure.
Testing effort involves equally things like complexity of test case creation, execution, data creation, environment management, project management and so on. There is no FP model that spans the entire gamut of items I mentioned. At best, you could use the CJ equation as a supplement to your overall estimation.

Bottomline: We still use heuristics.

[ 03-29-2004, 10:36 PM: Message edited by: punekar (Suresh) ]

8. ## Re: How to estimate time for testing in test plan

Vivek,
If you are just getting started with the estimation process for the first time you could do what we did and match the development hours plus 10%. This is a reasonable starting point until you get to the level where you can pull metrics and develop your own estimate. Also we use 6.5 hrs. per day of useful time based on a standard 8 hour day.

9. ## Re: How to estimate time for testing in test plan

Originally posted by Rich W.:
Vivek,
If you are just getting started with the estimation process for the first time you could do what we did and match the development hours plus 10%. This is a reasonable starting point until you get to the level where you can pull metrics and develop your own estimate.
<font size="2" face="Verdana, Arial, Helvetica">Scenario: The application makes several business decisions based on table entries. Development takes 10 minutes to update some rows in a table, completely changing the business rules.

Will the testers only need 11 minutes to test the changes?

10. ## Re: How to estimate time for testing in test plan

Originally posted by Harsh Bala:
For example:- I am working on a Test Plan of some Project. I have the Function Points of this project. It has already been developed but at the client side.Some modules are complex too in this project.

Is there any proven technique to calculate Testing Effort Estimation based on Function Points? The calculation should not be based guess work.
<font size="2" face="Verdana, Arial, Helvetica">There is a technique called Test Point Analysis, that builds on Function Points. Note that this technique covers the high level tests (system testing), and that the component and component integration tests are covered by the Function Points.
TPA is described in the book 'Software Testing: A Guide to the TMap® Approach', ISBN: 0 201 74571 2

#### 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.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.