Use Case
Use Case
Addendum de facto
• In today's testing world there is good news
and bad news. The good news is that, more
and more, testers are being asked to evaluate
the quality of object-oriented analysis and
design work earlier in the development
process. The bad news is that most of us do
not have an extensive background in the
object-oriented paradigm or in UML (Unified
Modeling Language), the notation used to
document object-oriented systems.
Objective
• introduce you to the most important diagrams
used in object-oriented development (use
case diagrams, sequence diagrams, class
diagrams, and state-transition diagrams)
• describe the UML notation used for these
diagrams
• give you as a tester a set of practical questions
you can ask to evaluate the quality of these
object-oriented diagrams
We will use three independent
approaches to test our diagrams:
• syntax
"Does the diagram follow the rules?"
• domain expert
"Is the diagram correct?" "What else is there that
is not described in this diagram?"
• traceability
"Does everything in this diagram trace back
correctly and completely to its predecessor?" "Is
everything in the predecessor reflected
completely and correctly in this diagram?"
What are use cases?
• A use case is a scenario that describes the use
of a system by an actor to accomplish a
specific goal. An actor is a user
playing a role with
respect to the
system.
What are use cases?
• A scenario is a sequence of steps that describe
the interactions between an actor and the
system.
• The use case model consists of the collection
of all actors and all use cases.
Importance of Use Cases
• Help us capture the system's functional
requirements from the users' perspective
• Involve users in the requirements-gathering
process
• Provide the basis for identifying major classes
and their relationships
• Serve as the foundation for developing system
test cases
Notation
• rectangle represents
the system boundary
• The stick figures
represent the actors
(users of the system)
• the ovals represent the
individual use cases.
Use Case Specifications
Syntax Testing
• verifying that the use case description
contains correct and proper information.
• Three kinds of questions:
– Is it complete?
– Is it correct? more than half
– Is it consistent? the use cases
failed syntax
testing.
Syntax Testing
Complete:
– Are all use case definition fields filled in? Do we really
know what the words mean?
– Are all of the steps required to implement the use case
included?
– Are all of the ways that things could go right identified and
handled properly? Have all combinations been
considered?
– Are all of the ways that things could go wrong identified
and handled properly? Have all combinations been
considered?
Consistent:
– Can the system actually deliver the specified goals?
Syntax Testing
Correct:
– Is the use case name the primary actor's goal expressed as an active verb
phrase?
– Is the use case described at the appropriate black box/white box level?
– Are the preconditions mandatory? Can they be guaranteed by the system?
– Does the failed end condition protect the interests of all the stakeholders?
– Does the success end condition satisfy the interests of all the stakeholders?
– Does the main success scenario run from the trigger to the delivery of the
success end condition?
– Is the sequence of action steps correct?
– Is each step stated in the present tense with an active verb as a goal that
moves the process forward?
– Is it clear where and why alternate scenarios depart from the main scenario?
– Are design decisions (GUI, Database, …) omitted from the use case?
– Are the use case "generalization," "include," and "extend" relationships used
to their fullest extent but used correctly?
Domain Expert Testing
(The second approach is
• two options:
always more difficult than
– find a domain expert the first, and the first can
– attempt to become one. be very hard.)