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

The fi rst draft of the use cases and the test cases have insuffi cient details to either
write code or execute tests at this time. Both do represent a roadmap to the additional
level of details needed for writing code and executing tests.
As the design phase of the software development project continues, details
become available that spell out how each actor can accomplish the use case
activities—menus, data entry web pages, data search web pages, report web pages,
printouts, databases for purchases, and so forth. As these details emerge from the
design work, the tester can identify the pieces that need testing individually before
they can be tested together, possibly implying more test cases.
An example of this individual piece testing would be the purchase web
page on which the customer indicates delivery information, billing informa-
tion, and method of payment. For the purposes of discussion, one web page is
assumed to collect all of this information. The purpose of the test case for the
purchase page is to rigorously test all of the data entry fields (delivery street
address), dropdown lists (state code and credit card), radio buttons (5-day
ground, second day air, and so forth), and any other buttons on the page. The
intent is to completely validate this web page before it is included in a happy
path test case. Figure 7.3 shows what the steps of the more detailed purchase
page test case might be.

Step no. Step Expected result

1. Launch the purchase order screen Screen appears

2. Enter purchaser name Accept valid names

3. Enter purchaser address street Accept multiple addresses

4. Enter purchaser address state Select multiple states

5. Enter purchaser address zip Select multiple zip areas

6. Select method of payment Select check/credit card

7. Exit purchase order screen Screen stops successfully

Figure 7.3

A full business path test case from use case

The more the individual web page validation that can be done before the
happy path and alternate path validation, the more successful the fi rst time path
tests will be. The other way to look at it is that if all of the individual web pages
work as advertised and one of the paths fails, then you can focus on the activ-
ity-to-activity interaction instead of asking which page might not be working
correctly.
It is hopefully clear now that use cases are a powerful basis on which to develop
business path test cases. Use cases contain the business functionality to be veri-
fi ed. As each use case is refi ned by additional requirements and design detail, the
tester can leverage the more detailed use cases to develop detailed test cases for the
individual application pieces. Execution of the test cases then proceeds in reverse