Decision Table Testing

What Is Decision Table Testing? #

Decision table testing is a black-box technique for testing systems where the output depends on combinations of conditions. When business rules involve multiple inputs that interact to determine the outcome, a decision table ensures you test every meaningful combination.

When to Use Decision Tables #

Use this technique when:

• Multiple conditions combine to determine an outcome
• Business rules contain complex if/then/else logic
• The specification says “if A and B, then X; if A and not B, then Y”
• You need to verify that every combination is handled correctly

Anatomy of a Decision Table #

A decision table has four quadrants:

                    | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
--------------------|--------|--------|--------|--------|
Conditions:         |        |        |        |        |
  Condition 1       |   T    |   T    |   F    |   F    |
  Condition 2       |   T    |   F    |   T    |   F    |
--------------------|--------|--------|--------|--------|
Actions:            |        |        |        |        |
  Action 1          |   X    |   X    |        |        |
  Action 2          |        |        |   X    |   X    |

• Conditions (top half): Input conditions that can be true (T) or false (F)
• Rules (columns): Each unique combination of condition values
• Actions (bottom half): The expected outcomes for each rule
• X marks which actions should occur for each rule

Building a Decision Table: Step by Step #

Example: Insurance Claim Processing #

Business rules:

• If the claimant is a member AND the claim is under $1000, auto-approve
• If the claimant is a member AND the claim is $1000+, send to manager
• If the claimant is NOT a member AND the claim is under $1000, send to review
• If the claimant is NOT a member AND the claim is $1000+, reject

Conditions:

1. Is member? (T/F)
2. Claim < $1000? (T/F)

Decision table:

4 rules = 4 test cases. Each test case exercises a unique combination.

Handling More Than Two Values #

When conditions have more than two values, the table grows accordingly. A condition with 3 values combined with a binary condition produces 3 x 2 = 6 rules.

Example: Shipping speed + membership

Simplifying Decision Tables #

When two rules have the same actions and differ in only one condition, you can merge them. The irrelevant condition is marked with a dash (-).

Before simplification:

After simplification:

Condition A doesn’t matter when B is true — one rule replaces two.

Advanced Decision Table Techniques #

Handling Large Tables #

With N binary conditions, a full table has 2^N rules. For 5 conditions, that’s 32 rules. For 10 conditions, 1024. Large tables become impractical, so use these strategies:

1. Eliminate impossible combinations. Not all combinations can occur in reality.

Condition: "User is logged in" = F
Condition: "User role is admin" = T
→ Impossible: you can't be admin if not logged in

2. Identify independent conditions. If some conditions don’t interact, split into separate smaller tables.

3. Use cause-effect graphing (covered in lesson 3.5) to identify constraints between conditions.

Decision Tables for API Testing #

Decision tables excel at testing API endpoints with multiple parameters that affect the response:

Example: GET /orders endpoint

Notice the cascading pattern: early failures (auth, permission) make later conditions irrelevant (marked with -).

Extended Entry Decision Tables #

Instead of T/F, conditions can have specific values. This is called an extended entry table.

Example: Tax calculation

Exercise: Build a Decision Table #

Scenario: A bank loan approval system uses these rules:

• Credit score: Good (700+) or Poor (<700)
• Employment: Employed or Unemployed
• Existing debt: Low (<50% of income) or High (>=50%)

Rules:

• Good credit + Employed + Low debt → Approve at standard rate
• Good credit + Employed + High debt → Approve at higher rate
• Good credit + Unemployed + Low debt → Manual review
• Good credit + Unemployed + High debt → Reject
• Poor credit + Employed + Low debt → Approve at higher rate
• Poor credit + Employed + High debt → Reject
• Poor credit + Unemployed → Reject (regardless of debt)

Task: Build the decision table. How many test cases are needed? Can any rules be simplified?

Pro Tips #

• Start with the specification. Every “if/then” in the requirements maps to conditions and actions. Highlight them.
• Validate with stakeholders. Decision tables make business rules visible. Walk through the table with product owners to catch missing or contradictory rules.
• Watch for default actions. What happens when no rule matches? The specification might not say — that’s a defect in the spec.
• Use decision tables for regression test selection. When a business rule changes, the affected rules in the table show exactly which test cases to re-run.
• Combine with EP and BVA. After identifying rule combinations with the decision table, use EP and BVA to select specific values for each condition.