Decision Table Testing

When multiple conditions combine to produce different outcomes, ad-hoc testing leaves combinations untested

Consider a shipping discount rule: "Free shipping if the user is a premium member AND the order is over £50, OR if a promo code is applied." How many combinations exist? How do you ensure all meaningful combinations are tested without duplicating effort?

Decision table testing provides a systematic way to identify all combinations of conditions and map them to expected actions. It is the technique of choice whenever business logic involves multiple conditions that interact.

// example: stripe — payment processing rules

Scenario: Stripe's payment processing has rules that combine multiple conditions: Is the card valid? Is the account balance sufficient? Is the transaction within the daily limit? Is fraud detection triggered? What happened: Without a decision table, a QA team tested the happy path (all conditions true) and a few failure cases. They missed the combination where the card was valid and the balance sufficient, but the fraud flag was triggered — which should decline the payment but instead processed it without flagging the account. A decision table would have made that combination explicit. Why it matters: Business logic defects almost always hide in untested combinations. A decision table makes every combination visible before a single test is executed.

Decision Table Testing — CTFL 4.0.1

A decision table maps combinations of conditions (inputs/states) to expected actions (outputs/results). It ensures systematic coverage of all meaningful condition combinations.

Structure of a decision table

Conditions — the inputs or states that affect the outcome (rows at the top)
Actions — the expected outputs or system behaviour (rows at the bottom)
Rules — each column represents a unique combination of conditions and its corresponding actions

Counting rules

For a table with binary (true/false) conditions, the maximum number of rules = 2ⁿ where n is the number of conditions.

2 conditions → 2² = 4 rules
3 conditions → 2³ = 8 rules
4 conditions → 2⁴ = 16 rules

Collapsed decision tables

When some conditions do not affect the outcome for certain combinations, a "don't care" value (—) is used to collapse multiple rules into one. This reduces the total number of test cases without losing coverage.

// tip: Exam Tip: The formula 2ⁿ gives the maximum number of rules for n binary conditions. The exam will give you a scenario with conditions and ask how many rules the full decision table has. Count the conditions, apply 2ⁿ. For 3 conditions: 2³ = 8 rules. Collapsed tables may reduce this number, but only when "don't care" values are valid.

Step-by-Step: Building a Decision Table

Scenario: A banking app approves a loan if: the applicant has a credit score above 700 AND annual income above £30,000. If either condition fails, the loan is rejected and a reason message is shown.

Rule	R1	R2	R3	R4
Condition 1: Credit score > 700	T	T	F	F
Condition 2: Income > £30,000	T	F	T	F
Action: Approve loan	✓	✗	✗	✗
Action: Show rejection reason	✗	Income too low	Credit score too low	Both conditions failed

Steps to build:

Identify all conditions (2 here: credit score, income)
Calculate total rules: 2² = 4
Fill condition rows with all T/F combinations (use binary counting pattern)
Determine the expected action for each rule
Each rule becomes one test case

Decision Table Builder

// Conditions (inputs)

Rules: 2ⁿ = 2^2 = 4

// Rules (columns)

Condition

Credit score > 700

Income > £30,000

Approve loan

—

Reject + show reason

✓

// "Don't care" (—) values

Click a condition value to cycle: T → F → — (don't care). When a condition is "don't care", its value does not affect the action for that rule — allowing you to collapse multiple rules into one.

// Exam trap

Conditions are inputs the system checks (e.g., "Is user premium?"). Actions are outputs (e.g., "Apply discount"). The exam will ask you to identify which is which — get this right before counting rules.

When to Use Decision Table Testing

Situation	Use Decision Table?	Reason
Multiple conditions that combine to produce different outcomes	Yes — ideal	Systematically captures all combinations
Business rules with IF/AND/OR logic	Yes — ideal	Makes implicit logic explicit and testable
Single input range validation (e.g. age 18–65)	No — use EP/BVA	Only one condition; decision table adds no value
System with defined states and transitions	No — use state transition	States and transitions are better modelled differently
Very large number of conditions (5+)	Use with caution	2⁵ = 32 rules — consider pairwise testing instead

// warning: Exam Trap: Confusing "conditions" with "actions." Conditions are the inputs or states that the system checks (e.g., "Is the user logged in?"). Actions are the system's responses or outputs (e.g., "Show dashboard" or "Redirect to login"). The exam will describe a scenario and ask you to identify which are conditions and which are actions — get this distinction right before counting rules.

Exam Practice Questions

// ctfl 4.0.1 style — select an answer to reveal explanation

Q1.A system has 4 binary conditions. How many rules does the full decision table contain?

Q2.In a decision table, what does a "don't care" value (—) in a condition row mean?

Q3.A tester is designing tests for a feature with 3 conditions: user is premium (Y/N), order total above £50 (Y/N), promo code applied (Y/N). How many test cases are needed for full decision table coverage?