Decision Table Builder
List every combination of your conditions, choose the outcome for each, and get the simplified set of tests you need to run.
Picture a cinema's ticket rules. Students get 10% off and members get 25% off. On Tuesdays, everyone gets 50% off. That sounds simple until someone asks what a student with a membership card pays on a Tuesday. Rules that combine like this are a common source of defects, because it's easy for a developer, or a tester, to miss a combination.
This builder lists every combination of your conditions in a decision table. You choose the outcome each one should give, and it simplifies the table down to the tests you need to run.
What is a decision table?
A decision table shows every combination of conditions and the outcome the software should give for each one. A condition is something that's either true or false, such as "is it Tuesday?". Each combination is called a rule, and the outcome is sometimes called the action.
Decision table testing is a black box technique, which means it tests what the software does without looking at how it's built. It works from the business rules, and it's especially useful when several conditions affect one result, such as prices, discounts, eligibility checks and logins.
Why does the number of rules keep doubling?
Each condition can be yes or no, so every new condition doubles the number of rules. 1 condition gives 2 rules, 2 give 4, 3 give 8 and 6 give 64. Testing every rule is exhaustive testing for that piece of logic, and like all exhaustive testing it grows quickly. The exhaustive and pairwise testing calculator shows the same effect across a whole form.
How does simplifying a decision table work?
Many rules in a full decision table don't need testing separately. In the cinema example, everyone gets 50% off on a Tuesday, so being a student or a member doesn't change the outcome. Those 4 Tuesday rules can be merged into 1, with a dash (–) showing the conditions that don't matter.
This is called collapsing or minimising the table. For the cinema, it takes 8 rules down to 4 tests.
Who is it for?
- Students and anyone new to software testing can see how a set of rules turns into a clear list of tests, and why every new condition doubles the work.
- Working testers get a full decision table and a simplified set of tests with expected outcomes, ready to download as CSV files.
- Business analysts and developers can check that every combination of a rule has an agreed outcome before any code is written.
How to use the builder
- Choose one of the examples, or start from scratch.
- Add each condition as a yes/no question, such as "Student?". You can add up to 6.
- List the possible outcomes, separated by commas.
- In the full decision table, choose the outcome for each rule. Choose "Not possible" for any combination that can't happen.
- Read the simplified table. Each row is one test.
- Download the full table, the simplified tests or both as CSV files.
Build your decision table
Add your conditions and outcomes, set the outcome for each rule, then see the tests you need.
Each one is a yes/no question. Up to 6.
Separate them with commas.
Things to know
- Simplifying merges rules that give the same outcome. If a defect only affects one of the merged combinations, the simplified tests could miss it. Where a mistake would be costly, test the full table.
- Choose "Not possible" for combinations that can't happen, such as being under 18 and over 65 at the same time. They're left out of the tests.
- A rule can appear under "Covers rules" for more than one test. That's normal. It means two simplified rules overlap, and both are needed to cover everything.
Understanding the results
The full decision table has one row for every combination of conditions. Textbooks often show rules as columns instead, but rows are easier to read on screen and in a spreadsheet. The outcome you choose for each rule is the expected result.
The simplified decision table has one row per test. A dash (–) means that condition doesn't change the outcome, so either value will do when you run the test. The covers rules column shows which rules from the full table each test stands in for.
Key points
- A decision table lists every combination of conditions and the expected outcome for each one.
- Every new yes/no condition doubles the number of rules.
- Rules where a condition doesn't change the outcome can be merged, which reduces the number of tests.
- Decision tables often reveal missing or unclear requirements, because every combination needs an agreed outcome.
Frequently asked questions
The simplified table covers every outcome and every rule with fewer tests. The full table tests each combination on its own. Use the full table when a mistake would be costly, such as with payments, or when there are only a few rules anyway.
Choose "Not possible" for that rule. It stays in the full table so you can see it was considered, but it's left out of the tests.
This builder uses yes/no conditions, which is the most common form. A condition with more values, such as a ticket type of adult, child or senior, can be split into yes/no questions, such as "Child?" and "Senior?". Then mark the impossible combinations, such as being both, as not possible. For settings with lots of options, the pairwise calculator may suit better.
Filling in the table forces a decision for every combination. Often nobody has decided what a student member pays on a Tuesday until the table asks the question. Finding that gap before the code is written is far cheaper than finding it after.
No. Decision tables are built from business rules, which are written in everyday language. They're one of the clearest ways to see how a piece of software should behave.