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
 Provides common context at an early stage of system
development
 Ensures a mutual understanding of the requirements
• Help in identifying
 Who interacts with the system
 The interfaces the system should have
Use Cases – Why (contd.)

• To validate
 All requirements have been captured
 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
 Regular variants
 Odd cases
• Exceptional flows
Use Case Alternative Flow
• Describe the following for each "detour" to the basic flow of events:
 Where in the basic flow of events the alternative behavior may
exist.
 The condition that needs to be fulfilled for the alternative
behavior to start.
 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.
2. Can not enroll because Unfulfilled
Prerequisites.
• Test cases to test boundary conditions may be
added.
Step Two: Identify Test Cases (contd.)

• 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.
Step Two: Identify Test Cases (contd.)

• Document the test cases, using a matrix format

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

• 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