# Thread: Arriving Testcases from Usecases

1. ## Arriving Testcases from Usecases

I would like to know whether there is any relation between Test case to Use cases. We know that in a usecase there will be a Mainflow and some alternate flows.

Please let me know whether we can derive (or any industry method) no.of test cases based on Mainflow and Alternate flow.

Since there is a formula to arrive at no. of test cases based on the Functional Points, I would like to know whethter there exists similar equation for Usecases as well

2. ## Re: Arriving Testcases from Usecases

Many folks use Use Cases as one of the many inputs to their Test Cases.

But I don't know that there is any valid formula that could transform the Number of Use Cases provided into the Number of Test Cases needed.

I'd be very skeptical if someone proposed such a formula - at least based on the kinds of Use Cases I've seen.

3. ## Re: Arriving Testcases from Usecases

Why not make the use case a test case? I suppose you could break down a use case based on the actions that it takes, into test cases. However, by doing so, you may end up diluting the relevance of that use case.

What makes use cases so valuable is that they give us an idea of how a user is going to interact with the application. So there really isn't a good reason to break them up. These use cases can, actually, sometimes be more valuable than the test cases themselves because users, even us as users, often do stupid things.

So I wouldn't break them up at all. No reason to.

4. ## Re: Arriving Testcases from Usecases

You can derive number of test cases from use cases using the formula 1 UC Flow = 2 TC. Generally, you should have 2 test cases for each flow within a use case (positive and negative test case). Estimation is not an exact science and thusly is not perfect, using the formula 1 UC Flow = 2 TC should give you a good idea of the number of test cases required for the project.

At a minimum you can use the formula of 1 UC Flow = 1 Test Case.

Hope this helps

5. ## Re: Arriving Testcases from Usecases

&gt; 1 UC Flow = 2 TC

huh??

where'ed ya get that formula? I could write a use case that might take hundreds of test cases to verify.

6. ## Re: Arriving Testcases from Usecases

First off, remember that it is an estimate. An estimate does not have to be exact but should get you close.

The formula is based on End to End test cases. I should have included that in the original post.

If you or anyone in your organization are writing Use Case flows that would take 100's of test cases to test, I would highly suggest changing the way uses case flows are written. Also, if you are writing 100's of test cases for 1 use case flow, you may want to re-think your test case deriving strategy, as it does not seem to be efficient.

There is plenty of "use case 101" documentation available that explain how use case flows should be written.

an example, taken from http://en.wikipedia.org/wiki/Use_case

Basic course of events

At a minimum, each use case should convey a primary scenario, or typical course of events, also called "basic flow" or "happy flow". The main basic course of events is often conveyed as a set of usually numbered steps. For example:

1. The system prompts the user to log on.
2. The user enters his name and password.
3. The system verifies the logon information.
4. The system logs user on to system.

 Alternative paths

Use cases may contain secondary paths or alternative scenarios, which are variations on the main theme. Each tested rule may lead to an alternate path and when there are many rules the permutation of paths increases rapidly, which can lead to very complex documents. Sometimes it is better to use conditional logic or activity diagrams to describe use case with many rules and conditions.

Exceptions, or what happens when things go wrong at the system level, may also be described, not using the alternative paths section but in a section of their own. Alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and, if appropriate, where they rejoin. The intention is to avoid repeating information unnecessarily.

An example of an alternative path would be:

1. The system recognizes cookie on user's machine.
2. Go to step 4 (Main path)

An example of an exception path would be:

3. The system does not recognize user's logon information
4. Go to step 1 (Main path)

Hope this helps

7. ## Re: Arriving Testcases from Usecases

I don't agree with your detailed examples of use cases. In learning analysis and design of systems, UML use cases don't sound anything like you describe.

When functionall decomposing an application, you can go with very high level uses cases. your mileage may vary.

I just mean your formula makes no sense unless you apply it to very detailed use cases that are ALREADY test cases, not high level uses cases.

8. ## Re: Arriving Testcases from Usecases

The information I provided is solid and represents what a use case should be. A use case should have a precondition, an actor or actors and describe a flow of events. A use case will have 1 to many flows, a primary "happy path" flow and alternate flows (to include negative paths)

Could you provide an example of what you believe to be a use case flow?

9. ## Re: Arriving Testcases from Usecases

http://en.wikipedia.org/wiki/Use_case

for example.. a use case might be "user logs into application via login page".. which could consist of many test cases to verify.

10. ## Re: Arriving Testcases from Usecases

You posted the exact same link that I have already posted in this thread. The "detailed" information regarding use cases that I provided was a cut and paste from that site.

Go to: http://en.wikipedia.org/wiki/Use_case and scroll down until you see basic course of events.

How can you reference the website where I obtained the detailed information about use cases found in my post then proceed to say that you do not agree with the detailed information that I provided?

Page 1 of 5 12345 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.