Guidelines: Test Case

Test Case

A Test case is a set of test inputs, execution conditions, and

expected results developed for a particular objective, such as to
exercise a particular program path or to verify compliance with a
specific requirement.

Topics

Explanation
Deriving Test Cases from Use Cases
Deriving Test Cases from Supplementary Specifications
Deriving Test Cases for Performance Tests
Deriving Test Cases for Security / Access Tests
Deriving Test Cases for Configuration Tests
Deriving Test Cases for Installation Tests
Deriving Test Cases for other Non-Functional Tests
Deriving test cases for Unit Tests
White-box tests
Black-box tests
Deriving Test Cases for Product Acceptance Test
Build Test Cases for Regression Test

Explanation
Nothing has a greater effect on the end-user's satisfaction with the software than a clear view of what
the end-user expects so that those expectations can be verified and validated. Test cases reflect the
requirements that are to be verified. Verifying these requirements, however, may be done differently
and by different testers. For example, executing the software to verify its function and performance
may be done by a tester using automated test techniques, the shut-down sequence of a computer
system may be done by manual test and observation, while market share and sales, (also product
requirements), will be done by measuring product and competitive sales.
Since you may not be able to (or be responsible to) verify all requirements, it is critical for the
success of your project to select the most appropriate or critical ones requirements for test. The
requirements you choose to verify will be a balance between the cost, risk, and necessity of having
the requirement verified.
Identifying the test cases is important for several reasons.
Test cases form the foundation on which to design and develop Test Scripts.
The "depth" of the testing is proportional to the number of test cases. Greater confidence in
the quality of the product and test process is gained when the number of test cases increases,
since each test case reflects a different scenario, condition, or flow through the product.
A principal measure of the completeness of test is requirements-based coverage, based on the
of the number test cases identified, implemented, and / or executed. A statement such as "95
percent of our critical test cases have been executed and verified" is more significant than stating

"We're 95 percent of the way through our tests."

The scale of the test effort is proportional to the number of test cases. With a comprehensive
breakdown of test cases, the timing of succeeding stages of the test cycle can be more accurately
estimated.
The kinds of test design and development, and the resources needed are largely governed by
the test cases.
Test cases are often categorized or classified by the type of test or requirement for test they are
associated with, and will vary accordingly. Best practice is to develop at least two test cases for each
requirement for test:
a test case to demonstrate the requirement has been achieved, often referred to as a positive
test case,
another test case, reflecting an unacceptable, abnormal, or unexpected condition or data, to
demonstrate that the requirement is only achieved under the desired condition, referred to as a
negative test cases.

Deriving Test Cases from Use Cases

Test cases for functional testing are derived from the target-of-test's use cases (see Artifact: Use
Case). Test cases should be developed for each use-case scenario. The use-case scenarios are
identified by describing the paths through the use case that traverse the basic flow and alternate
flows start to finish through the use case.
In the diagram below, for example, each of the different paths through a use case reflecting the basic
and alternate flows, are represented with the arrows. The basic flow, represented by the straight,
black-line is the simplest path through the use case. Each alternate flow begins with the basic flow
and then, dependent upon a specific condition, the alternate flow is executed. Alternate flows may
rejoin the basic flow (alternate flows 1 and 3), may originate from another alternate flow (alternate
flow 2), or may terminate the use case without rejoining a flow (alternate flows 2 and 4).

Sample Flows of Events for a use case

Following each possible path through the use case in the above diagram, the different use-case
scenarios can be identified. Beginning with the basic flow and then combining the basic flow with
alternate flows, the following use-case scenarios can be identified:
Scenario 1 Basic Flow
Scenario 2 Basic Flow

Alternate Flow 1

Scenario 3 Basic Flow

Alternate Flow 1

Scenario 4 Basic Flow

Alternate Flow 3

Scenario 5 Basic Flow

Alternate Flow 3

Alternate Flow 1

Scenario 6 Basic Flow

Alternate Flow 3

Alternate Flow 1

Scenario 7 Basic Flow

Alternate Flow 4

Scenario 8 Basic Flow

Alternate Flow 3

Alternate Flow 2

Alternate Flow 2

Alternate Flow 4

NOTE: For simplicity, Scenarios 5, 6, and 8 only depict a single execution of the loop indicated by
Alternate flow 3.
Deriving the test cases for each scenario is done by identifying the specific condition that will cause
that specific use-case scenario to be executed.
For example, suppose the use case depicted in the diagram above stated the following for Alternate
Flow 3:
"This flow of events occurs if the dollar amount entered in Step 2 above, "Enter Withdraw Amount"

is greater than the current account balance. The system displays a warning message and then rejoins
the basic flow at Step 2 "Enter Withdraw Amount" above, where the bank customer can enter a new
withdrawal amount."
With this information, you can begin to identify the test cases needed to execute the alternate flow 3:

Test
Scenario
Case ID

Condition

Expected
Result

TC x

Scenario 4

Step 2 - Withdraw Amount > Account Balance

Rejoin
basic
flow at
Step 2

TC y

Scenario 4

Step 2 - Withdraw Amount < Account Balance

Does not
execute
Alternate
Flow 3,
takes
basic
flow

TC z

Scenario 4

Step 2 - Withdraw Amount = Account Balance

Does not
execute
Alternate
Flow 3,
takes
basic
flow

NOTE: the test cases shown above are very simplistic since no other information was provided. Test
cases are rarely this simple.
A more realistic example of deriving test cases from use cases is provided below.

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 pre-set 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 Flow In Basic Flow Step 2 - Verify Bank Card, if the card is not valid, it is ejected
1 - Not a valid with an appropriate message.
Card
Alternate Flow At Basic Flow Step 5 - ATM Options, if the ATM is out of money, the "Cash
2 - ATM out of Withdraw" option will not be available.
Money
Alternate Flow At Basic Flow Step 6 - Enter Amount, if the ATM contains insufficient funds to
3 - Insufficient dispense the requested amount, an appropriate message will be displayed, and

funds in ATM

rejoins the basic flow at Step 6 - Enter Amount.

Alternate Flow At Basic Flow Step 4 - Verify Account and PIN, the customer has three tries to
4 - Incorrect
enter the correct PIN.
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 Flow At Basic Flow Step 4 - Verify Account and PIN, if the Banking system returns
5 - No Account a code indicating the account could not be found or is not an account which
allows withdrawals, the ATM displays the appropriate message and rejoins the
Basic Flow at Step 9 - Return Card.
Alternate Flow
6 - Insufficient
Funds in
Account

At Basic Flow Step 7 - Authorization, the Banking system returns a code

indicating the account balance is less than the amount entered in Basic Flow
Step 6 - Enter Amount, the ATM displays the appropriate message and rejoins
the Basic Flow at Step 6 - Enter Amount.

Alternate Flow
7 - Daily
maximum
withdrawal
amount
reached

At Basic Flow Step 6 - Authorization, the Banking system returns a code

indicating that, including this request for withdrawal, the customer has or will
have exceeded the maximum amount allowed in a 24 hour period, the ATM
displays the appropriate message and rejoins the Basic Flow at Step 6 - Enter
Amount.

Alternate Flow If at the Basic Flow Step 10 - Receipt, the log cannot be updated, the ATM
x - Log Error enters the "secure mode" in which all functions are suspended. An appropriate
alarm is sent to the Bank System to indicate the ATM has suspended operation.
Alternate Flow The customer can, at any time, decide to terminate the transaction (quit). The
y - Quit
transaction is stopped and the card ejected.
Alternate Flow The ATM contains numerous sensors which monitor different functions, such
z - "Tilt"
as power, pressure exerted on 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 re-start / re-initialize 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 pre-set 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 - Successful
cash withdraw

Basic Flow

Scenario 2 - ATM out of

money

Basic Flow

Alternate Flow 2

Scenario 3 - Insufficient
Funds in ATM

Basic Flow

Alternate Flow 3

Scenario 4 - Incorrect PIN Basic Flow

(tries left)

Alternate Flow 4

Scenario 5 - Incorrect PIN Basic Flow

(no tries left)

Alternate Flow 4

Scenario 6 - No Account / Basic Flow

incorrect account type

Alternate Flow 5

Scenario 7 - Insufficient
Account Balance

Alternate Flow 6

Basic Flow

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
ID#

Scenario /
Condition

PIN Account Amount Amount Amount

#
Entered
in
in ATM
Account
(or
chosen)

Expected
Result

CW1. Scenario 1 Successful

Cash
Withdraw

Successful
cash
withdrawal.

CW2. Scenario 2 ATM out of

Money

Cash
Withdraw
option
unavailable,
end of use
case

CW3. Scenario 3 V
Insufficient
funds in ATM

Warning
message,
return to
Basic Flow
Step 6 - Enter
Amount

CW4. Scenario 4 Incorrect PIN

(> 1 left)

n/a

Warning
message,
return to
Basic Flow
Step 4, Enter
PIN

CW5. Scenario 4 Incorrect PIN

(= 1 try left)

n/a

Warning
message,
return to
Basic Flow
Step 4, Enter
PIN

CW6. Scenario 4 I
Incorrect PIN
(= 0 tries left)

n/a

Warning
message,
card 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.
One all the test cases have been identified, they should be reviewed and validated to ensure
accuracy, appropriateness, and eliminate redundant or equivalent test cases. See Checkpoints: Test
Case for more details.
Upon approval of the test cases, the actual data values can be identified (in the test case
implementation matrix) and the test data built (see Guidelines: Test Data for more information
regarding test data).
TC
ID#

Scenario /
Condition

PIN Account Amount Amount Amount

#
Entered
in
in ATM
Account
(or
chosen)

Expected
Result

CW1. Scenario 1 Successful

Cash
Withdraw

4987

809 498

50.00

500.00

2,000 Successful
cash
withdrawal.
Account
balance
updated to
450.00

CW2. Scenario 2 ATM out of

Money

4987

809 498

100.00

500.00

0.00

CW3. Scenario 3 - 4987

Insufficient
funds in ATM

809 498

100.00

500.00

70.00 Warning
message,
return to
Basic Flow
Step 6 Enter
Amount

CW4. Scenario 4 - 4978

Incorrect PIN
(> 1 left)

809 498

n/a

500.00

2,000 Warning
message,
return to
Basic Flow
Step 4, Enter
PIN

CW5. Scenario 4 - 4978

Incorrect PIN
(= 1 try left)

809 498

n/a

500.00

2,000 Warning
message,
return to
Basic Flow

Cash
Withdraw
option
unavailable,
end of use
case

Step 4, Enter
PIN
CW6. Scenario 4 - 4978
Incorrect PIN
(= 0 tries
left)

809 498

n/a

500.00

2,000 Warning
message,
card 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.

See also Guidelines: Test Data for additional information regarding the test data.

Deriving Test Cases for Product Acceptance Test

Product acceptance testing is the final test action prior to deploying the software. The goal of
acceptance testing is to verify that the software is ready and can be used by the end-users to perform
those functions and tasks the software was built to do. Product acceptance testing often involves

more than execution of the software for readiness, it also involves all product artifacts delivered to
the customer(s), such as training, documentation, and packaging.
Deriving test cases for the software artifact(s) is done in the manner described in the sections above.
Depending upon the degree and of formality of the product acceptance test, the test cases will either
be the same or similar to those identified above (formal), or a sub-set (informal). Independent of the
depth of the test cases, agreement on the test cases and Product Acceptance Plan should be reached
at before product testing is implemented and executed.
Evaluating the non-software artifact(s) varies greatly dependent upon the artifact being evaluated.
Refer to each specific non-software artifacts Guidelines and Checklists for information regarding
what / how to evaluate it.

Build Test Cases for Regression Test

Regression testing compares two builds or versions of the same target-of-test and identifies
differences as potential defects. It thus assumes that a new version should behave like an earlier one
and ensures that defects have not been introduced as a result of the changes.
Ideally, you would like all the test cases in one iteration to be used as test cases in the later iterations.
The following guidelines should be used to identify, design, and implement test cases that maximize
the value of regression testing and re-use, while minimizing maintenance:
Ensure the test case identify only the critical data elements (those needed to create / support
the condition being tested
Ensure each test case describes or represents a unique set of inputs or sequence of events that
results in a unique behavior by the target-of-test
Eliminate redundant or equivalent test cases
Group together test cases which have the same target-of-test initial state and state of the test
data

Copyright 1987 - 2001 Rational Software Corporation

Rational Unified Process