Decision Tables and Trees

Quick Summary

• Use a Decision Table DT when there are multiple rules, and different combinations of them lead to different results.

  • Example: If condition 1 AND AND condition 2 OR condition 3 THEN do X — when logic gets messy, a decision table helps organize such logic.

• DT core limitation: it grows exponentially.

  • 5 conditions = 2⁵ = 32 combinations; 10 conditions = 2¹⁰ = 1024.

  • 5 Conditions are an approximate limit, after which the DT becomes difficult to understand, change, or manage.

  • It's possible to simplify a DT.

  • It is sometimes appropriate to break up a DT into several smaller ones (one table per equivalence partition or state).

  • Possible DT alternatives:

    • Rule Engines (e.g. Drools): for systems with many (many!) dynamic, complex rules.

    • Pairwise Testing technique: unlike a DT, does not exhaustively define all rule combinations, but effectively reduces test cases while ensuring key combinations are tested.

Template

Conditions	Rule (Test) 1	Rule 2
Condition 1	Y	N
(Optional blank row for visual clarity)
Action / Result / Output	X

Simple example

Applicant must be over 18 to qualify for {thing}

Condition	Rule 1	Rule 2
Age ≥ 18	Y	N
Accept Application?	X

• Y / N stands for Yes / No. It can also be T / F (True / False)

• X is used for Actions and means "Yes". Blank means "no" or "no action". You could use Y/N for action rows too, but it becomes harder to read the table. Using X helps separate "what is" (conditions) from "what to do" (actions).

• - or N/A means "not applicable"

• There can be many Conditions and many Actions

• The table grows at 2ⁿ rate.

  • 1 condition: 2¹ = 2 columns (rules)

  • 2 conditions: 2² = 4 columns

  • 3 conditions 2³ = 8 columns

  • etc.

Intermediate example

• Applicant must be over 18 to qualify for {thing}

• Fast-track review with residency card, standard review without it

Condition	Rule 1	Rule 2	Rule 3	Rule 4
Age ≥ 18	Y	Y	N	N
Has res. card	Y	N	Y	N
Fast-track review	X
Standard Review		X
Reject			X	X

You'll notice that adding a second condition (has res. card) doubled the number of rules: 2²=4.

Filling in Condition Rows

Looking at the condition rows and all those YY-NN-Y-N-Y-N, one may wonder how to fill them in without getting lost.

Assuming Y/N (boolean) are the only possible values, like so:

Break up the first row in half, fill the 1st half with Y, 2nd with N:

Condition 1: Y Y Y Y N N N N Take half of the condition above, and fill the next row with half Y, half N: Condition 1: Y Y Y Y N N N N Condition 2: Y Y N N Condition 3 Y N Now you have the "repeating pattern" for each row and you can fill them in: Condition 1: Y Y Y Y N N N N Condition 2: Y Y N N Y Y N N Condition 3 Y N Y N Y N Y N

Simplifying The Table

One Action Row to Rule Them All

When actions are mutually exclusive (you can't "approve" and "reject" at the same time), consider using just one row.

• One "Action" row

• Insert action values instead of 'X'

Condition	Rule 1	Rule 2	Rule 3	Rule 4
Age ≥ 18	Y	Y	N	N
Has res. card	Y	N	Y	N
Action	Fast-track Review	Standard Review	Reject	Reject

When more than one action applies in a rule (e.g., "Send email" AND "Log event"), then it makes sense to have one action per row and mark with X.

Merging Rules

It's possible to combine (collapse) rules where it is apparent that an alternative does not make a difference in the outcome.

This: Condition 1 : N N Condition 2 : Y N

Action 1 : X X Can be expressed as: Condition 1 : N Condition 2 : - (dash [-] means "either Y or N, doesn't matter") Action 1 : X

An example of a table with merged rules:

Given that underage applicants will always be rejected (poor beings), we can merge Rules 3 and 4 (and all future Rules with Age ≥ 18 = N).

Condition	Rule 1	Rule 2	Rule 3
Age ≥ 18	Y	Y	N
Has res. card	Y	N	-
Action	Fast-track Review	Standard Review	Reject

The above example reduces the number of rules by 1 (from 4 to 3). This may seem insignificant, but the savings grow with each added condition:

• 3 conditions → 2³ = 8 rules, half of which would have Age ≥ 18 = N , thus we merge 4 rules into 1

• 4 conditions → 2⁴ = 16 rules, we can merge 8 rules into 1

The above example shows only ONE row that offers an opportunity to merge rules.

ANY ROW may allow merging, not just the 1st one.

A table may have MULTIPLE rows that allow rule merging.

Merging Conditions

Watch out for logically inverse conditions. They are redundant.

Either of the conditions can be removed and the table will not lose meaning or coverage

Condition	Rule 1	Rule 2
Income > 60k	Y	N
Income < 60k (^ inverse, can be removed)	N	Y
Action	Approve	Reject

Checking for Completeness and Accuracy

The following problems can occur in decision tables:

1. Condition and Rule redundancy (demonstrated above by merging rules)

2. Incompleteness

3. Impossible situations or contradictions

How do I check for incompleteness?

• If there are no merged rules, and assuming only Y/N values, your table must have exactly 2ⁿ rules. Fewer indicates missing rules.

• If there are merged rules, then it depends. Assuming a simple scenario from above where the same value always leads to the same result ( Age ≥ 18 = N → Reject ), you can calculate the correct number of rules that you should have:

Total Conditions	Total Rules	Mergeable (exactly half)	Reduced Rules After Merge
3	8	4 → 1	5
4	16	8 → 1	9
5	32	16 → 1	17
n	2ⁿ	2ⁿ⁻¹ → 1	2ⁿ⁻¹ + 1

If your table with 5 conditions has 15 rules, it may be missing 2 rules (should be 17).

In other cases, you will have DIFFERENT logic and a DIFFERENT way of deducing whether your table is incomplete.

How do I find impossible situations or other issues?

It is arguably impossible to list an exhaustive list of problems in decision tables. One must rely on strong logical reasoning. Nonetheless, here are a few examples.

Example 1:

• Rule 1: overlapping truth. If someone earns ≥ 60k, it is also true that they earn ≥ 30k - so both conditions being Y is logically valid, but potentially redundant or overlapping.

• Possible fix: redefine 2nd condition to 30k ≤ Income < 60k

Condition	Rule 1 ❌	Rule 2	Rule 3	Rule 4	Rule n
Income ≥ 60k	Y	Y	N	N
Income ≥ 30k	Y	N	Y	N
Action	Approve	Approve	Review	Reject

Example 2: Direct contradiction

• If we KNOW that a passport was ISSUED to a person, how can we then assert that the person has NO valid passport. What does "valid" mean anyway?

• This example also highlights that contradicting values may be many rows apart and thus not obvious.

• Possible fix: clarify condition definitions. Perhaps Passport Expired instead of Valid (which is too broad)?

Condition	Rule 1	Rule 2	Rule 3 ❌	Rule n
Has Valid Passport	Y	N	N
Is Resident of Country A	Y	Y	N
Passport Issued by Country A	Y	N	Y
Action	Auto Verify	Manual Check	???

Pivoting the Table

It is possible to have rules as both columns and rows.

There is little difference when the tables are small, but starting from ca. 2³=8 and more rules, it may become inconvenient to have rules as columns (seen until now). 8+ rules as columns might look OK in a spreadsheet or a specialised tool on a wide screen, but much less so on static websites or wikis such as this one.

In such cases, consider pivoting the table (flipping rows and columns).

🚗 Example: Car Insurance Premium Decision Table

3 binary conditions:

• Gender: Male / Female

• Age: Under 21 / 21 or Older

• Car Type: Normal / Sports Car

We assume these affect price. For example:

• Sports cars cost more

• Young drivers cost more

• Young males driving sports cars pay the most (we wonder why)

Condition	Rule 1	Rule 2	Rule 3	Rule 4	Rule 5	Rule 6	Rule 7	Rule 8
Gender	M	M	M	M	F	F	F	F
Age ≥ 21	Y	Y	N	N	Y	Y	N	N
Sports Car	N	Y	N	Y	N	Y	N	Y
Premium ($)	1200	1600	1800	2500	1000	1400	1500	2200

Notice 2 new things about the above table:

• The first row is in the format Gender=M/F, as opposed to Is Male=Y/N. This is OK because there are still only two options, and it reads fluently.

• There is Premium={value} instead of Specific Action=X or Action=Verb. This is OK too. Whatever helps common understanding.

Chances are, whatever device you're using right now, the table view is truncated, and you must scroll back and forth.

Here is the same table but pivoted.

Rule #	Gender	Age ≥ 21	Sports Car	Premium ($)
1	M	Y	N	1200
2	M	Y	Y	1600
3	M	N	N	1800
4	M	N	Y	2500
5	F	Y	N	1000
6	F	Y	Y	1400
7	F	N	N	1500
8	F	N	Y	2200

This format is preferred by many and follows the typical format of "1 test case per row".

Speaking of test cases, we can use this pivoted format to fill the table with concrete test border values.

Filling With Test Data

🚗 Car Insurance Premium – With Example Values

Notice that:

• The "age" column was moved to the left. As the author of a test model, you can decide the order to achieve greatest possible clarity.

• If we replace "Rule" with "Test Case", we'll get a classic test case table.

• Ages 20 and 21 are border values. You may add 22 as min+ for additional testing.

Rule	Age	Gender	Car Type	Premium ($)
Rule 1	20	Male	Sports	2500
Rule 2	20	Male	Normal	1800
Rule 3	20	Female	Sports	1500
Rule 4	20	Female	Normal	2200
Rule 5	21	Male	Sports	1600
Rule 6	21	Male	Normal	1200
Rule 7	21	Female	Sports	1400
Rule 8	21	Female	Normal	1000

Truth vs. Extended Decision Tables

Up until now, all Decision Tables have been Truth Tables - they only allow conditions with binary values (Yes/No, Male/Female, Under/Over 21, Normal/Sports). They grow at 2ⁿ.

The next logical question is "but what if we have business rules that demand non-binary values"? In other words, what if we have many partitions?

Examples:

• 3 age groups: x < 21, 21 ≤ x < 65, and x ≥ 65

• 3 (or more) car types: Family, Sports, All Other

It's entirely normal to allow 3+ values in a condition. Such tables are called Extended Decision Tables.

Then they no longer grow at 2ⁿ. Instead:

🔢 Formula for Total Rules:

If you have:

• C₁ possible values for Condition 1

• C₂ possible values for Condition 2

• C₃ possible values for Condition 3

• ...

Then total rules = C₁ × C₂ × C₃ × ... × Cₙ

Given the example of Car Insurance:

• Age: Under 21 / 21–64 / 65+ → 3 values

• Gender: Male / Female → 2 values

• Car Type: Family / Sports / Other → 3 values

Total rules = 3 × 2 × 3 = 18 rules (before merging)

Changing to Decision Trees

You can represent a (simpler and smaller) Decision Table with a Decision Tree.

Let's take a Table with 3 binary conditions (gender, age, car type) that has 8 rules and recreate it as a Tree.

✅ Use a Decision Tree when:

• You want a visual, easy-to-follow flow of decisions.

• You need to explain logic to non-technical users.

• Some conditions matter more early.

• You want to quickly trace a path from input to outcome.

❌ Avoid Decision Trees when:

• You have many conditions with complex combinations.

Advantages over Decision Tables:

• Easier to understand at a glance.

• Naturally represents prioritization of conditions.

Downsides:

• It can get large and messy with many branches. (Drawing and re-drawing take time).

Open-source and Free Tools

1. Decision Table Online: https://rendersnail.com/tools/decision-table-online

2. Drools: https://www.drools.org/

Further Reading

1. https://www.hillelwayne.com/post/decision-table-patterns/

2. Factoring large and complex decision tables into several smaller ones

367KB

Factoring-Decision-Table-Knowledge.pdf

PDF

Open