By Shalini Rawal

I wanted to share my understanding of USE CASES and get valuable inputs from you. I found use case very interesting and an easy way to design test cases. The name sounds a bit awkward. Doesn’t it? So then what does it mean?

Use Case is a very effective elicitation technique which can be used throughout SDLC. It describes “who” can do “what” with the system in question. The use case technique is used to capture a system’s behavioral requirements by detailing scenario-driven threads through the functional requirements. It is very effective where multiple user classes are involved. As compared to other approach (Requirement Itemisation) of test case designing from SRS, use case has some advantages:

• Easy to write

• Expressed in language of the user

• Can be visually represented

• Can be used for validation (acceptance testing)

• Tools support

• Ideal for OO development

• Where the system is functionally oriented (different types of users, complex behavioral patterns)

We should not use a Use Case when system has few users and is dominated by Non-Functional requirement. Now let us see the various entities involved in a Use Case.

• Actor: An Actor is someone or something that interacts with the system. Example of actors are People (Users), Devices, Other Systems, Organizations. Actors live outside the boundary of the system being defined and they initiate an action. Types of actors are Primary actor and Supporting actor.

A PRIMARY ACTOR is one who calls on the system to deliver a service. i.e. it has a GOAL with respect to the system. A PRIMARY ACTOR is typically who triggers the use case

Examples: A caller initiating a telephone call, a customer withdrawing money from the ATM

(Note: Use cases help identify Primary actors early in the lifecycle)

A SUPPORTING ACTOR is an external actor that provides a service to the system under design.

Examples: A high-speed printer, a web service

(Note: We can use supporting actors to identify external interfaces and the protocols the system will use. An actor can be primary in one use case and supporting in another).

• A GOAL is:

• What an ACTOR wants to get with the help of the system

• An ACTION is

• what the ACTOR must perform to reach the GOAL

• An INTERACTION is

• a sequence of steps that must be  followed to complete the ACTION

Examples of USE CASEs are:

1. “Purchase Goods” Level: User Goal

1. Visitor enters customer information (name, address, etc.).

2. System retrieves customer’s profile information, and presents product search and selection mechanisms.

3. Visitor selects products until satisfied. After each selection, system adds the selected product to the customer’s shopping cart and presents the ongoing running total of products selected.

4. Visitor selects to purchase the selected items.

5. System presents contents of shopping cart and requests customer’s payment information.

6. Visitor enters manner of payment and other payment details.

7. System presents visitor with final sums, charges credit card, and delivers packing list to the shipping department.

2. “Book flight!” referencing “Find a flight-”

“Book flight!” Level: User Goal

1. The customer contacts the travel agency and requests a flight.

2. The customer finds a flight-.

3. The system presents the travel options to the customer.

4. The customer selects a flight.

5. The system builds and reserves flight itinerary for the customer.

7. The customer provides a credit card number.

8. The system charges the flight against it and issues the ticket.

“Find a flight-” Level: Subfunction

1. The customer requests to find a flight.

2. The travel agent captures the customer’s trip origin and destination.

3. The travel agent looks up the airport codes for the origin and destination.

4. The travel agent captures the preferred departure times for the customer.

5. The travel agent captures the customer’s preferred class of service.

6. The travel agent confirms that the customer’s preferences are correct.

7. The system gets from the airline reservation system and presents a list of the available flights that match the customer’s preferences.

To summarise, Use Cases are very helpful in deriving test cases from specification. Some of the good practices for writing Use Cases are:

• Make the use cases clear, short and easy to read: Use active voice, present tense, make sure actor and actor’s intent are visible in each step.

• Every Use case has two possible endings: Success and Failure / alternate courses. Don’t forget to gather both.

• Create a list of primary actors and their goals (actor-goal list).

• Restrict use cases to capture system behavior….use cases are not suitable for other type of requirements.

• Use a common template.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.