Full Decision Tables and Infeasible Rules (ISTQB CTAL-TA: Rule-Based Test Techniques)
Overview
Decision table testing is one of the main rule-based test techniques in the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus. It models how a system responds to combinations of conditions. Two ideas cause the most trouble for candidates. The first is the full decision table, which lists every possible combination of condition values. The second is the infeasible rule, a combination of values that cannot occur in reality. Understanding both is essential for building correct tables, calculating coverage and answering exam questions accurately.
1. Why It Is Important
• Completeness: A full decision table forces the analyst to consider every combination. This exposes gaps in requirements, such as combinations nobody specified an outcome for.
• Defect prevention: Building the table often reveals contradictions (one combination with two conflicting actions) and redundancies before any code is written.
• Correct coverage measurement: Coverage is calculated against feasible rules only. If infeasible rules are not identified, coverage figures are understated and testers waste effort trying to create impossible tests.
• Efficiency: Removing infeasible rules and collapsing rules with 'don't care' entries reduces the number of test cases without losing important behaviour.
• Requirements validation: Labelling a rule 'infeasible' is an assumption. Asking stakeholders to confirm it can reveal hidden requirements, for example when a combination believed impossible actually happens in production through data migration or an interface.
2. What It Is
Decision table structure:
• Conditions (upper rows) are the inputs or states that influence the outcome.
• Actions (lower rows) are the outputs or behaviours the system performs.
• Rules (columns) are each a unique combination of condition values together with the resulting actions.
Notation commonly used:
• T / F (or Y / N, 1 / 0) are Boolean condition values.
• '–' means don't care: the value does not affect the outcome.
• 'N/A' means not applicable: the condition is meaningless or impossible in that rule.
• X marks an action that occurs. A blank means the action does not occur.
Limited-entry vs extended-entry tables:
• In limited-entry tables, every condition is Boolean.
• In extended-entry tables, conditions can take several values, for example Membership = Gold / Silver / None. These values are often derived from equivalence partitions.
Full decision table: A table containing every combination of condition values.
• For n Boolean conditions, the number of rules is 2^n. So 3 conditions give 8 rules and 4 conditions give 16 rules.
• For extended-entry conditions, the number of rules is the product of the number of values of each condition. For example, 3 × 2 × 2 = 12 rules.
Infeasible rule: A column whose combination of condition values cannot occur. Typical causes are:
• Mutually exclusive conditions: 'Age < 18' and 'Age ≥ 65' cannot both be true.
• Logical dependency: If 'Customer has an account' = F, then 'Account is overdrawn' = T is impossible.
• Physical or business constraints: For example, 'Delivery date before order date' when the system enforces sequencing.
Don't care is not the same as infeasible:
• Don't care (–) means the combination CAN occur, but the condition's value does not change the outcome.
• Infeasible means the combination CANNOT occur at all.
This distinction is a classic exam trap.
3. How It Works: Step by Step
Step 1: Identify the conditions and actions from the requirements or business rules.
Step 2: Determine the possible values of each condition, either Boolean or partitioned.
Step 3: Calculate the number of rules using 2^n or the product of the value counts.
Step 4: Build the full table systematically. A common pattern for 3 Boolean conditions is:
• Condition 1 alternates in blocks of 4 (TTTTFFFF).
• Condition 2 alternates in blocks of 2 (TTFFTTFF).
• Condition 3 alternates singly (TFTFTFTF).
Step 5: Mark the infeasible rules. Examine each column for impossible combinations and mark them, for example as 'infeasible' or with N/A. They receive no actions.
Step 6: Determine the actions for each feasible rule from the specification. Flag any rule with no specified outcome as a requirements gap.
Step 7 (optional): Minimise or collapse the table. Merge rules that differ in only one condition and have identical actions, replacing that condition with '–'. Repeat until no further merging is possible.
Step 8: Derive test cases. Normally create at least one test per feasible rule (column) of the table being used.
Worked Example 1 (Boolean conditions with dependency)
Conditions:
• C1: Registered customer?
• C2: Loyalty card linked? (only registered customers can link a card)
• C3: Order value > 100?
Actions: A1 is 10% discount, A2 is free shipping.
The full table has 2^3 = 8 rules:
• R1: T,T,T gives A1 and A2
• R2: T,T,F gives A1
• R3: T,F,T gives A2
• R4: T,F,F gives no action
• R5: F,T,T is infeasible (an unregistered customer cannot have a linked card)
• R6: F,T,F is infeasible
• R7: F,F,T gives A2
• R8: F,F,F gives no action
The table therefore has 8 rules, of which 2 are infeasible and 6 are feasible. Note that R3 and R7 have identical actions and differ only in C1. They can be collapsed into one rule: (–, F, T) gives A2. Likewise, R4 and R8 collapse into (–, F, F) gives no action. The minimised table has 4 columns.
Worked Example 2 (Mutually exclusive Boolean conditions)
Conditions:
• C1: Age < 18
• C2: Age 18–64
• C3: Age ≥ 65
The full table has 8 rules, but exactly one condition can be true at a time. Only 3 rules are feasible (TFF, FTF, FFT) and 5 are infeasible. FFF is impossible because every age falls into one band, and any rule with two or more T values is impossible. Lesson: mutually exclusive Boolean conditions are better modelled as ONE extended-entry condition with three values (Child / Adult / Senior). This produces no infeasible rules at all.
Worked Example 3 (Extended-entry table)
Conditions:
• Membership: Gold / Silver / None (3 values)
• Payment: Card / Cash (2 values)
• Express delivery: Y / N (2 values)
The full table has 3 × 2 × 2 = 12 rules. If the business rule says 'Express delivery cannot be paid in cash', then the 3 rules with Cash + Express = Y are infeasible. That leaves 12 − 3 = 9 feasible rules.
Coverage calculation
Decision table coverage is calculated as:
Coverage = (number of feasible rules exercised by tests) / (total number of feasible rules) × 100%
Infeasible rules are excluded from the denominator. In Example 3, tests covering 6 of the 9 feasible rules achieve 6/9 = 66.7% coverage, not 6/12 = 50%. 100% coverage requires at least one test for every feasible column.
Risks and considerations
• Full tables grow exponentially. Ten Boolean conditions produce 1,024 rules, so minimisation and risk-based selection become necessary.
• Collapsing with '–' assumes the don't-care condition really has no effect. If the implementation is faulty, the untested value may hide a defect.
• A collapsed rule with k dashes represents 2^k original combinations (for Boolean conditions). Some of those combinations may be infeasible.
• An 'infeasible' rule may still be worth testing as a robustness or negative test, for example if corrupted data or an external interface could produce the combination. Even so, it is still excluded from the decision table coverage calculation.
• Always confirm infeasibility with stakeholders or the specification rather than assuming it.
Exam Tips: Answering Questions on Full Decision Tables and Infeasible Rules
1. Count the rules first. Use 2^n for Boolean conditions and multiply the value counts for extended-entry conditions. Many questions are simply 'How many rules does the full table have?' Watch for a condition with 3 values hidden among Boolean ones, for example 2 × 2 × 3 = 12, not 8.
2. Subtract the infeasible rules. Look for keywords such as 'cannot', 'only if', 'mutually exclusive', 'is not possible', 'must be' and 'only applies when'. Each constraint removes a set of combinations. Calculate how many columns each constraint eliminates, and do not double-subtract columns removed by two constraints.
3. Use only feasible rules in the coverage denominator. If a question gives the total rules, the infeasible rules and the rules tested, compute tested / (total − infeasible). Distractor answers often use the total rule count.
4. Know the minimum number of tests for 100% coverage. It equals the number of feasible columns in the table being used. For a full table, that is all feasible rules. For a minimised table, it is the number of collapsed columns. Read carefully to see which table the question refers to.
5. Distinguish '–' from N/A or infeasible. A don't-care rule CAN be executed, and any value can be chosen for the dashed condition. An infeasible rule CANNOT be executed. Questions often ask which statement is correct about these symbols.
6. Check collapsing questions carefully. Two rules can be merged only if (a) they differ in exactly one condition and (b) their actions are identical. If the actions differ even slightly, they cannot be merged.
7. Spot poor modelling. If a scenario uses several Boolean conditions that represent ranges of the same variable, expect many infeasible rules. The better answer is usually to model them as a single extended-entry condition based on equivalence partitions.
8. Identify requirements defects. In K3/K4 scenario questions, a feasible rule with no specified action indicates a gap. A rule with conflicting actions indicates a contradiction. Both are defects to raise, and they are among the key benefits of using a full decision table.
9. Work methodically on paper. Write out the binary pattern (TTTTFFFF / TTFFTTFF / TFTFTFTF) quickly and strike through infeasible columns. This avoids arithmetic slips under time pressure.
10. Eliminate absolute distractors. Be wary of statements such as 'infeasible rules must always be tested to achieve 100% coverage' or 'don't care means the combination is impossible'. Both are false.
11. Remember the benefits and limitations.
• Benefits: systematic coverage of combinations, early detection of requirements defects, and a clear basis for tests.
• Limitations: exponential growth, and reliance on correct identification of conditions and constraints.
Quick Recap
• A full decision table contains all combinations: 2^n for Boolean conditions, or the product of the value counts.
• An infeasible rule is a combination that cannot occur. It is excluded from test design and from the coverage denominator.
• Coverage = exercised feasible rules / total feasible rules.
• Don't care (–) means the value doesn't matter. Infeasible means the combination is impossible.
• Minimise by merging rules that differ in only one condition and have identical actions.
• Always verify infeasibility assumptions with stakeholders, because they can hide requirement defects.
