When a table is clearer
In short: Text is good for one rule but bad for many cases. A process shows who does what and in which order, a use case shows the goal and what can go wrong, a state machine shows the life of the order, and a decision table shows every combination.
Problem
Three sentences, two answers
The owner writes the discount rule:
The promo code gives a 10 % discount. The code does not apply to products on sale. Loyal customers always get a 5 % discount. Discounts do not add up.
The developer and the tester read it. A loyal customer with a valid code buys a product that is not on sale. The developer calculates 10 %. The tester calculates 15 %, because "always". Each sentence is clear on its own. The combination is not.
Three conditions with two answers each make eight cases. The text describes them in pieces. A table will show all of them.
The idea
When a picture is clearer
Text is good for one rule. When there is an order of steps, many participants, many states or many combinations, a model says more:
| The question | The model | In the shop |
|---|---|---|
| Who does what, and in which order? | business process | the order from the cart to the courier |
| How does one person reach one goal, and what can go wrong? | use case | "Place an order" |
| What is the life of one thing? | state machine | new → paid → shipped → delivered |
| What happens for every combination of conditions? | decision table | promo code, sale price and loyalty |
A model does not replace the requirements. It is a requirement written in another form, and so it can be reviewed and tested like any other.
The idea
The business process
A business process shows the steps of a piece of work, in order, by participant. The standard notation is BPMN. Four symbols are enough here: an event (a circle: something happens, such as a start or an end), an activity (a rectangle: someone does something), a gateway (a diamond: a question with several exits) and lanes (strips: one per participant).
The order process, written as a table:
| # | Lane | Symbol | Step |
|---|---|---|---|
| 1 | Customer | event (start) | The customer presses "Order". |
| 2 | Shop | activity | Creates an order in the state "new". |
| 3 | Customer | activity | Pays by card. |
| 4 | Shop | gateway | Did the payment go through? No → end "The order awaits payment". Yes → 5. |
| 5 | Shop | activity | Marks the order as "paid". The warehouse prints the label. |
| 6 | Warehouse | activity | Packs the parcel and hands it to the courier. The order is "shipped". |
| 7 | Courier | activity | Delivers the parcel. The order is "delivered". |
| 8 | Customer | event (end) | The customer has the parcel. |
The table is poorer than the drawing, but it says the same thing. The most valuable part is step 5: that is where the work passes from the shop to the warehouse, and where the new address got lost.
More precisely, if you are curious
BPMN (Business Process Model and Notation) is an OMG standard, version 2.0. It has many more symbols: messages between participants, timers, subprocesses, exceptions. In BABOK, Process Modelling is a technique of its own. For the analyst and the tester, reading is enough: seeing the lanes, the gateways and the places where work passes from one to another.
Try it
Read the process
The idea
The use case
A use case describes how one actor (a role outside the system) reaches one goal with the system. It has a main flow, where everything goes well, and alternative flows for everything that can go wrong.
Use case: Place an order. Actor: the customer. Precondition: the customer is logged in.
Main flow:
- The customer opens the cart.
- The system shows the products, the total and delivery: 0.00 € from 50 € inclusive, otherwise 4.90 €.
- The customer picks an address.
- The customer presses "Order".
- The system creates the order as "new" and shows the payment.
- The customer pays. The system marks the order as "paid" and sends a confirmation.
Alternative flows:
- 2a. The cart is empty: the system does not allow an order and says why.
- 2b. A product has more than 10 items: the system says the maximum and does not continue.
- 4a. The customer entered a promo code they have already used: the system refuses the code, the total stays without a discount, and the customer continues from step 4.
- 6a. The payment is refused: the order stays "new", and the customer can try again.
Everyone writes the main flow. The value is in the alternative ones. Each of them is a rule the developer has to build and the tester has to check.
More precisely, if you are curious
The format here is close to Alistair Cockburn's in "Writing Effective Use Cases": a main success scenario and extensions numbered by step. UML also has a use case diagram: a stick figure for the actor and an oval for the use case. It shows which use cases exist, but not what happens in them. The text above says more.
Try it
Read the use case
The idea
The state machine
An order has a life: it is new, then paid, then shipped, then delivered. Each such situation is a state, and moving from one to another, on some event, is a transition. Together they are a state machine.
As a table, the order's machine looks like this:
| From | Event and condition | To |
|---|---|---|
| New | the customer pays | Paid |
| New | the customer cancels | Cancelled |
| Paid | the warehouse hands the parcel to the courier | Shipped |
| Shipped | the courier delivers | Delivered |
| Delivered | the customer requests a return, within 14 days of receipt | Returned |
The table also shows what is not allowed. Every "from → to" pair that is not there is forbidden. A shipped order does not become cancelled. A delivered one does not become new.
That is its strength. In text, "cancellation is allowed before shipping" sounds clear. In the table you see at once whether every case "before shipping" has its own row.
Exercise
Which row is missing?
1. The missing transition. Compare the transition table with the rules of the shop.
The idea
The decision table
A decision table has a row for every condition and every action, and a column for every combination. The discount rule from the start, after the owner has said that when two discounts apply the larger one wins:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| The code is valid | yes | yes | yes | yes | no | no | no | no |
| The product is on sale | yes | yes | no | no | yes | yes | no | no |
| The customer is loyal | yes | no | yes | no | yes | no | yes | no |
| Discount | ? | 0 % | ? | 10 % | 5 % | ? | 5 % | 0 % |
The table does two things. First, it is a requirement that reads only one way: every case has exactly one answer. Second, it shows the holes in the text. Column 3 is exactly where the developer and the tester disagreed. The question to the owner ("10 or 15 %?") comes from the empty cell, not from inspiration.
More precisely, if you are curious
Decision tables are also a test design technique (ISTQB CTFL, black-box techniques). There every column is a test case, and columns with the same result are merged with "—" (does not matter): for example, columns 5 and 7 are "no code, loyal → 5 %", whatever the sale. The module "Test design techniques" continues from here. In a requirement the table is kept full, so that no case is left that nobody has thought about.
Exercise
Models as requirements
1. Fill in the table. The three empty cells of the discount table, and how many columns there are.
Test