Decision Table
Generate decision tables for systematic condition coverage. Click action cells to mark which actions fire per rule.
| R1 | R2 | R3 | R4 | |
|---|---|---|---|---|
| User is logged in | T | T | F | F |
| Has valid subscription | T | F | T | F |
| Allow access | ||||
| Show upgrade prompt | ||||
What is decision table testing?
Decision table testing is a test design technique for features driven by business rules. You list the conditions that can be true or false, enumerate every combination of them, and record what the system should do in each case. Each column is one rule, and each rule becomes one test case. The technique turns a paragraph of requirements prose into a grid where a missing or contradictory rule is visible at a glance.
Its value is as much analysis as testing. Requirements written in sentences hide gaps: the spec says what happens for a logged-in customer with a coupon, and says nothing about a guest with a coupon. In a decision table that silence is an empty cell in a specific column, and you can take it to the product owner before a line of code is written.
A worked example: three conditions, eight rules
Take a checkout discount feature with three conditions and three possible actions. With three binary conditions there are 2³ = 8 combinations, and the tool above generates all of them:
| Condition | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|---|---|---|
| Customer is logged in | T | T | T | T | F | F | F | F |
| Cart total ≥ 100 | T | T | F | F | T | T | F | F |
| Valid coupon applied | T | F | T | F | T | F | T | F |
Then you fill in the actions. This is the step that finds bugs, because you have to answer every column out loud:
| Action | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|---|---|---|
| Apply 10% member discount | ✓ | ✓ | ✓ | ✓ | ||||
| Apply free shipping | ✓ | ✓ | ✓ | ✓ | ||||
| Apply coupon value | ✓ | ✓ | ✓ | ✓ |
R1 is the stacking case: member discount, free shipping and a coupon all at once. That single column is the question most discount bugs come from, and in prose it is easy to never ask it. R8 is the do-nothing baseline, which teams routinely forget to test at all.
Collapsing rules with do-not-care entries
Full tables grow as 2ⁿ: 3 conditions give 8 rules, 5 give 32, 8 give 256. Most of that growth is redundant, because some conditions stop mattering once another is false. If a guest never gets any discount, then for every rule where “logged in” is false the value of “cart total ≥ 100” is irrelevant: marked as a dash or an en dash and read as do-not-care.
Collapsing merges those columns. Eight rules above can reduce to five real test cases once the guest branch is folded into one. Generate the full table first, fill in the actions, then collapse: doing it in the other order is how teams collapse away a combination that actually behaved differently.
How to use this decision table generator
- Add your conditions as yes/no questions about system state: phrase them so that true and false are both meaningful.
- Add the actions the system can take. Keep them observable: something a tester could see or assert on.
- The tool generates every combination of condition values as columns, in a stable order.
- Fill in which actions fire for each rule. Empty cells are answers too: they mean the action must not fire.
- Export as CSV and attach it to the ticket or paste it into your test plan; each column is one test case.
Everything runs in your browser, so you can model an unreleased pricing rule without sending it to a third-party service.
When NOT to use decision tables
Decision tables are excellent for one specific shape of problem and poor for everything else. Recognising the difference saves a lot of wasted grid-building.
The behaviour depends on order, not on conditions
A decision table has no concept of before and after. If the bug is “applying the coupon before selecting the shipping method produces a different total”, no column expresses that. Use state transition testing or a scenario-based approach.
The conditions are not really binary
Account status with five values is not a condition, it is a parameter. Forcing it into true/false questions either loses information or explodes the table. Model multi-value inputs with equivalence partitioning and combine them with pairwise instead.
You have more than about eight conditions
At nine conditions a full table is 512 columns, and nobody reviews 512 columns carefully. That is a signal to split the feature into two or three smaller tables along its natural boundaries, or to question whether the rule set itself is too complicated to be correct.
The rules are numeric thresholds
“Cart total ≥ 100” is one condition in the table, but the interesting test values are 99.99, 100.00 and 100.01. The table tells you the threshold matters; boundary value analysis tells you which numbers to actually type. Use both.
Ways to build a decision table, compared
| Approach | Cost | Combination coverage | Trade-off |
|---|---|---|---|
| AQAPro (this page) | Free, browser, no signup | Generated, all 2ⁿ columns | Binary conditions only; no constraint rules |
| By hand in a spreadsheet | Free | Whatever you remember to type | Missed columns are invisible; no structure enforced |
| Gherkin scenario outline | Free | Only the rows you write | Executable and versioned, but the grid is not generated for you |
| Rule engine (Drools and similar) | Free, heavy setup | Enforced in production code | Solves implementation, not test design; overkill for a test matrix |
| Test management SaaS | Paid | Varies | Traceability and workflow, at the price of a licence and a login |
Honest summary: the generated grid matters because it is complete by construction. A hand-built table is only as complete as the person building it was awake, and the columns people miss are exactly the odd ones where bugs live.
How decision tables relate to the other test design techniques
Each technique answers a different question. Equivalence partitioning and boundary value analysis decide which values to use for a single input. Decision tables decide which combinations of business conditions must be verified. Pairwise decides how to cut down combinations of many-valued parameters when full coverage is impractical. State transition testing covers order and history. A thorough test design pass runs through all four rather than picking a favourite.
Frequently asked questions
How many rules does a decision table have?
A full table with n binary conditions has 2ⁿ rules: 3 conditions give 8, 4 give 16, 5 give 32, 8 give 256. Collapsing do-not-care entries reduces the count to the number of genuinely distinct behaviours, which is usually far smaller.
What is the difference between a limited-entry and an extended-entry decision table?
A limited-entry table allows only true and false in the condition cells: that is what this generator produces, and it is the common case in QA. An extended-entry table allows a condition to hold a value or a range, which is more compact but harder to check for completeness mechanically.
Does every rule become a test case?
In the strict form, yes: one test per column, which gives full decision-table coverage. After collapsing, one test per collapsed rule is the normal standard. Teams under time pressure often test every rule where an action fires plus the all-false baseline, and accept the gap knowingly.
When should I use a decision table instead of pairwise testing?
Use a decision table when combinations carry business meaning and you need every one of them answered: pricing, eligibility, permissions, discounts. Use pairwise when combinations are merely configuration, there are too many to enumerate, and covering each pair once is good enough.
Can a decision table find missing requirements?
That is one of its strongest uses. Generating all columns forces a decision for each one, and any column nobody can answer is an unspecified requirement. Raising those before implementation is cheaper than filing bugs after.
How do I handle conditions that cannot be true at the same time?
Generate the full table, then mark the impossible columns as infeasible and exclude them from the test count with a note explaining why. Do not silently delete them: a reviewer needs to see that the combination was considered and ruled out, not that it was forgotten.