Minimizing Decision Tables with Don't-Care Values (ISTQB CTAL-TA: Rule-Based Test Techniques)
Overview
Decision table testing is one of the core rule-based techniques in the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus. A full decision table lists every combination of conditions. With many conditions it quickly becomes too large to be practical. Minimization (also called collapsing or simplifying) reduces the number of columns, or rules. It does this by merging columns whose outcome does not depend on one or more conditions. Those conditions are then marked as don't-care values, usually shown as '-'.
Why It Is Important
Combinatorial explosion: n Boolean conditions produce 2^n combinations. For example, 5 conditions give 32 columns and 10 conditions give 1024. Minimization makes the technique usable on real business rules.
Test effort and cost: each column in the final table normally becomes at least one test case. Fewer columns means fewer tests while keeping the essential business rules covered.
Clarity of requirements: a minimized table shows which conditions actually drive each outcome. This often exposes ambiguous, incomplete or contradictory requirements. Finding these is an important static-testing benefit for the Test Analyst.
Risk-based decisions: the Test Analyst must decide whether to use a full or a minimized table. This choice depends on risk, because minimization assumes the implementation really ignores the don't-care conditions. That assumption may not hold if the code contains defects.
What It Is
A decision table has two parts:
1. Conditions, the inputs or states (for example, 'Credit score good?'). Values are T/F for limited-entry tables, or several values for extended-entry tables.
2. Actions, the expected outcomes (for example, 'Approve loan'), marked X or left blank.
Each column is a rule, meaning a unique combination of condition values together with its resulting actions.
A don't-care value ('-') means the value of that condition does not affect the outcome of that rule. The CTAL-TA syllabus also distinguishes N/A for an infeasible condition value. An example is a condition that cannot be evaluated because an earlier condition already makes it meaningless or impossible.
How It Works: The Merging Procedure
1. Build the full table with all combinations. This guarantees completeness.
2. Find pairs of columns that are identical in all actions and differ in exactly one condition.
3. Merge each such pair into one column. Replace the differing condition with '-'.
4. Repeat. Merged columns can merge again if they share the same don't-care positions, identical actions, and differ in exactly one remaining condition.
5. Remove infeasible columns, or mark them N/A.
6. Check the result. Every original combination must be covered by exactly one column: no gaps and no overlaps.
Counting rule: for Boolean conditions, a column with k don't-cares represents 2^k original combinations. In an extended-entry table, a '-' on a condition with m possible values represents m combinations. The represented combinations across all columns must add up to the size of the full table.
Worked Example
Conditions:
C1 = Credit score good?
C2 = Income sufficient?
C3 = Existing customer?
Actions:
A1 = Approve
A2 = Reject
A3 = Apply loyalty discount
Business rules:
- A bad credit score is always rejected.
- Good credit with insufficient income is rejected.
- Good credit with sufficient income is approved, and existing customers also get the discount.
The full table has 2^3 = 8 columns.
Collapsing:
- The four columns with C1=F all lead to Reject, so they merge into (F, -, -). This column represents 4 combinations.
- The columns (T, F, T) and (T, F, F) both lead to Reject, so they merge into (T, F, -). This column represents 2 combinations.
- (T, T, T) leads to Approve + Discount and stays as it is.
- (T, T, F) leads to Approve and stays as it is.
Result: 4 columns instead of 8. Check: 4 + 2 + 1 + 1 = 8, so the table is complete with no overlap.
Note that minimization is not always unique. In this example, you could instead merge (T,F,-) with (F,F,-) to get (-,F,-), leaving (F,T,-). The column count is the same, but the layout differs. Exam questions usually ask for the minimum number of columns or test cases, not one specific layout.
Turning Columns into Tests
For a don't-care condition, the tester chooses any valid value when writing the concrete test case. A good Test Analyst picks values deliberately, for example varying them across tests or choosing the riskier value. This partly compensates for the assumption that the condition really is irrelevant.
Coverage
Decision table coverage = (number of exercised feasible columns) / (total number of feasible columns) x 100%.
When a minimized table is used, coverage is measured against the minimized columns. One test per column gives 100% coverage.
Infeasible (N/A) combinations are excluded from the denominator.
Risks and Limitations
- Minimization assumes the implementation behaves as specified. If the code wrongly evaluates a don't-care condition, a minimized table may miss the defect. For high-risk or safety-critical rules, consider the full table.
- Merging columns with different actions is an error, because it loses a rule.
- Overlapping columns, where one combination matches two rules, indicate contradictory requirements if the actions differ, or redundancy if they are the same.
Exam Tips: Answering Questions on Minimizing Decision Tables with Don't-Care Values
1. Start from the full table size. Compute 2^n for Boolean conditions, or the product of value counts for extended entries. Many questions test whether you can confirm a minimized table is complete.
2. Use the 2^k check. Sum the combinations each column represents. If the total is below the full size, the table is incomplete. If it is above, columns overlap. This quickly eliminates wrong options.
3. Merge only when actions are identical and exactly one condition differs. Distractor answers often merge columns with slightly different actions.
4. Look for the 'dominant' condition. A condition that forces an outcome regardless of the others (like C1=F above) usually collapses into a column full of '-'.
5. Know the difference between '-' and N/A. '-' means the value is irrelevant to the outcome. N/A means the combination is infeasible. N/A columns are not tested and not counted for coverage.
6. Minimum tests = number of columns in the minimized table, one test per rule, for 100% decision table coverage. Do not count the full-table combinations unless the question asks about the full table.
7. Read the question carefully: full or minimized? Phrases like 'without collapsing' or 'all combinations' require the full count.
8. Expect scenario questions. You may get business rules in text (insurance, discounts, access control) and be asked how many rules or tests are needed. Sketch the table quickly on scratch paper and collapse it step by step.
9. Remember the trade-off. Questions may ask when to avoid minimization. The answer usually involves high risk, untrusted implementations, or a need to detect defects in how conditions interact.
10. Concrete values for don't-cares: any valid value is acceptable. Answers claiming the tester must test all values of a don't-care condition, for minimized coverage, are wrong.
11. Watch for contradictions. If two rules cover the same combination with different actions, the correct answer is often 'the specification contains a contradiction and should be raised as a defect'.
Summary
Minimizing decision tables with don't-care values keeps rule-based testing efficient and readable. Merge columns that differ in one condition and share identical actions, mark the irrelevant condition '-', and verify completeness with the 2^k counting check. Then derive one test per remaining column. In the exam, combine careful counting with an awareness of the risk trade-off and of the difference between '-' and N/A.
