Thanks:  0
Likes:  0
Dislikes:  0

# Thread: how to estimate the number of TC

1. ## how to estimate the number of TC

How can we estimate the time required to create test cases? If we have a UC document which contains let say 100 page, is there a standard equation to estimate the number of required test cases, and estimate the required time?

2. ## Re: how to estimate the number of TC

A difficult one! There are no standards that apply for every engagement.
I might be being dense but I don't know what you mean by a UC document. Assuming it is a requirements definition or functional specification (with a total number of requirements/functions). The way i would approach it is as follows:
- Categorise the requirements/functions depending on complexity to test (high, medium, low)
- Pick a typical example from each category and determine no. of test cases required.
- extrapolate up to get estimated total number of test cases.

You can then follow the same process for estimating time (e.g. categorise test cases in terms of time to execute (high, medium or low) and produce an estimate in time for each category. Multiply time/category by number in each category and you have an estimate of effort.

Estimating is useful, however very difficult to be accurate first time round. The trick is to learn from your first estimation and review all the categories after you have completed the test case development and execution phases of your project.

I hope this helps - could be totally pointless if I have misinterpreted what you mean by a UC document.

---------

Tom

3. ## Re: how to estimate the number of TC

UC = Use Case

... at least this might be ...

Might be an interesting question: What's the relationship between Use Case and Test Case?
This could also help answering qa_tester's question ...

Regards,
Juergen

4. ## Re: how to estimate the number of TC

You'd have thought I would have been able to work that out. I think the process in my original post still stands given the Use Case situation.

Categorise the Use Cases in the same way as you would for the functional spec/requirements definition. etc. etc. ......

p.s. thanks Juergen

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

Tom

5. ## Re: how to estimate the number of TC

I have to say, a Use Case of 100 pages seems to be impracticle!
"A good use case is a sequence of transactions that yields a measurable result of value for an actor".
Surely this huge use case could be broken down into many use cases?
The more granular the Feature/Use Case/Requirement - the easier and probably more accurate the estimation.

6. ## Re: how to estimate the number of TC

Linda Wilken posted the following months back and it's very very useful, I hope she does not mind that I post it again!!

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

7. ## Re: how to estimate the number of TC

Hello ,
This is with reference to Linda Wilken's post
(# test requirements) /3 = # test cases .
My question is that what do we mean by Test Requirements ? Is it the same as Functional Requirements or say, Use Cases . If yes , then I think # test cases would be more than the # requirements in most circumstances. Then why are we dividing # test requirements by 3 ?

8. ## Re: how to estimate the number of TC

One of the benefits of feature driven development is the definition of feature sets and features, which makes this estimation easier (not easy!).
Basically, a requirement is expressed in terms of feature sets, and each feature set has a number of features. Usually the feature:test case ratio is 1:1
Another way of doing it (the one I believe Linda was using) is to break a requirement down into a list of test criteria (her test requirement). A test criteria is the smallest testable item with a checkable result. These test criteria can be clumped together logically into test cases - hence Number of test criteria/3 equals average number of test cases.
With functional requirements and Use cases, it all depends on the size and complexity (or granularity) of each when considering how many test criteria (and hence test cases) they break down into. A simple functional requirement or Use case may result in a single test case, more complex ones may equate to hundreds of test cases.
Again, I argue against any of these high level estimation techniques based on averages or assumptions - they are no better that a thumb in the air.
For every project, first define your scope as granular as possible, only then can you make a reasonable estimate.
It is possibly the major issue in development projects as a whole and QA/Test in particular - being asked for estimates before scope is fully defined !

[ 11-13-2003, 04:06 PM: Message edited by: KBEE01 ]

9. ## Re: how to estimate the number of TC

Just for completeness, here what Jeff De Luca says about feature sets/features:
"A feature is a very small but tangible piece of the domain that means something to the business. Partition the domain into major business areas. For each area, list the major business activities. For each activity, list the steps. This sounds harder than it is. You will find it very easy to categorize the domain in this way and in doing so, you are identifying features and categorizing them at the same time."

This captures the essence of what the Features List processs is all about. It is simple functional decomposition of the domain. For each Subject Area (Business Area using the above text) what are the Business Activities? For each Business Activity, what are the steps? The steps become features by being expressed using the feature naming template and by using the two week rule (to break them down further if necessary).

#### 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.