Example: deriving test cases from use cases

Example:

Actors and use cases in an ATM machine.

The following table contains the basic flow and some alternate flows
for Cash Withdrawal use case in the diagram above:

Basic Flow This Use Case begins with the ATM in the Ready State.
1. Initiate Withdraw - Customer inserts bank card in
the card reader on the ATM machine
2. Verify Bank Card - The ATM reads the account code
from the magnetic strip on the bank card and checks
if it is an acceptable bank card.
3. Enter PIN - The ATM asks for the customer's PIN
code (4 digits)
4. Verify account code and PIN - The account code
and PIN are verified to determine if the account is
valid and if the PIN entered is the correct PIN for the
account. For this flow, the account is a valid account
and the PIN is the correct PIN associated with this
account.
5. ATM Options - The ATM displays the different
alternatives available at this ATM. In this flow, the
bank customer always selects "Cash Withdraw."
6. Enter Amount - The ATM the amount to withdraw.
For this flow the customer selects a preset amount
 ($10, $20, $50, or $100).
7. Authorization - The ATM initiates the verification
process with the Banking System by sending the
Card ID, PIN, Amount, and Account information as a
transaction. For this flow, the Banking System is
online and replies with the authorization to complete
the cash withdrawal successfully and updates the
account balance accordingly.
8. Dispense - The Money is dispensed.
9. Return Card - The Bank Card is returned.
10.Receipt - The receipt is printed and dispensed. The
ATM also updates the internal log accordingly.

Use Case ends with the ATM in the Ready State.

Alternate In Basic Flow Step 2 - Verify Bank Card, if the card is not
Flow 1 - valid, it is ejected with an appropriate message.
Not a valid
Card
Alternate At Basic Flow Step 5 - ATM Options, if the ATM is out of
Flow 2 - money, the "Cash Withdraw" option will not be available.
ATM out of
Money
Alternate At Basic Flow Step 6 - Enter Amount, if the ATM contains
Flow 3 - insufficient funds to dispense the requested amount, an
Insufficient appropriate message will be displayed, and rejoins the
funds in basic flow at Step 6 - Enter Amount.
ATM
Alternate At Basic Flow Step 4 - Verify Account and PIN, the
Flow 4 - customer has three tries to enter the correct PIN.
Incorrect
PIN If an incorrect PIN is entered, the ATM displays the
appropriate message and if there are still tries remaining,
this flow rejoins Basic Flow at Step 3 - Enter PIN.

If, on the final try the entered PIN number is incorrect, the
card is retained, ATM returns to Ready State, and this use
case terminates.
Alternate At Basic Flow Step 4 - Verify Account and PIN, if the
Flow 5 - Banking system returns a code indicating the account
No could not be found or is not an account which allows
Account withdrawals, the ATM displays the appropriate message
and rejoins the Basic Flow at Step 9 - Return Card.
Alternate At Basic Flow Step 7 - Authorization, the Banking system
Flow 6 - returns a code indicating the account balance is less than
Insufficient the amount entered in Basic Flow Step 6 - Enter Amount;
Funds in the ATM displays the appropriate message and rejoins
Account the Basic Flow at Step 6 - Enter Amount.
Alternate At Basic Flow Step 6 - Authorization, the Banking system
Flow 7 - returns a code indicating that, including this request for
Daily withdrawal, the customer has or will have exceeded the
maximum maximum amount allowed in a 24 hour period, the ATM
withdrawal displays the appropriate message and rejoins the Basic
amount Flow at Step 6 - Enter Amount.
reached
Alternate If at the Basic Flow Step 10 - Receipt, the log cannot be
Flow x - updated, the ATM enters the "secure mode" in which all
Log Error functions are suspended. An appropriate alarm is sent to
the Bank System to indicate the ATM has suspended
operation.
Alternate The customer can, at any time, decide to terminate the
Flow y - transaction (quit). The transaction is stopped and the card
Quit ejected.
Alternate The ATM contains numerous sensors which monitor
Flow z - different functions, such as power, pressure exerted on
"Tilt" the various doors and gates, and motion detectors. If at
any time a sensor is activated, an alarm signal is sent to
the Police and the ATM enters a "secure mode" in which
all functions are suspended until the appropriate restart /
reinitialize actions are taken.

In the first iteration, according to the iteration plan, we need

to verify that the Cash Withdrawal use case has been
implemented correctly. The whole use case has not yet been
 implemented, only the following flows have been
implemented:

Basic Flow - Withdrawal of a preset amount ($10, $20, $50,

$100)
Alternate Flow 2 - ATM out of Money
Alternate Flow 3 - Insufficient funds in ATM
Alternate Flow 4 - Incorrect PIN
Alternate Flow 5 - No Account / Incorrect Account Type
Alternate Flow 6 - Insufficient funds in Account

The following scenarios can be derived from this use case:

Scenario 1 - Basic Flow

Successful cash
withdraw
Scenario 2 - ATM out Basic Flow 5 Alternate Flow 2
of money
Scenario 3 - Basic Flow 6 Alternate Flow 3
Insufficient Funds in
ATM
Scenario 4 - Basic Flow Alternate Flow 4
Incorrect PIN (tries
left)
Scenario 5 - Basic Flow Alternate Flow 4
Incorrect PIN (no
tries left)
Scenario 6 - No Basic Flow Alternate Flow 5
Account / incorrect
account type
Scenario 7 - Basic Flow Alternate Flow 6
Insufficient Account
Balance
NOTE: For simplicity the loops in Alternate flows 3 and 6 (Scenarios 3
and 7), and combinations of loops have not been included in the table
above.

For each of these seven scenarios, test cases need to be identified.

Test cases can be identified and managed using matrices or decision
tables. A common format is shown below, where each row represent
an individual test case, and the columns identify test case
information. In this example, for each test case, there is a test case
ID, Condition (or description), and all the data elements participating
in the test case (as input or already in the database), and expected
result.
To begin developing the matrix, start by identifying what data elements are required to execute
the use-case scenarios. Then, for each scenario, identify at least test case that contains the
appropriate condition to execute the scenario. For example, in the matrix below, V (valid) is used
to indicate this condition must be VALID for the basic flow to execute and I (invalid) is used to
indicate the condition which will invoke the desired alternate flow. In the table below, "n/a"
indicates that this condition is not applicable to the test case.

TC Scenario / PIN Account Amount Amount Amount Expected

ID# Condition # Entered in in ATM Result
Account
(or
chosen)

CW1. Scenario 1 V V V V V Successful

- cash
Successful withdrawal.
Cash
Withdraw
CW2. Scenario 2 V V V V I Cash
- ATM out Withdraw
of Money option
unavailable,
end of use
case
CW3. Scenario 3 V V V V I Warning
- message,
Insufficient return to
funds in Basic Flow
ATM Step 6 -
Enter
Amount
CW4. Scenario 4 I V n/a V V Warning
- Incorrect message,
PIN (> 1 return to
left) Basic Flow
Step 4,
Enter PIN
CW5. Scenario 4 I V n/a V V Warning
- Incorrect message,
PIN (= 1 return to
try left) Basic Flow
Step 4,
Enter PIN
CW6. Scenario 4 I V n/a V V Warning
- Incorrect message,
PIN (= 0 card
tries left) retained,
end of use
case

In the matrix above, the six test cases execute the four scenarios. For
the Basic Flow, test case CW1 above is known as a positive test
case. It executes the Basic Flow path through the use case without
any deviations. Comprehensive testing of the Basic Flow must
include negative test cases to ensure that the Basic Flow is taken
only when the conditions are correct. These negative test cases are
represented by test cases CW2 - 6 (the shaded cell indicates the
condition needed to execute the alternate flows). While CW2 - 6 are
negative test cases for the Basic Flow, they are positive test cases for
Alternate flows 2 - 4, and there is at least one negative test case each
of these Alternate Flows (CW1 - the Basic Flow).

Scenario 4 is an example where having just one positive and one

negative test case per scenario is not sufficient. To thoroughly test
Scenario 4 - Incorrect PIN, at least three positive test cases (to
invoke Scenario 4) are needed:

the incorrect PIN is entered and there are tries left and this
Alternate Flow rejoins the Basic Flow Step 3 - Enter PIN)
the incorrect PIN is entered and there are no remaining tries left
and this Alternate Flow then retains the card and terminates the
use case.
the CORRECT PIN is entered when there are no remaining
tries left. This Alternate Flow rejoins the Basic Flow at Step 5 -
Enter Amount.

Notice, that in the above matrix, no actual values were entered for the
conditions (data). An advantage of creating the test case matrix in this
manner is that it is easy to see what conditions are being tested. It is
also very easy to determine if sufficient test cases have been
identified, since you only need to look at Vs and Is (or as done here -
shaded cells). Looking at the above table, there are several
conditions for which there is no shaded cell, therefore, we are missing
test cases, such as for Scenario 6 - No Account or Incorrect Account
Type and Scenario 7 - Insufficient Account Balance.

Once sufficient test cases have been identified, they should be

reviewed and validated to ensure accuracy, appropriateness, and
eliminate duplicate, equivalent or otherwise redundant test cases.

TC Scenario / PIN Account Amount Amount Amount Expected

ID# Condition # Entered in in ATM Result
Account
(or
chosen)

CW1. Scenario 1 4987 809 - 50.00 500.00 2,000 Successful

- 498 cash
Successful withdrawal.
Cash Account
Withdraw balance
updated to
450.00
CW2. Scenario 2 4987 809 - 100.00 500.00 0.00 Cash
- ATM out 498 Withdraw
of Money option
unavailable,
end of use
case
CW3. Scenario 3 4987 809 - 100.00 500.00 70.00 Warning
- 498 message,
Insufficient return to
funds in Basic Flow
ATM Step 6 -
Enter
Amount
CW4. Scenario 4 4978 809 - n/a 500.00 2,000 Warning
- Incorrect 498 message,
PIN (> 1 return to
left) Basic Flow
Step 4,
Enter PIN
CW5. Scenario 4 4978 809 - n/a 500.00 2,000 Warning
- Incorrect 498 message,
PIN (= 1 return to
try left) Basic Flow
 Step 4,
Enter PIN
CW6. Scenario 4 4978 809 - n/a 500.00 2,000 Warning
- Incorrect 498 message,
PIN (= 0 card
tries left) retained,
end of use
case

The test cases above are only a few of the test cases needed to
verify the Cash Withdraw Use Case for this iteration. Other test cases
needed include:

Scenario 6 - No Account or Incorrect Account Type: Account not

found or available
Scenario 6 - No Account or Incorrect Account Type: Account
does not allow withdraws
Scenario 7 - Insufficient Account Balance: Amount requested
greater than amount in account.

In future iterations, when other flows are implemented, test cases will
be needed for:

Invalid cards (card is reported lost, stolen, is not from an

accepted bank, has a damaged stripe, etc.)
Inability to read a card (card reader is jammed, off-line, or
malfunctioning)
Account is closed, frozen, or otherwise unavailable
Amount in ATM is insufficient or incapable of creating requested
amount (different than CW3, in that one denomination is out, but
not all)
Incapable of contacting banking system for approval
Bank network goes off line, or power failure mid-transaction

When identifying functional test cases, ensure the following:

sufficient test cases, positive and negative, have been identified

for each use-case scenario
 test cases address any business rules implemented by the use
cases, ensuring that there are test cases inside, outside, and at the
boundary condition / value for the business rule
test cases address any sequencing of events or actions, such
as those identified in the sequence diagrams in the design model,
or user interface object states or conditions.
test cases address any special requirements defined for the
use case, such minimum/maximum performance, sometimes
combined with minimum/maximum loads or data volumes during
the execution of the use cases.