Timeliness
Acceptance tests really need to be available in the same iteration as the story is scheduled. Think about it—you want to score the development based on getting stories done, and the only way to know if they are really done is to run the tests.
Programmers, you have the right to know what is needed. Insist on this right in the form of automated functional tests. You'll be glad you did.
Customers, you have the right to see progress in a running system, proven to work by automated tests that you specify. Insist on this right, and do your part by providing the necessary information.
Acceptance: Test Samples
Here are some of the sample stories from the story chapter, with suggestions for how they might be tested. Union dues vary by union and are taken only in the first pay period of the month. The system computes the deduction automatically. The amount is shown in the attached table. This is an easy one, of course: the test pays some employees from various unions and checks whether they are charged the right dues, in the first pay period. Another test checks the subsequent pay periods to make sure dues are not taken. When a transaction causes a customer's account to go into overdraft, transfer money from the overdraft protection account, if any. Also easy. Some sample customers, with and without overdraft protection. Test what happens if there isn't enough money in the overdraft account—note that the story is probably incomplete. If the customer writes the test correctly, the programmers will see and deal with the problem quickly enough. When a transaction causes a customer's account to go into overdraft, send an e-mail showing the transaction and balance to the customer. If overdraft protection is in effect, show the overdraft transaction and the resulting account balances in the e-mail. Same as previous test, except that e-mails should be sent. Send them all to a fixed account; have the programmers write code that reads them and checks their formats, so the test can be automatic. Produce a statement for each account, showing transaction date, number, payee, and amount. A sample statement is attached—make the report look approximately like the sample. It's tempting to look at the report manually. That way lies the dark side. Check the report once, very carefully, then compare it mechanically against the good one thereafter. When the GPS has contact with two or fewer satellites for more than 60 seconds, it should display the message "Poor satellite contact," and wait for confirmation from the user. If contact improves before confirmation, clear the message automatically. Functionally testing small hardware devices can be tricky. Do you have a version of the hardware hooked up to testing equipment that can read the display, provide fake satellite input, and so on? Depending on your cost of testing and need for reliability, this might be valuable enough to do. Allow the user to add new service types to the system's initial list. For example, he may wish to add a special entry for getting the car washed at the high school's "free" wash. Include the standard fields amount and date, plus allow the user to add any additional text or numeric fields. Reports should automatically sum any numeric fields. (Programmer note: story needs splitting. Please separate text and numeric fields into two stories, plus one for the summing.) This program, probably conceived as just an interactive GUI-based system, clearly needs a programmatic interface. It's not hard, given even a simple interface, to have a little scripting language set up that simulates GUI commands and checks report output. Remember to compare the report file to a correct one rather than check it by hand. |