Arunkumar Khannur's Software Testing Knowledge Center
   
 

11.14. Illustration on Deriving Test Cases and Scenarios from Diagrammatic Use Case Representations

Steps involved in developing and performing use case scenario testing are:
  • Step 1: Create the Use Case Scenarios
  • Step 2: Derive Test Cases from Use Cases
  • Step 3: Execute Test Cases and report findings
Following sections describe each step in detail.

Step 1: Create the Use Case Scenarios
The first step is to develop the Use Case topics from the functional requirements of the Software Requirement Specification. The Use Case topics are depicted as an oval with the Use Case name. See < Fig. ## > The Diagram also identifies the Actors outside the system, and which participant initiates the action.

In the first iteration of Use Case definition, the topic, a brief description and actors for each case are identified and consolidated. In the second iteration the Event Flow of each Use Case can be flushed out. The Event Flow may be the personification and role playing of the requirements specification. The requirements in the Software Requirement Specification are each uniquely numbered so that they may be accounted for in the verification testing. These requirements should be mapped to the Use Case that satisfies them for accountability.

The event flow is a description (usually a list) of the steps of the actor’s interaction with the system and the system’s required response. Recall that system is viewed as a black box. The event flow contains exceptions, which may cause alternate paths through the event flow.

A scenario is a single path through the Use Case event flow. Generally there is one path that may be traversed that does not encounter exceptions (this is referred to as the Happy Day scenario). There are as many exceptions path scenarios as there are exceptions.

Let’s look at an example of a Use Case and the Test Case derived from it. The Following problem statement will serve as our Software Requirement Specification.

Example: Problem statement and corresponding Use Case Diagram of Card Reader System is as follows:
  • Monitor and control the normal entry and exit of building occupants through the use of personal security cards
  • This includes entry and exit of the building proper, and entry and exit from particular security zones within the building.
  • The system controls the locks on the doors, and will not unlock a door unless the appropriate security card is swiped through the card reader by the door

    Given this problem statement, we may arrive at a Use Case diagram shown in Card Reader System Use Case Diagram as follows.
    T
    The brief descriptions for these Use Cases might read as:
  • Enter Building : Employee enters the building using card reader passage
  • Exit Building : Employee exits the building using card reader passage
  • Enter Security Zone: Cleared Employee enters the vault using card reader passage
  • Exit Security Zone: Cleared Employee exits the vault using card reader passage
  • System Maintenance: Authorized user enters/edits employee card data
  • Note that the enter and exit use cases could be combined into one use case for the building and one for the security zone due to similarity between the enter and exit functions
  • Looking now at one particular Use Case, Enter Building, we would expect an Event Flow such as:

Enter Building Event Flow
  • Use case starts when user slides card through card-reader
  • Card-reader scans employee ID from card [E1]
  • System validates employee access [E2]
  • System unlocks door for configured time period [E3]
  • Employee opens door [E4]
  • Employee enters and door shuts [E5]
  • System locks door [E6], Use Case ends

The following events and the associated exceptions can then be generated for the Enter Building use case.
Use case starts when the user slides a card through the card-reader
Card-reader scans employee ID from card

Exception 1: Card can’t be read
         Log event
         Use case ends
System validates employee access
Exception 2: Employee ID is invalid
         Log event
         Use case ends
System unlocks door for configured time period
Exception 3: System unable to unlock door
         Log event
         Use case ends
Employee opens door
Exception 4: Door is not opened
         System waits for timeout
         System locks door
         Use case ends
Employee enters and door shuts
Exception 5: Door is not shut
         System waits for timeout
         System attempts to lock door
         Log event
         Set alarm condition
         Use case ends
System locks door, Use case ends
Exception 6: Door fails to lock
         System waits for timeout
         System attempts to lock door
         Log event
         Set alarm condition
         Use case ends
For this Use Case, based on the above events and exceptions, we have derived the following Test Case.

Step 2: Derive Test Cases from Use Cases
For Enter Building Use case as represented above as a set of scenarios, we can derive following test cases.

Enter Building Test Case
Test Condition 1: Happy days scenario – valid employee card is used
         Swipe card
         Verify door is unlocked
         Enter building
         Verify door is locked
Test Condition 2: Card can’t be read
         Swipe a card that is not valid
         Verify event is logged
Test Condition 3: Invalid employee ID
         Swipe card with invalid employee ID
         Verify door is not unlocked
         Verify event is logged
Test Condition 4: System unable to unlock door
         Swipe card
         “Injected” failure of unlocking mechanism
         Verify event is logged
Test Condition 5: Door is not opened
         Swipe card
         Verify door is unlocked
         Don’t open the door and wait until timeout is exceeded
         Verify door is locked
Test Condition 6: Door is not shut after entry
Swipe card
Enter building
Hold door open until timeout is exceeded
Verify alarm is sounded
Verify event is logged
Test Condition 7: Door fails to lock
Swipe card
Enter building
“Injected” failure of locking mechanism
Verify alarm is sounded
Verify event is logged
Test cases 4 and 7 would normally be verified at the unit test or integration test phase due to having to, presumably, use an intrusive method to fail the lock mechanism.

There are, however, limitations of Using Use Cases For Test Case Generation. Use cases are not used to model capacity and performance related requirements, they are used to only model functional requirements. Consequently the non-functional requirements need to be verified outside of the use case generated tests cases.

Step 3: Execute Test Cases and Report Findings
Once derive Test Cases, we have to execute test cases. Given the large number of use cases, and even larger number of scenarios, some prioritization of the generated test cases must be performed to obtain a reasonable set of tests to actually run. Besides prioritizing the tests that are to be performed at system test time, use cases can also be verified at unit test and integration and test time, thus spreading the test effort out over the more of the life cycle of the project.

Following this, testers execute Use Case based Test Cases and scenario. The findings are recorded in Use Case Testing Worksheet.
 
 
 
Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
         
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
STEP-AUTO Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
URL: www.isqtinternational.com
Email: khannur@isqtinternational.com
Skype: arun.isqt