5 Use Case Coverage - essenius/AcceptanceTesting GitHub Wiki
A typical way of describing a use case (taken from the Construx Professional Tester Boot Camp) is shown in the table below
Use Case #66 | Place Order |
---|---|
Actor(s) | Customer |
Description | A customer orders some set of books |
Pre-conditions | Known Customer, at least 1 known book, all book quantities are at least 1 |
Post-conditions | One new Book Order has been created with date ordered = today, ship to address as specified, and status = placed. One new Book Order Line has been created for each specified book with quantity = number of copies requested |
Priority | Highest |
Normal course | Credit card payment and ship-to address = customer’s primary address |
Alternative courses | Pay with gift certificate Pay with airline miles Ship-to address is other than customers primary address This order is a gift |
Exceptions | Credit card rejected, Insufficient miles in airline account |
Special requirements | Must be completed in under 60 seconds |
Assumptions | None |
You can mechanically derive test cases from this specification and by doing so you achieve use case coverage. Positive tests are:
- Normal course
- Each alternative course
- Combinations of alternative courses
Negative tests are:
- Violate each precondition
- Force each exception
Use case coverage can (and should) be combined with input domain coverage to reduce the level of incompleteness. The test cases derived from the use case example above are shown below.
Source | Test Cases |
---|---|
Normal course | A known customer buys 2 known books and pays by credit card and ship-to date is primary address |
Alternative courses | A customer buys 2 known books and
|
Combinations of alternate courses |
|
Negative test cases |
|