Decision Table Testing
Decision table testing is a black-box test design technique for rules in which a combination of conditions decides the outcome. Conditions and actions form the rows; each column is a decision rule, one combination of condition values with its actions. "Transfers to a saved beneficiary go through immediately; transfers above 5,000.00 SAR to a new beneficiary need a one-time password" has two conditions, so four columns, and says nothing about one of them: a small transfer to a new beneficiary.
Building on the business rules lesson and its T, F and X table, this lesson adds the full notation, minimised tables, coverage, and a count that finds forgotten rules.
Why it matters
Defects in multi-condition rules hide in the one combination nobody discussed: the frozen account that can still pay a saved beneficiary, or the customer who falls between two sentences of a requirement and gets whatever the code happens to do. Typical cases pass either way.
A decision table makes every combination visible and countable. Built during a requirements review, it turns gaps and contradictions into questions for the product owner instead of defects in production.
Conditions, actions and decision rules
Condition rows hold what the rule depends on; action rows hold what the system must do. A full table has one column per combination of condition values: three true/false conditions give 2 × 2 × 2 = 8 columns.
If every condition is only true or false, the table is limited-entry. In an extended-entry table a condition, or an action, can take several values, such as ranges, equivalence partitions or discrete values like "tier: standard, silver, gold". The column count is then the product of the value counts: one three-value and two true/false conditions give 3 × 2 × 2 = 12. The ISTQB Foundation syllabus uses this notation:
T: the condition is true;F: it is false. The syllabus allows other notations, and some tools writeYandN.–: the condition is irrelevant in this column; any value gives the same actions. It is often called "don’t care" and typed as a hyphen,-.N/A: the condition is infeasible for this rule, for example "card expired" when the customer pays in cash.X: the action must happen; blank: it must not.
Worked example: finding missing and conflicting rules
Requirement TR-07 for a mobile banking app: "S1. Transfers to a saved beneficiary are processed immediately. S2. Transfers of more than 5,000.00 SAR to a new beneficiary are processed after the customer enters a one-time password (OTP). S3. Transfers from a frozen account are rejected."
Three conditions (account frozen, beneficiary saved, amount above 5,000.00 SAR), three actions (reject, process after OTP, process immediately). Do the sentences cover every combination exactly once? Four steps tell.
- Count. Write each sentence as a column with
–for every condition it does not mention, as in the table below. With true/false conditions, one–stands for 2 combinations, two for 4: S1 and S3 give 4 each, S2 gives 2, 10 in total, but only 8 combinations exist. Above 8 means at least one overlap, below 8 at least one gap; an overlap is a conflict when its sentences give different actions. - Expand. A matching total proves nothing, since a gap and an overlap can cancel each other out, so mark the sentences that apply to each column of the full table. Columns 1 to 3, a frozen account with a saved beneficiary or an amount above 5,000.00 SAR, are conflicts: S3 rejects, S1 or S2 processes. Column 8, up to 5,000.00 SAR to a new beneficiary from an active account, is a gap.
- Ask. Take both to the product owner instead of guessing. The answers: a freeze blocks every transfer, and up to 5,000.00 SAR to a new beneficiary is processed immediately. Record them in the requirement.
- Look beyond the table. It checks only the conditions you listed, so ask about missing conditions (a daily limit, another currency) and missing actions (the message shown after a rejection).
TR-07 as written: one column per sentence
Frozen Saved > 5,000.00 SAR Action Stands for
S1 – T – process immediately 4 combinations
S2 – F T process after OTP 2 combinations
S3 T – – reject 4 combinations
Total 10, but only 8 exist| Decision table column | Account frozen | Beneficiary saved | More than 5,000.00 SAR | TR-07 as written | After the product owner’s answers |
|---|---|---|---|---|---|
| Column 1 | T | T | T | S1 + S3conflict: process immediately or rejectCaution | rejectproduct owner’s answer |
| Column 2 | T | T | F | S1 + S3conflict: process immediately or rejectCaution | rejectproduct owner’s answer |
| Column 3 | T | F | T | S2 + S3conflict: process after OTP or rejectCaution | rejectproduct owner’s answer |
| Column 4 | T | F | F | S3rejectPass | reject |
| Column 5 | F | T | T | S1process immediatelyPass | process immediately |
| Column 6 | F | T | F | S1process immediatelyPass | process immediately |
| Column 7 | F | F | T | S2process after OTPPass | process after OTP |
| Column 8 | F | F | F | No sentencegapFail | process immediatelyproduct owner’s answer |
- FailGap: no sentence says what happens
- CautionConflict: two sentences give different actions
- Settled by the product owner’s answer
Each row is one column of the full decision table. T: the condition is true; F: it is false. S1, S2 and S3 are the sentences of TR-07.
Full, simplified and minimised tables
The ISTQB syllabus names two ways to shrink a table. A simplified table deletes the columns whose combination of conditions is infeasible: with the conditions "above 5,000.00 SAR" and "above 20,000.00 SAR", no amount is above 20,000.00 but not above 5,000.00, so every column with F for the first and T for the second is deleted. A minimised table, which some books and tools call collapsed, merges columns that have the same actions and differ in exactly one condition, which becomes –.
In the clarified TR-07, columns 1 to 4 all reject and merge in two steps into R1 (T, –, –); columns 5 and 6 merge into R2 (F, T, –); columns 7 and 8 stay as R3 and R4. Check with the same count: 4 + 2 + 1 + 1 = 8. Other merges are possible, such as column 8 with column 6. Every result built only from such valid merges is correct; the count is a quick check, not a proof.
Full table (TR-07 with the product owner’s answers)
1 2 3 4 5 6 7 8
Account frozen T T T T F F F F
Beneficiary saved T T F F T T F F
Amount > 5,000.00 SAR T F T F T F T F
Reject X X X X
Process after OTP X
Process immediately X X X
Minimised table R1 R2 R3 R4
Account frozen T F F F
Beneficiary saved – T F F
Amount > 5,000.00 SAR – – T F
Reject X
Process after OTP X
Process immediately X X
Stands for 4 2 1 1 = 8 combinationsCoverage and choosing test values
The coverage items are the columns with feasible combinations of conditions, and coverage is the share of them your tests exercise. The four test cases below, one per minimised column, give 100% coverage of the minimised table but 4 of 8, or 50%, of the full table, so always say which table you measured.
A minimised table assumes the code really ignores each – condition. If the code checked the amount before the freeze, a frozen account paying 6,000.00 SAR to a new beneficiary would get an OTP prompt, which only a test of full-table column 3 shows. For rules that move money, consider all 8 columns.
A – still needs a concrete value: pick the one that would change the action if the condition mattered after all. R1 uses a saved beneficiary, since a frozen account that still sends money is the worst failure; R2 uses a large amount, in case every large transfer asks for an OTP. Ranges are tested at the boundary, as in boundary value analysis: 5,000.01 for R3, 5,000.00 for R4.
Test Rule Account Beneficiary Amount (SAR) Expected result
TC-1 R1 frozen saved 6,000.00 rejected, no money leaves the account
TC-2 R2 active saved 6,000.00 processed immediately, no OTP asked
TC-3 R3 active new 5,000.01 OTP asked, processed after a valid OTP
TC-4 R4 active new 5,000.00 processed immediately, no OTP askedCommon mistakes
- Writing columns only for the combinations the requirement mentions.
- Putting
–where the requirement is silent. Silence is a question for the product owner, not proof that a condition is irrelevant. - Merging columns that have different actions or differ in more than one condition.
- Trusting the column total alone: a gap and an overlap can cancel each other out.
- Reporting "100% coverage" without saying whether the full or the minimised table was measured.
- Using a decision table when the outcome depends on the order of events, such as a lockout after three failed sign-ins; that calls for state transition testing.
The QA perspective
Decision tables pay off most in refinement and requirements review. When a story joins conditions with "and", "or", "unless" or "except", sketch the table in the meeting, count the columns and raise every gap and overlap at once. Record the answers in the requirement and keep the table, labelled with its rule version, beside the test cases.
Before relying on a minimised table, ask the developer in which order the conditions are evaluated. Trace each test case to its column, report coverage as "4 of 4 columns of the minimised table", and update the table first when the rule changes: a new true/false condition doubles the full table.
Practice exercise
Check a cancellation rule for gaps and conflicts
A food-delivery app has the cancellation rule below. Build its decision table, find the gaps and conflicts and write your questions for the product owner. Then minimise the clarified table and count the test cases for 100% coverage of it.
CR-2 Order cancellation
1. Orders the restaurant has not accepted yet can be cancelled with a full refund.
2. Accepted orders paid in cash cannot be cancelled.
3. Subscribers who paid by card get a 50% refund when they cancel.- List the conditions and the actions.
- Write each sentence as a column with
–entries; add up the combinations. - Expand to the full table; mark the sentences that apply to each column.
- Write your questions, assume the likely answers, minimise.
Show the model answer
Conditions: accepted, paid by card, subscriber. Actions: full refund, 50% refund, refused. Sentence 1 is (F, –, –), 4 combinations; sentence 2 (T, F, –), 2; sentence 3 (–, T, T), 2. The total is 8: it looks complete, and it is not.
Full table, T before F, first condition slowest: column 1 (T, T, T) 50% refund; column 2 (T, T, F), an accepted card order from a non-subscriber, matches no sentence: a gap; columns 3 and 4 refused; column 5 (F, T, T) matches sentences 1 and 3: a conflict; columns 6 to 8 full refund.
Questions: what does a non-subscriber get for cancelling an accepted card order? Does a subscriber who paid by card get a full refund or 50% when the order is not accepted yet? What about wallets?
If column 2 is refused and column 5 gets a full refund, the minimised table is (F, –, –) full refund, (T, F, –) refused, (T, T, F) refused, (T, T, T) 50% refund: 4 + 2 + 1 + 1 = 8. Four test cases give 100% coverage of it, 50% of the full table.
Frequently asked questions
How many conditions are too many for one decision table?
There is no fixed limit, but the full table doubles with every true/false condition: 4 conditions give 16 columns, 5 give 32. Before you build a table that large, check whether the rule splits into independent parts, such as eligibility first and then the fee, each with its own small table. If many columns remain, test the minimised table or choose columns by risk. When you have many independent parameters that no rule links, pairwise testing fits better.
Should I test the full table or the minimised one?
The minimised table is enough when the risk is low and you trust that the code ignores each – condition. Test the full table, or at least the columns most likely to go wrong, when the rule moves money, decides access or eligibility, or when you know the code checks the conditions in a different order than the table suggests.
Do decision tables replace equivalence partitioning and boundary value analysis?
No, they work together. Equivalence partitioning gives the values of each condition, such as amounts up to 5,000.00 SAR and above it. The decision table combines those values into rules. Boundary value analysis then picks the concrete amounts inside each column, such as 5,000.00 and 5,000.01.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
Practise with Mutqan tools
Build decision tables from conditions and actions, generate all rule combinations and collapse impossible ones.
Derive valid and invalid equivalence classes for each input and pick representative test values.
Generate boundary values (min-1, min, min+1, nominal, max-1, max, max+1) for numeric and length constraints.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.