0% found this document useful (0 votes)
21 views16 pages

Use Case

The document introduces use case diagrams and describes how to evaluate them using syntax, domain expert, and traceability testing. It defines what use cases are, their importance, notation, and provides examples of questions to ask for each type of testing.

Uploaded by

Lakbay Tanaw
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views16 pages

Use Case

The document introduces use case diagrams and describes how to evaluate them using syntax, domain expert, and traceability testing. It defines what use cases are, their importance, notation, and provides examples of questions to ask for each type of testing.

Uploaded by

Lakbay Tanaw
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 16

Use Cases

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.)

Ask three kinds of questions:


• Is it complete?
• Is it correct?
• Is it consistent?
Domain Expert Testing
Complete:
– Are all actors identified? Can you identify a specific person who will
play the role of each actor?
– Is this everything that needs to be developed?
– Are all external system trigger conditions handled?
– Have all the words that suggest incompleteness ("some," "etc."…)
been removed?
Correct:
– Is this what you really want? Is this all you really want? Is this more
than you really want?
Consistent:
– When we build this system according to these use cases, will you be
able to determine that we have succeeded?
– Can the system described actually be built?
Traceability Testing
• To check if we can trace from the functional
requirements to the use cases and from the
use cases back to the requirements.
• three kinds of questions:
– Is it complete?
– Is it correct?
– Is it consistent?
Traceability Testing
Complete:
– Do the use cases form a story that unfolds from highest to lowest
levels?
– Is there a context-setting, highest-level use case at the outermost
design scope for each primary actor?
Correct:
– Are all the system's functional requirements reflected in the use
cases?
– Are all the information sources listed?
Consistent:
– Do the use cases define all the functionality within the scope of the
system and nothing outside the scope?
– Can we trace each use case back to its requirement(s)?
– Can we trace each use case forward to its class, sequence, and state-
transition diagrams?

You might also like