Functional Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 100

Chapter 5 described the desirable contents of a test plan and the associated test
cases. The heart of the test plan is a series of test cases that detail the test execution
steps needed to validate the software. The challenge for the tester is to progress from
writing the test plan at a high level to writing the test cases at the test execution level.
The experienced tester has discovered that the developer produced use cases provide
a ready blueprint for test case authorship.
7.2 FUNCTIONAL TEST CASES FROM USE CASES
There is a relatively new scoping technique called use case that software developers
employ to capture functional requirements of a system for the purpose of scoping the
project. The technique became popular in the mid-1990s fi rst as an object-oriented
design technique and later broadened in appeal for other types of software develop-
ment. If this topic sparks your interest, there are a number of recent textbooks that
can give you more guidance about writing use cases. [23, 24]
The software development community has not yet standardized on the devel-
opment team role that should write these use cases. Some organizations give this
responsibility to the developers. Some organizations give this responsibility to the
testers. Some organizations give this responsibility to a business analyst. As long as
use cases are written by someone, testers can take advantage of these use cases when
writing functional test cases.
The building blocks of this approach are actors, use cases, happy paths
and alternate paths. Actors are those business roles who are going to directly
use the software. The happy path is the sequence of actions that the actor must
take in order to accomplish a specific use case. Alternative steps that could
be used by an actor to complete the use case represent contingency use cases
(customer not found, credit denied, accessories not available, and so forth.) to
a happy path. A kind of node diagram of the software emerges that displays
all the high-level tasks for a specific business role and the steps necessary to
accomplish these tasks. This node diagram is translated into a text descrip-
tion. The combined node diagram and text description constitute the use case
documentation.
For example, if a developer were to write a use case for an online purchasing
system, the use case text might look like Figure 7.1.
As stated in the Use Case #001 title, this is a happy path, that is, all steps
are expected to be completed by the customer in the sequence shown. An
alternate path associated with this happy path would be dealing with rejection
of the customer's attempted payment. The same products will ultimately be
purchased as with the happy path, but there will be intervening action needed
to solicit acceptable payment from the customer that the happy path does not
encounter.
Use Case #001 provides a high-level description of the sequence of steps that
the actor (customer) must take to complete an online purchase. Recall that in the test
case content description in Chapter 5, there is a sequence of test steps. For functional
testing, here is the helpful crossover. Consider drafting a test case for each use case