Use Cases and Testing

[article]
Testing UML Models, Part 1
Summary:

This article introduces you to the most important diagrams used in object-oriented development and describes the UML notation used for these diagrams. It also provides practical questions you can ask to evaluate the quality of these object-oriented diagrams: Three sets of questions (complete, correct, and consistent) under three areas of testing (syntax testing, domain expert testing, and traceability testing).

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  ocument object-oriented systems.

This is the first in a series four of articles written to

  • 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?"

For this set of articles we will use a case study: a Web-based, online auction system that I invented: F-LAKE. Yes, I invented the idea of online auctions. I'm not sure why F-LAKE never caught on.

Use Cases
A use case is a scenario that describes the use of a system by an actor to accomplish a specific goal. What does this mean? An actor is a user playing a role with respect to the system. Actors are generally people although other computer systems may be actors. 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. Use cases help us

  • capture the system's functional requirements from the users' perspective
  • actively 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

The UML notation for use cases is

 

 
The rectangle represents the system boundary, the stick figures represent the actors (users of the system), and the ovals represent the individual use cases. Unfortunately, this notation tells us very little about the actual functionality of the system.

Alistair Cockburn has proposed the following format for defining the details of each use case, which I have used on a number of projects. I've included an example use case for F-LAKE: "Bid On An Item."

User Case Name

Bid on an Item

Context Of Use

Bidder wants to purchase an item

Scope

Systems

Level

Primary task

Primary Actor

Bidder

Stakeholders and Interests

Seller, FLAKE.com

Preconditions

None

Success End Conditions

Bid has been processed against the item

Failed End Conditions

Bid has not been processed; item and its current bid price remain unchanged

Trigger

Bidder enters a bid into FLAKE

Description

Step Action
  1

Bidder enters a "Bid on Item" request

  2

FLAKE bids up the currentBid by looping through all active bidders on this item

  3

FLAKE waits for BidTimer to expire

  4

FLAKE notifies winning and losing bidders

Extensions

None

Variations

None

Priority

Critical

Response Time

Within 5 seconds of entry

Frequency

Approximately 100,000 times per day

Channels To Primary Actor

Interactive through a Web interface

Secondary Actors

None

Channels To Secondary Actors

N/A

Due Date

1 Feb 2000

Open Issues

None

 

Syntax Testing
Let's begin with the simplest kind of testing-syntax testing. When performing syntax testing,

User Comments

1 comment
Fiona Benichou's picture
Fiona Benichou

Hi Lee,

In addition to this article, I recently purchased and enjoyed your book on “A Practitioner’s guide to software test design”. The techniques are really helpful! Is there a tool/software downloads/test management system available that encompasses ALL of the test design techniques discussed in the book?

April 9, 2013 - 1:16pm

About the author

Lee Copeland's picture Lee Copeland

Lee Copeland has more than thirty years of experience in the field of software development and testing. He has worked as a programmer, development director, process improvement leader, and consultant. Based on his experience, Lee has developed and taught a number of training courses focusing on software testing and development issues. Lee is the managing technical editor for Better Software magazine, a regular columnist for StickyMinds.com, and the author of A Practitioner's Guide to Software Test Design. Contact Lee at lcopeland@sqe.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!