Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Creating the Acceptance Test Cases
In parallel with designing the application for a particular use case, it's very useful and effective to also design the acceptance test cases for the use case. If you're lucky, this is something that your testers and users will do for you; even if they do, however, I normally spend some time thinking about how to test the use case.
Conceptually, an acceptance test case is very simple. It defines correct operation of the system by stating:
The initial state of the application
The various inputs from the users
The final state of the application
The various outputs from the application
Although some people prefer to number their test cases, personally I prefer to name every test case with a combination of the use case goal and the extension conditions that are being tested.
Notify About Event: Member without email or phone
Initial State:
Membership system contains a member with the name "Pete" and blank email address and phone number.
Inputs:
Club Secretary specified event "Club AGM," date 1-April-2002, location "TBA."
Secretary then chose to print event notice for "Pete."
Final State:
"Club AGM" event is stored.
Member "Pete" is flagged as being sent "Club AGM" notice.
Outputs:
Application showed that 1 member would be notified, and prompted Club Secretary to print event details for "Pete."
"Club AGM" event notice is printed with phone contact list containing the name "Pete" and the phone number "......."
NOTE
Dates in acceptance tests get stale really quickly, so I often choose a date in the past or an easy-to-remember date—April Fools' Day works great for me. If the date absolutely has to be a future date, I use a relative date, such as "now + 30 days".
As you can see, fully specifying one acceptance test case for this use case requires a lot of detail. The full suite of acceptance tests for this one use case could easily require 20 or 30 acceptance test cases. Luckily, once you have all of the detail in the use case, creating these test cases is a fairly mechanical process, but it still has to be done. After all, it would be fairly embarrassing to ask the users to decide how to deal with all of the weird and wonderful error conditions and then have the application fail the first time the user tries to do anything out of the ordinary.
The other reason for documenting these acceptance test cases in such detail is that they are now available for use when you start doing design and test-driven development of the application (see Part 2 of this series for more on test-driven development). The next article in this series will take this use case and associated acceptance test cases and look at the "simple matter" of programming an application (with various detours to discuss design and the craft of programming).