Test Cases From Use Cases

The extension conditions nominate test cases that need to be
created to ensure that the named condition is correctly handled by the system.

Once a use case has been captured, the first part of design is the validation
of the use case to ensure that it can be implemented. Creating test cases adds
an extra level of precision to a use case. The precise meaning of the Minimal
and Success Guarantees are defined by providing explicit values
for the associated data, and the Extension Conditions are defined
by the explicit combination of values that must be tested for.

An additional benefit of this approach is that creating the test cases assists
in identifying the important concepts in each use case. In OO development we
use classes to represent concepts, so this early nomination of
candidate classes is useful.

Using the standard ATM example, with Step 3 in the main success scenario;

3. Customer enters PIN, ATM verifies it matches the encrypted version on
the card

3a PIN not entered and timeout period expired

The test case for this condition will state the precision to which the system
will perform this test, by defining test conditions around the boundary.

Normally, the first Test Case to create is that for the Main Success Scenario,
since this is the simplest, scenario and usually the highest volume path through
the Use Case. The other test cases can then be defined as variations based on
this simple, happy day case.

Although Test Cases can be simply numbered, it is easier to name them based
on the Use Case name and extension condition that we are validating.

Customer: Withdraw Money - Success

Customer: Withdraw Money - Invalid PIN exceeds retry count

For each Test Case we need to define three parts:

Initial System State: This is the set of values that the system
knows before the start of this use case in order to deliver the expected results
and the resulting final system state. These values are derived from the preconditions
for the use case (if any) and by inference from the inputs and final system
state.

Final System State and expected outputs: The set of values
that the system will contain after the use case has completed and the information
that will have been output as the use case ran through the test case. The
values for the final state are derived from the Use Case Guarantees, the outputs
from the use case steps.

Further notes on the Test Cases

At least 1 test case is needed for every extension condition in a Use
Case. For complete coverage you will need more test cases. This might seem like
a lot of work, but look on the bright side, you only have to test the things
that you want to work correctly, for all of the other requirements you do
not have to worry about specifying tests, since it does not matter if the system
correctly implements these requirements. (With apologies to Ron
Jeffries for rewording his thoughts on testing)

The Main Success Scenario test case should come first since it is nice to show
how the system works in the high volume case. Often this test case can be generated
before all of the extension conditions and recovery paths are known (or investigated
in detail with the business or user community).