Alistair Cockburn's format for Use Cases has been very effective in enabling Use Cases to be used for driving the testing process in projects.
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.
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.
For the ATM Customer: Withdraw Money - Success, Account 101 Card# 123, PIN 1234, balance $1100.00 as of 10/Oct/2000, ATM number 89 contains 10 $20 bills.
Inputs from the actors: The values that will be provided by all of the actors that should cause the desired result for this test case. These values are derived directly from the steps in the use case.
For the ATM Customer: Withdraw Money - Success, Card# 123, PIN 1234 requests withdrawal of $60 from account 101 at 10:10 on 11/Oct/2000.
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.
For the ATM Customer: Withdraw Money - Success, Account 101 balance $1100.00 as of 10/Oct/2000 with pending withdrawal of $60 on 11/Oct/2000 from ATM number 89, ATM number 89 contains 7 $20 bills, receipt shows withdrawal of $60 from account 1** at 10:10 on 11/Oct/2000, remaining balance $1040.00.
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).
The following test cases apply to this sample Use Case Customer: Order Goods.
Initial system state/inputs
Customer Fred (Good Credit risk) orders 1 of item#1 price $10.00
quantity on hand for item#1 is 10
Expected system state/outputs
Quantity on hand for item#1 is 9
Delivery instructions generated
Invoice generated for Customer Pete for 1 of Item#1 price $10.00
Initial system state/inputs
Customer Joe (Bad Credit risk) orders 1 of item#1 price $10.00
quantity on hand for item#1 is 10
Expected system state/outputs
Quantity on hand for item#1 is 9
Delivery instructions specify Cash on Delivery
(C) 2000 Software Craftsmanship Inc., all rights reserved.