Decision tables, state transition tests and traceability

Boundary values handle inputs. Two other techniques handle rules and flows, and both appear in testing screenings. Decision tables stop you missing a combination of conditions. State transition testing stops you missing an illegal move between statuses. A traceability matrix proves that every requirement has a test.

Decision tables

List the conditions as rows, the possible combinations as columns, and the expected action at the bottom. Worked example, a shipping rule: free shipping if the customer is a member or the order is over 50, otherwise charge 5.

Condition        R1   R2   R3   R4
Member?          Y    Y    N    N
Order over 50?   Y    N    Y    N
Shipping fee     0    0    0    5

Two conditions give four rules, so four test cases. Three conditions give eight. Write the full table before merging any columns. The table also exposes gaps: ask the product owner what "over 50" means at exactly 50, and you have found a requirement defect before writing a single case.

State transition testing

Many features are status machines: an order moves from New to Paid to Shipped to Delivered, and can go to Cancelled only from New or Paid. Draw the states as boxes and the allowed events as arrows. Then write two kinds of cases: valid transitions (Paid plus Ship event gives Shipped) and invalid ones (Shipped plus Cancel event must be refused with a clear message). A state table makes the invalid cases visible:

State      Pay      Ship      Cancel
New        Paid     refuse    Cancelled
Paid       refuse   Shipped   Cancelled
Shipped    refuse   refuse    refuse

Each cell that says "refuse" is a test most teams forget. Second example: a user account with Active, Locked and Closed, where five bad passwords lock it and only an admin can clear the lock. The invalid case "user logs in while Locked with the correct password" is the one that finds real bugs.

Traceability matrix

A requirements traceability matrix (RTM) is a table with requirement IDs down the side and test case IDs across, with a mark where a case covers a requirement. It answers two questions instantly: which requirement has no test, and which tests to re-run when a requirement changes. Keep it in the same spreadsheet as the test cases.

Common mistakes and a practice habit

• Testing only the happy path through a status flow and never the refused moves.
• Collapsing a decision table before writing it out, and losing a rule.
• Building an RTM at the end for the audit instead of during design.
• Using a table for a flow problem or a diagram for a rule problem. Rules get tables; sequences get diagrams.

Practice habit. Take a real policy you know, such as a return policy, and write its decision table. Then take a status flow, such as a support ticket, and write the state table including every refused move. One of each per week builds the reflex.