Arunkumar Khannur's Software Testing Knowledge Center
   
 

11.15. Illustration on Deriving Test Cases and Scenarios from Textual Use Cases

A Textual use case contains the following core information:
  • Case Id, Name and optional Abstract/Context Diagram
  • Risk Factors
  • Frequency of occurrence: [frequency range per time interval or event]
  • Impact of failure, likely & worse case [ high, medium, low]
  • Case Conditions
  • Invariants and Pre-conditions
  • Courses of Action
  • Primary Scenarios
  • Performed Scenario(s)
  • Variations or Alternate Scenario(s)
    Exception handler (EH)
    Case-exiting utilities (CE)
    Required selections (RS)
    Optional actions (OA)
    User-invoked interrupts (UI)

A Textual use case contains one Primary Scenario and zero or more performed and/or Alternative Scenario. Additional information such as version, modeler, sources, duration, trigger events (e. g., specific times), undoing cases, or likely successors may also be included in the case. Additional candidates for inclusion can be found in [4] and [6].

A Primary Scenario description contains the following core information:
  • name
  • course conditions i.e., invariant, pre, and post conditions
  • inter-actors, and
  • interaction steps

Each scenario (i.e., complete path through a use case) begins at the first step of the Primary Scenario and must satisfy the case invariants and pre-conditions. Success scenarios, including those talking alternative Scenario, successfully exit the last step of the Primary Scenario.

A performed scenario is invoked with a “does < performed scenario name >” action and contains the following core information:
  • name
  • course conditions,
  • inter-actors, and
  • interaction steps.

Performed Scenarios are used to simplify the Primary Scenario description as well as to encapsulate common course segments.
There are four types of alternative Scenario. All alternative course descriptions contain the following core information:
  • name,
  • insertion site location or range,
  • alternative course conditions,
  • inter-actors, and
  • interaction steps.

The four types of alternative Scenario include:
  • Exception handlers (EH) deal with abnormal conditions that block the successful completion of a system process. An exception condition is checked and if TRUE, the corresponding handler is invoked. The handler may compensate for the abnormal condition or take other steps to deal with the situation.
  • Required Selections (RS) are elements of a set of two or more mutually exclusive alternative Scenario, one of which must be followed e.g., payment alternatives.
  • Optional Actions (OA) are guarded by a set of guard conditions i.e., invariants and pre-conditions. If all the guards conditions are TRUE, then the option is included in the flow e.g., using discount coupons during checkout.
  • User-invoked Interrupts (UI) are included goal-level use cases from the same application or a different application or utilities(e.g., help, save, print)

Let us consider, sections of a use case representing “Reserve Seat on Flight” Use Case, for which we write test cases for alternative scenarios.
Use Case Name Reserve Seat on Flight
Use case Identifier (Optional) UC-1026
Risk Factors Frequency of occurrence: 0 to 2 times per Reservation Impact of failure; likely case- low, open seating is a workaround Worst case – medium, open seating in a large plane with many expensive seats is likely to anger important passengers.
Goal in context Brief description on what is expected from the < Use Case Name >
Description Passenger who is the primary actor interacts with the Web-based Airline Reservation System to reserve a seat on flight
Preconditions For reservation system, status is active For passenger, System access status is signed on.
Assumptions [Optional] Any important assumptions about the domain that you have made when writing this use case. At some point you should verify these assumptions and evolve them either into decisions or simply into parts of the Primary Scenario or alternate Scenarios of action.
Actors Primary actor: Passenger
Primary Scenario Requests seat assignment
Requests a reservation locator
Provides a (corrected) reservation locator alternative
Searches for reservation
Selects a seating alternative
Assigns selected seat unless no seating alternative selected
If (For reservation, seat previously assigned) returns previous seat to inventory
Confirms seat assignment
     SUCCESS EXIT
Variations or Alternate Scenario Offers seating alternatives
   a. reservation not located or
   b. seat previously assigned or
   c. no seats are available or
   d. no seats are assignable
Post-conditions For flight, previously Assigned seat is available
Extensions/ Extended Use Cases [Optional] -NA-
Inclusions/ Included use cases [Optional]. -NA-
Change history [Optional] -NA-
Referenced GUI Seat Status
Issues [Optional] -NA-
Decisions Selection and reserving seat on flight

11.15.1. Primary Scenario Conditions
  • Extensions:
    • For reservation system, status is active
    • For passenger, system access status is signed on
    • For passenger & Flight, a reservation exists and can be located
  • Pre-conditions:
    • For flight, some seats are assignable
    • Passenger wants to get or change seat assignment
  • Post-conditions:
    • For flight, seating alternative was selected
    • For reservation, selected seat is assigned
Alternative Scenarios:
Exception Handlers (EH)
  • EH 1 – 5a (reservation not located)
    EH1 Extensions:
    • For reservation system, status is active
    • For passenger, system access status is signed on
    • For passenger, reservation not located.

    Passenger Web-Based Airline Reservation System
      1. Offers help making reservation
    FAILURE     EXIT

  • EH 2 - 5B (seat previously assigned)
    EH2 Extensions:
    • For reservation system, status is active
    • For passenger, system access status is signed on
    • For passenger & flight , a reservation exits and can be located
    • For reservation, seat previously assigned
       
    Passenger Web-based Airline Reservation System
      1.offers to change seat assignment
    2.wants
    a. to change seat assignment
    b. no change
    3. If (Passenger wants to change seat assignment),
       CONTINUE
          Else, provides help and SUCCESS EXIT

  • EH3 – 5c or 5d (no seats are available or assignable)
    EH3 Extensions:
    • For reservation system, status is active
    • For passenger, system access status is signed on
    • For passenger & flight, a reservation exists and can be located
    • For flight, no seats are assignable

    Passenger Web-Based Airline Reservation System
      If (check in),
    Places passenger on standby
    Post-cond – For passenger , name on standby list
    Else,
    Advices when assignment will be possible
    Endif
    FAILURE EXIT

  • EH4 – 7a (no seating alternative selected)
    EH4 Extensions:
    • For reservation system, status is active
    • For passenger, system access status is signed on
    • For passenger & flight, a reservation exits and can be located
    • For flight, some seats are assignable
    • For reservation, no seating alternative selected
       
    Passenger Web-Based Airline Reservation System
      1. If (For reservation, seat previously assigned)
        SUCCESS EXIT
    Endif
      If (day of flight),
     Advises to get assignment at check in
      Else,
        
        Advises to try later
    Endif
    FAILURE EXIT

11.15.2. Test Coverage Criteria for Textual Use Cases
To describe test coverage, we need a few definitions. Single-goal use cases accomplish one and only one user goal. Multiple-goal cases accomplish tow or more user goals. Transitional use cases cause entity state transitions e.g., returns a book, while non-transitional cases do not e.g., display copies borrowed. An ordered pair of transitional cases referencing the same entity may be valid or invalid. For example, a customer record can only be updated, after it is created.

For a set of Textual Use Cases, a test suite should cover:
  • Every (valid) ordered pair of single-goal cases where one or both are non-transitional
  • Every (valid & invalid) ordered pair of transitional cases that reference the same entity
  • Every multiple-goal case

If this is too expensive, then either cover every ordered pair of “high or medium risk” use cases or just cover every ordered pair of “high risk” use cases. In either case, cover every multiple-goal case.

Within a single-goal case, a test suite should cover every step in the basic course, performed scenarios, and alternative courses.

A use case will normally contain multiple scenarios i.e., complete execution paths, because it contains repetition cycles and alternative courses. A scenario may have multiple interpretations, because it contains input alternatives and derived conditions for inputs (e.g., invalid) or states (e.g., unavailable). There are usually many distinct ways to interpret a derived condition e.g., many distinct ways to be invalid or state.

For a use case, the test suite should cover every:
  • Repetition cycle 0 (if possible), 1, and an even number of times
  • Unique cause + 1 interpretation of selection, repetition, alternative course, and derived conditions
  • Input alternative

In addition, the test suite should cover every:
Output boundaries
•Valid and invalid input boundary values.


If one or more of these criteria causes the test suite to be “too big” (i.e., unaffordable because criteria are too strong), risk information must be used to weaken or delete criteria.
Consider adding the “every pair of input partition values” criterion, if you have an adequate budget surplus and its incremental cost-effectiveness has been shown.
 
 
 
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