Developing Test Cases from Use

Cases
Objective

• To provide insight on how to develop effective Test Cases

with Use Case Model

Writing effective Test

Cases

Use Cases to Test

Cases
Use Case Model - What
• A model that describes a system's functional requirements
in terms of use cases
• A model of the system’s intended functionality and its
environment

User
User
Use Case Model

Use case model

Glossary

Actors

Supplementary
Specifications
Use cases
specifications
Use Case Model – Where to use?
• Very effective elicitation technique
 Describe a business process
 Capture functional requirements of a system
 Describe design details of a system
• Can be used throughout SDLC (should be refined)
• Identifies Who (Actors) and the What (Behavior)
• Useful for gathering behavioral aspects and documenting
functionality
• Effective where multiple types of users are involved
Use Cases – Why
Benefits of developing Use Cases
• Facilitate communication among business users, domain
experts and developers
o Provides common context at an early stage of system development
o Ensures a mutual understanding of the requirements
• Help in identifying
o Who interacts with the system
o The interfaces the system should have
Use Cases – Why (contd.)

• To validate
o All requirements have been captured
o The developments team understands the requirements

• A powerful construct for the phases - Analysis, Design,

Implementation and Acceptance Test

Use Cases must be validated by the Business Users

or the Client.
Use Cases to Test Cases
Example

Use Case Specifications:

• Name
• Brief description
• Preconditions
• Sequence of steps - scenario
• Special requirements
• Post-conditions
Use Case Name
• Each use case should have a name that indicates what is
achieved by its interaction with the actor(s)
• The name should be descriptive
• No two use cases can have the same name

E.g. "withdrawing funds" or "examining the passbook"

Use Case Description
• The brief description of the use case should reflect its
purpose.
• As you write the description, refer to the actors involved in
the use case, the glossary and, if needed, define new
concepts.
Use Case - Sequence Of steps
• Describe how the use case starts and ends
• Describe what data is exchanged between the actor and the use case
• Do not describe the details of the user interface
• Describe the flow of events, not only the functionality. To enforce this,
start every action with "When the actor ... "
• Describe only the events that belong to the use case, and not what
happens in other use cases or outside of the system
• Avoid vague terminology such as "for example", "etc. " and
"information"
• Detail the flow of events—all "whats" should be answered. Remember
that test designers are to use this text to identify test cases.
Use Case - Sequence Of steps
(contd.)
• Basic flow
• Alternative flows
o Regular variants
o Odd cases
• Exceptional flows
Use Case Alternative Flow
• Describe the following for each "detour" to the basic flow of events:
o Where in the basic flow of events the alternative behavior may exist.
o The condition that needs to be fulfilled for the alternative behavior to
start.
o How and where the basic flow of events is resumed, or how the use
case ends.

E.g. To withdraw money, I do not have money in my bank

account but I have overdraft facility that will let me withdraw.
Use Case Special requirements
• Special requirements are typically non-functional
requirements and customer-specified behavioral
constraints on the implementation of a system

E.g. You must support 10,000 transactions per minute. They

are, again, best specified in a separate document and
referenced here.
Use Case Preconditions

• Pre-conditions are
useful to clarify how
the sequence of
steps start.
Use Case Preconditions

• It is the constraint not the event that starts the use

case
• Specifies the required state of the system prior the
start of the Use Case
• Can be used for a similar purpose in the Test Case

E.g. customer has sufficient balance in his bank

account
As a consequence, the "checking account balance" use
case must have been performed before the "customer
withdrawing money" use case can be performed.
Use Case Post-conditions

• A postcondition for a use case should be true

regardless of which flows were executed
• It can be a powerful tool for describing use cases
First define what the use case is supposed to
achieve, the postcondition and then describe how to
reach this condition
• May be used for test pass/fail criteria

E.g. the new account balance is the old balance less

the amount withdrawn.
Example

Online Registration for a course:

• A student of an Institute can register online for a
course.
• The student has to provide his/her Student Id,
Password, Course code and Educational
qualifications.
• The student has the facility to enter details and save
it for later registration.

Use Case :
Generating Test Cases

Steps for generating test cases from a fully detailed Use

Case:
• For each Use Case, generate a full set of use case
scenarios
• For each scenario, identify at least 1 test case and
the conditions that will make it ‘execute’
• For each test case, identify the data values with
which to test
Step One: Generate Scenarios

• Identify each combination of basic flow and alternate

flows
• Create a scenario matrix
Step Two: Identify Test Cases

• There should be at least one test case for each scenario.

• Additional test cases may be required to test all the
possibilities for same scenario.
Eg. 1. Can not enroll because Unfulfilled Prerequisites.
2. Can not enroll because Course is full (intake capacity)
3. Can not enroll because Schedule is not open.
• Test cases to test boundary conditions may also be
added.
Step Three: Identify Test Data

• Find the conditions and data elements required to

execute the various scenarios.
• Without test data, test cases can't be executed.
• Identify actual values to be used in implementing the
final tests.
Document Test Cases

• Document the test cases, using a matrix format

having columns:
o Test case ID
o Scenario - brief description of the test case
o Actions
o Values
o Error Messages/Warnings
o Expected Result
• Create a Decision Table:

• Generate Test Case Matrix:

Limitations

• Use cases are used to model only functional

requirements
• They are not used to model capacity and
performance related requirements
• Consequently the non-functional requirements need
to be verified outside of the use case generated tests
cases