FEATURE

In this article, we will discuss how

using use cases to generate test cases

Generating Test can help launch the testing process

early in the development life cycle and
also help with testing methodology.

Cases
by Jim Heumann

from Use Cases

n many organizations, software testing
accounts for 30 to 50 percent of soft-
ware development costs. Yet often that
same software is delivered with signifi-
cant defects. This contradiction is root-
ed in two clear facts: First, testing soft-
ware is a very difficult proposition; and
second, testing is typically done without
a clear methodology.
A widely-accepted tenet in the industry
is that it is better to start testing as early
in the software development process as
possible. Delaying the start of testing
activities until all development is done
is a high-risk way to proceed. If signifi-
cant bugs are found at that stage (and
they usually are), then schedules often
slip.
Haphazard methods of designing,
organizing, and implementing testing
activities and artifacts also frequently
lead to less-than-adequate test cover-
age. Having a straightforward plan for
how testing is done can help increase
coverage, efficiency, and ultimately
software quality.
In a software development project, use
cases define system software require-
ments. Use case development begins
early on, so real use cases for key prod-
uct functionality are available in early
iterations. By definition, a use case “…
fully describes a sequence of actions
performed by a system to provide an
observable result of value to a person or
another system using the product under
development.” Use cases tell the cus-
tomer what to expect, the developer
what to code, the technical writer what
to document, and the tester what to test.
For software testing — which consists
of many interrelated tasks, each with its
own artifacts and deliverables — cre-
ation of test cases is one of the first fun-
damental steps. Then test procedures
are designed for these test cases, and
finally, test scripts are created to imple-
ment the procedures. Test cases are key
to the process because they identify and
communicate the conditions that will be
implemented in test and are necessary
to verify successful and acceptable
implementation of the product require-
ments. They are all about making sure
that the product fulfills the require-
ments of the system.
• Test Case - A set of test inputs, exe-
cution conditions, and expected
results (outputs) developed to verify
compliance with a specific require-
ment
• Test Procedure - The procedural
aspect of a given test, usually a set of
detailed instructions for the setup and
execution of one or more given test
cases. The test procedure is an
abstract idea realized by one or more
specific test scripts.
• Test Script - The step-by-step
instructions that realize a test,
enabling its execution. Test Scripts
may take the form of either docu-
mented textual instructions that are
executed manually or computer read-
able instructions that enable automat-
ed test execution.
Although few actually do it, testers can
begin creating test cases as soon as use
cases are available, well before any
code is written. We will discuss how to
do this, and the advantages you can reap
from it, below.
An Introduction to Use
Cases
Use cases are part of the Unified
Modeling Language (UML) and can be
visually represented in use-case dia-
grams. Figure 1 (on page 2) shows a
use-case diagram depicting require-
ments for a university course registra-
tion system.
The ovals represent use cases, and the
stick figures represent “actors,” which
can be either humans or other systems.
The lines represent communication
between an actor and a use case. As you
can see, this use-case diagram provides
the big picture: Each use case repre-
sents a big chunk of functionality that

September 2002 http://www.testinginstitute.com Journal of Software Testing Professionals 1

can be either humans or other systems.
The lines represent communication Feasibility
Study
between an actor and a use case. As you Test Strategy
can see, this use-case diagram provides Project
Definition
the big picture: Each use case represents
a big chunk of functionality that will be User Acc.
Test Plan
implemented, and each actor represents Ops. Accept.
Test Plan System
someone or something outside our sys- Test Plan Integration
tem that interacts with it. Test Plan Unit
It is a significant step to identify use Test Plan
cases and actors, but now there is more
to be done. Each use case also requires Requirements Operational System Design Detailed Design
Definition Requirements Document Document
a significant amount of text to describe
it. This text is usually formatted in sec-
tions, as shown in Table 1. KEY
Development
Unit
Use Case Section Description Name An Deliverable Integration Test Spec.
appropriate name for the use case Brief System Test Spec.
Testing Ops. Accept. Test Spec.
Description A brief description of the User Acc.
Deliverable Test Spec.
use case’s role and purpose. Flow of Test Spec.
Events A textual description of what the
actor does and what the system does in
response. There will always be one
main flow and there will usually be
requirements specific to the use case. conditions A textual description that
multiple alternate flows. The descrip-
Preconditions A textual description that defines any constraints on the system at
tion should be understandable to the
defines any constraints on the system at the time the use case will terminate.
customer. Special Requirements A tex-
the time the use case may start. Post The most important part of a use case
tual description of non-functional
for generating test cases is the flow of
events. The two main parts of the flow
Table 1: Format for a Use-Case Textual Description
of events are the basic flow of events
Use Case Section Description and the alternative flows of events. The
Name An appropriate name for the use case basic flow of events should cover what
“normally” happens when the use case
Brief Description A brief description of the use case’s role and pur- is performed. The alternative flows of
pose events covers behavior of an optional or
exceptional character relative to normal
Flow of Events A textual description of what the actor does and- behavior, and also variations of the nor-
what the system does in response. There will mal behavior. You can think of the alter-
always be one main flow and there will usually be native flows of events as “detours” from
multiple alternative flows. The description should the basic flow of events.
be understandable to the customer.
Figure 2 represents the typical structure
Special Requirements A textual descsription of non-functional require- of these flows of events. The straight
ments specific to the use case. arrow represents the basic flow of
events, and the curves represent alter-
Preconditions A textual description that defines any constraints nate flows. Note that some alternate
on the system at the time the use case may start. flows return to the basic flow of events,
while others end the use case. Both the
Post conditions A textual description that defines any constraints basic flow of events and the alternative
on thesystem at the time the use case will termi- flows should be further structured into
nate. steps or subflows.

2 Journal of Software Testing Professionals http://www.testinginstitute.com September 2002

 Use-Case Scenarios
There is one more thing to describe
before we concentrate on how use cases
can be used to generate test cases: a use-
case scenario. A use-case scenario is an
instance of a use case, or a complete
“path” through the use case. End users
of the completed system can go down
many paths as they execute the func-
tionality specified in the use case.
Following the basic flow would be one
scenario. Following the basic flow plus
alternate flow A1 would be another. The
basic flow plus alternate flow A2 would
be a third, and so on.

Table 2, on the next page, lists all possi-

ble scenarios for the diagram shown in
Figure 2, beginning with the basic flow
and then combining the basic flow with
alternate flows.

A textual description for the basic flow of events in the Register For Courses Use Generating Test Cases
Case is shown in Figure 3. A test case is a set of test inputs, execu-
tion conditions, and expected results
Figure 3: Textual Description for the University Course Registration Use- developed for a particular objective: to
Case Basic Flow of Events exercise a particular program path or
verify compliance with a specific
Register For Courses requirement, for example.
Basic Flow
The purpose of a test case is to identify
1. Logon and communicate conditions that will
This use case starts when a Student accesses the Registration System. be implemented in test. Test cases are
The system asks for, and the Student enters, the student ID and password. necessary to verify successful and
2. Select ‘Create a Schedule’ acceptable implementation of the prod-
The system displays the functions available to the student. The student uct requirements (use cases).
selects “Create a Schedule.”
3. Obtain Course Information We will describe a three-step process
The system retrieves a list of available course offerings from the Course for generating test cases from a fully-
Catalog System and displays the list to the Student. detailed use case:
4. Select Courses
The Student selects 4 primary course offerings and 2 alternate course offer- 1. For each use case, identify a full set
ings from the list of available course offerings. of use-case scenarios.
5. Submit Schedule 2. For each scenario, identify at least
The student indicates that the schedule is complete. For each selected course one test case and the conditions that
offering on the schedule, the system verifies that the Student has the neces- will make it “execute.”
sary prerequisites. 3. For each test case, identify the data
6. Display Completed Schedule values with which to test.
The system displays the schedule containing the selected course offerings
for the Student and the confirmation number for the schedule. Step One: Generate
Scenarios

September 2002 http://www.testinginstitute.com Journal of Software Testing Professionals 3

 Figure 4: Textual Description for University Course Registration Use-Case Step Two: Identify Test
Alternate Flows Cases
Once the full set of scenarios has been
Register for Courses identified, the next step is to identify the
Alternate Flows test cases. We can do this by analyzing
the scenarios and reviewing the use
A1. Unidentified Student case textual description as well. There
In Step 1of the Basic Flow, Logon, if the system determines that the should be at least one test case for each
student ID and/or password is not valid, an error message is displayed. scenario, but there will probably be
A2. Quit more. For example, if the textual
The Course Registration System allows the student to quit at any time dur- description for an alternate flow is writ-
ing the use case. The Student may choose to save a partial schedule before ten in a very cursory way, like A3.
quitting. All courses that are not marked as “enrolled in” are marked as Unfulfilled Prerequisites, Course Full,
“selected” in the schedule. The schedule is saved in the system. The use case or Schedule Conflicts, shown above,
ends. then additional test cases may be
A3. Unfulfilled Prerequisites, Course Full, or Schedule Conflicts required to test all the possibilities. In
In Step 5, Submit Schedule in the Basic Flow, if the system determines that addition we may wish to add test cases
prerequisites for a selected course are not satisfied, that the course is full, or to test boundary conditions.
that there are schedule conflicts, the system will not enroll the student in the
course. A message is displayed that the student can select a different course. The next step in fleshing out the test
The use case continues at Step 4, Select Courses, in the basic flow. cases is to reread the use-case textual
A4. Course Catalog System Unavailable description and find the conditions or
In Step 3, Obtain Course Information in the Basic Flow, if the course cata- data elements required to execute the
log system is down a message is displayed and the use case ends. various scenarios. For the Register for
A5. Course Registration Closed Course use case, conditions would be
If, when the use case starts, it is determined that registration has been closed student ID, password, courses selected,
a message is displayed and the use case ends. etch.

As you can see, a significant amount of detail goes into fully specifying a use case. To clearly document the test cases, once
Ideally, the flows should be written as “dialogs” between the system and the again, a matrix format is useful, like the
actors. Each step should explain what the actor does and what the system does in one in Table 4. Notice the top row. The
response; it should also be numbered and have a title. Alternate flows always first column contains the test case ID,
specify where they start in the basic flow and where they go when they end. the second column has a brief descrip-

Table 2: Some scenarios for the “use case” shown in Figure 2

Scenario ID Starting Flow First Alternate Flow Second Alternate Flow Third Alternate Flow

Scenario 1 Basic Flow

Scenario 2 Basic Flow

Scenario 3 Basic Flow Alternate Flow 1 Alternate Flow 2

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 Alternate Flow 2

Scenario 7 Basic Flow Alternate Flow 4

Scenario 8 Basic Flow Alternative Flow 3 Alternate Flow 4

You can see that a scenario always starts in the basic flow, and besides the basis flow itself, always exercises one ore more
alternate flows. These scenarios will be used as the basis for creating test cases.

September 2002 http://www.testinginstitute.com Journal of Software Testing Professionals 9

Table 3: Partial Scenario Matrix for the Register for Courses Use Case
Scenario ID Starting Flow First Alternate Flow Second Alternate Flow
1 - Successful registration Basic Flow
2 - Unidentified student Basic Flow
3 - User Quits Basic Flow A1
4 - Course registration system unavail. Basic Flow A2
5 - Registration closed Basic Flow A4
6 - Course full Basic Flow A3
7 - Prerequisite not fulfilled Basic Flow A3
8 - Schedule conflict Basic Flow A3
9 - Schedule conflice & User Quits Basic Flow A3 A2

Table 4: Test Case Matrix for the Register for Courses Use Case
Test Scenario/ Student Courses Pre-Req’s Course Schedule Expected
Case ID Condition ID Password Selected Fulfilled Open Open Result
RC 1 Scenario 1 - V V V V V V Schedule and
successful confirmation
registration number displayed.
RC 2 Scenario 2 - I N/A N/A N/A N/A N/A Error message -
unidentified back to login
student screen
RC3 Scenario 3 - V V N/A N/A N/A N/A Login screen
valid user quits appears
RC4 Scenario 4 - V V N/A N/A N/A N/A Error message -
course regi- back to step 2
stration system
unavailable
RC 5 Scenario 5 - V V N/A N/A N/A N/A Error message -
registration back to step 2
closed
RC6 Scenario 6 - V V V V I V Error message -
cannot enroll - back to step 3
course full
RC 7 Scenario 7 - V V v I V V Error message -
cannot enroll - back to step 4
pre-requisite
not fulfilled
RC 8 Scenario 8 - V V V V V I Error message -
cannot enroll - back to step 4
schedule conflict
RC 9 Scenario 9 - V V V V V I Error message -
schedule conflict use case ends
and user quits

tion of the test case, including the sce-
nario being tested, and all other
columns except the last one contain
data elements that will be used in imple-
menting the tests. The last column con-
tains a description of the test case’s
expected output.
Notice that in this matrix no data values
have actually been entered. The cells of
the table contain a V, a I or n/a. V indi-
cates valid, I is for invalid and n/a
means that it is not necessary to supply
a data value in this case. This specific
matrix is a good intermediate step; it
clearly shows what conditions are being
tested for each test case. It is also very
easy to determine by looking at the Vs
and Is whether you have identified a
sufficient number of test cases. In addi-
tion to the “happy day” scenarios in
which everything works fine, each row

10 Journal of Software Testing Professionals http://www.testinginstitute.com September 2002

Table 5: Test Case Matrix with Data Values
Test Scenario/ Student Courses Pre-Req’s Course Schedule Expected
Case ID Condition ID Password Selected Fulfilled Open Open Result
RC 1 Scenario 1 - jheumann abc123 M101 Yes Yes Yes Schedule and
successful E201 confirmation
registration S101 number displayed.
RC 2 Scenario 2 - Jheuman1 N/A N/A N/A N/A N/A Error message -
unidentified back to login
student screen
RC3 Scenario 3 - jheumann abc123 N/A N/A N/A N/A Login screen
valid user quits appears
RC4 Scenario 4 - jheumann abc123 N/A N/A N/A N/A Error message -
course regi- back to step 2
stration system
unavailable
RC 5 Scenario 5 - jheumann abc123 N/A N/A N/A N/A Error message -
registration back to step 2
closed
RC6 Scenario 6 - jheumann abc123 M101 Yes M101full Yes Error message -
cannot enroll - E201 back to step 3
course full S101
RC 7 Scenario 7 - jheumann abc123 M101 No for E201 Yes Yes Error message -
cannot enroll - E201 back to step 4
pre-requisite S101
not fulfilled
RC 8 Scenario 8 - jheumann abc123 M101 Yes Yes E202 and Error message -
cannot enroll - E201 S101 conflict back to step 4
schedule conflict S101
RC 9 Scenario 9 - jheumann abc123 M101 Yes Yes E202 andI Error message -
schedule conflict E201 S101 conflict use case ends
and user quits S101

in the matrix should have at least one I
indicating an invalid condition being
tested. In the test case matrix in Table 4,
some conditions are obviously missing
— e.g., Registration Closed — because
RC3, RC4 and RC5 each have the same
combination of Is and Vs. Additionally,
each column should contain an I in at
least one cell. Looking at the Password
column in table 4 one can see that there
is no I, this indicates that a test case is
missing, there is no test for a bad pass-
word. This “intermediate” test matrix,
thus, helps to quickly analyze test cov-
erage for the associated use case.
Step Three: Identify Data
Values to Test
Once all of the test cases have been
identified, they should be reviewed and
validated to ensure accuracy and to
identify redundant or missing test cases.
Then, once they are approved, the final
step is to substitute actual data values
for the Is and Vs. Without test data, test
cases (or test procedures) can’t be
implemented or executed; they are just
descriptions of conditions, scenarios,
and paths. Therefore, it is necessary to
identify actual values to be used in
implementing the final tests. Table 5
shows a test case matrix with values
substituted for the Is and Vs in the pre-
vious matrix. A number of techniques
can be used for identifying data values,
including random or creative data entry,
but these are beyond the scope of this
article.
Putting It All Together
In current practice, use cases are associ-
ated with the front end of the software
development lifecycle and test cases are
typically associated with the latter part
of the lifecycle. By leveraging use cases
to generate test cases, however, testing
teams can get started much earlier in the
lifecycle, allowing them to identify and
repair defects that would be very costly
to fix later, ship on time, and ensure that
the system will work reliably.
Using the clearly-defined methodology
I’ve outlined above for generating test
cases, testers and developers can sim-
plify the testing process, increase effi-
ciency, and help ensure complete test
coverage.
About the Author:
As Requirements Management Evan-
gelist at Rational Software, Jim
Heumann specializes in the front end of
the software development lifecycle. Jim
has been with Rational software for
over two years, most of which has been
spent helping customers understand and
implement software processes and
tools.
Heumann has been in the software busi-
ness since 1982, having worked on
analysis, development, design, training
and project management in several
organizations of various sizes and
industry segments.

September 2002 http://www.testinginstitute.com Journal of Software Testing Professionals 11

Abstract
By reviewing this paper, the reader
should gain additional insight into the
following areas:
• The differences between functional
and non-functional requirements
• The importance of non-functional
requirements during system analysis
and testing
• The major categories of non-function-
al requirements
• The primary characteristics of each
non-functional requirement type
• Suggested methods for integrating
non-functional requirements into soft-
ware testing practices
Introduction
From an early age, we are all taught the
basic questions to ask when gathering
information. Whether you are a school
child researching a report, a journalist
investigating a story, or a witness
recounting a crime scene, you immedi-
ately ask yourself the so-called “Magic
Five Questions.” These, of course,
include “Who,” “What,” “Where,”
“When” and “How.” And as every good
journalist knows instinctively, without
all of this information the resulting
work seems unfinished and/or raises as
many questions as it answers.
For some reason, however, we IT pro-
fessionals seem to forget these basic
investigative techniques when we
attempt to define the requirements for a
software application. As we interview
customers for their needs, we focus on
only one aspect; that is, the “What.”
Nearly all of the questions we ask
address what the customer wants to be
able to do with the application, and we
assume that if we deliver everything the
customer asked for then our application
will be a success.
Unfortunately, this assumption is bla-
tantly inaccurate. It is just as important
to ask the remaining four questions as it
is to thoroughly document the first. By
focusing on only the “What” of the
12 Journal of Software Testing Professionals
application, we miss much of the under-
lying context and may ignore critical
business constraints that will ultimately
determine our effort’s success or fail-
ure. And just like a journalist who skips
one or more of his “Magic Five,” we
often end up building software applica-
tions that seem unfinished and/or cause
as many problems as they solve.
Functional vs. Non-Functional
Requirements
Unfortunately for IT, software is not
like Kevin Costner’s baseball diamond
in the Hollywood motion picture “Field
of Dreams.” In the movie, Costner has a
vision which tells him that “If you build
it (the baseball diamond), they will
come (ghostly players and real-life
fans).” In software, on the other hand,
just because we build it (the software),
it doesn’t mean they will come (the cus-
tomers).
Instead, it is our job to first determine
exactly what a customer needs before
we begin building the solution. We do
this by asking the “What” questions,
and the answers to those questions are
usually referred to in the IT world as the
“functional requirements” for the appli-
cation.
Functional requirements describe what
it is that a customer needs to be able to
do with our software. They may be doc-
umented in the form of rigorously spec-
ified process models or use cases, or
they may simply be lists of required fea-
tures and functions. Whatever the form
used, functional requirements should
always identify the minimum function-
ality necessary for the software imple-
mentation to be considered a success.
However, as mentioned earlier, this is
not enough. Instead, business analysts
http://www.testinginstitute.com September 2002