tldr: Decision table testing models combinations of conditions and expected outcomes as a table, then derives test cases from it. Best for rule-heavy logic: pricing tiers, eligibility, access control, anywhere "if A and B but not C" patterns dominate.
How decision tables work
A decision table has condition rows, action rows, and rule columns. Each column is a combination of conditions and the corresponding actions.
Example: a discount engine.
| Condition | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Logged in | Yes | Yes | No | No |
| Cart total > $100 | Yes | No | Yes | No |
| Has promo code | No | Yes | Yes | Any |
| Action | ||||
| Apply 10% off | Yes | No | No | No |
| Apply promo | No | Yes | No | No |
| No discount | No | No | Yes | Yes |
Each rule becomes a test case. The four rules cover every meaningful combination.
Why this works better than ad-hoc cases
Three benefits.
Combinations are explicit. When testing multi-condition logic by hand, it is easy to miss combinations. The table forces all of them.
Redundancy gets exposed. If two rules produce the same action, you can usually merge them. The table makes this visible.
Communication improves. A decision table is a shared artifact between QA, engineering, and product. Disagreements about what the system should do surface here.
How to build one
Three steps.
1. Identify conditions
What inputs drive the logic? List them. For the discount example: logged-in status, cart total, promo code presence.
2. Identify actions
What outcomes can the logic produce? List them. For the discount example: 10% off, apply promo, no discount.
3. Enumerate rules
For each combination of conditions, define the action. Reduce by combining duplicate rows or noting "any" where the value does not matter.
When tables explode
A table with 5 binary conditions has 32 rows. With 10 conditions, 1024 rows. Practical decision tables have 3 to 6 conditions.
Above that, switch to:
- Pairwise testing. Cover every pair of conditions. Catches most interaction bugs at a fraction of the rows.
- Decision tree. Hierarchical decisions reduce the combinatorial explosion.
- Equivalence partitioning at the input level. Many conditions can be summarized into classes before they hit the table.
How AI testing fits
Once the table is built, AI testing platforms can run each rule as a test case. Bug0 describes each rule as a goal in plain language, walks through the flow, and validates the action. Adding a new rule is adding a row, not maintaining selectors.
FAQs
What is the difference between decision tables and decision trees?
Tables enumerate combinations as rows. Trees model decisions hierarchically. Tables are easier to verify completeness; trees are easier to follow for humans.
Should every test case come from a decision table?
No. Use them where the logic is rule-heavy. For sequential flows, state-transition tests are better.
How do I test "any" or "don't care" entries?
Pick the most realistic value. Document the choice so the test is reproducible.
How does Bug0 use decision tables?
Bug0 treats each rule as an independent goal. Adding a rule adds a test; modifying a rule modifies one test. The structure of the table maps directly to the test suite.