Decision Table Coverage and Implementing Test Cases from Rules

Decision Table Coverage and Implementing Test Cases from Rules (ISTQB CTAL-TA)

Introduction
Decision table testing is the main rule-based test technique in the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus. It models business logic as a set of conditions (inputs) and actions (outputs). Each column (rule) is one unique combination of conditions and the actions it triggers. This guide covers why the technique matters, how decision table coverage is measured, and how rules become executable test cases. It ends with exam tips and practice questions.

1. Why It Is Important
• Business rules are combinatorial. Defects often hide in combinations of conditions that the developer or requirement writer did not think about. Equivalence partitioning and boundary value analysis look at one input at a time. Decision tables look at the interactions between inputs.
• It finds defects in specifications early. Building the table forces the analyst to ask what should happen for every combination. This exposes three kinds of problem:
  - Incompleteness: a combination with no defined action.
  - Contradiction: overlapping rules with different actions.
  - Redundancy: duplicate rules.
• It gives a measurable coverage criterion. Stakeholders can see objectively how much of the rule logic has been tested.
• It supports traceability and maintenance. Each test traces to exactly one rule. When a rule changes, the affected tests are easy to find.
• It is heavily examined. At Advanced level, decision table testing is applied, not just recalled. Expect scenario questions where you must build, minimize, or analyse a table and count tests or calculate coverage.

2. What It Is: Structure and Notation
A decision table has four parts:
• Condition stubs (upper left): the conditions, e.g. 'Customer is a member?'
• Condition entries (upper right): the values for each rule.
• Action stubs (lower left): the possible outcomes, e.g. 'Apply 10% discount'.
• Action entries (lower right): which actions occur for each rule.

Common notation:
• T/F or Y/N: the condition is true or false.
• – (dash): 'don't care'. The condition value does not affect the outcome for that rule.
• N/A: the condition is infeasible or not applicable for that combination.
• X (or a tick) in the action part: the action occurs. A blank or F means it does not.

Types of tables:
• Limited-entry table: conditions and actions take only Boolean values.
• Extended-entry table: conditions can take several values, e.g. Age group = child / adult / senior. Actions can also take values, e.g. Discount = 0%, 5%, 10%.
• Full decision table: lists every combination. With n Boolean conditions there are 2^n columns. For extended entries, multiply the number of values of each condition. For example, 2 x 2 x 3 = 12 columns.
• Minimized (collapsed) table: columns whose outcomes do not depend on a particular condition are merged using 'don't care'. This keeps all distinct behaviours with fewer columns.

3. What Is Decision Table Coverage?
In decision table testing, the coverage items are the columns that contain feasible combinations of conditions.

Decision table coverage (%) = (number of feasible columns exercised by tests / total number of feasible columns) x 100

Key points:
• 100% coverage needs at least one test case per feasible column.
• Infeasible columns are excluded from the denominator. Example: 'Age < 18' and 'Age > 65' cannot both be true.
• Coverage is measured against the table you are given: full or minimized. A minimized table usually gives fewer coverage items. One test exercising a column with a '–' covers that column. It does not cover all the full-table combinations hidden behind the dash.

4. How It Works: Step by Step
Step 1 – Identify conditions and actions
Read the specification, user story, or business rule. List every independent condition that affects the outcome and every possible action.

Step 2 – Determine the condition values
Decide whether each condition is Boolean or multi-valued. Equivalence partitions are often used to define the values of extended-entry conditions.

Step 3 – Generate all combinations
Build the full table (2^n columns for n Boolean conditions). A systematic way:
• In the first row, alternate values in blocks of half the columns (e.g. YYYYNNNN).
• In the next row, use blocks of a quarter (YYNNYYNN).
• Continue halving until the last row alternates single values (YNYNYNYN).

Step 4 – Determine the actions for each column
Use the specification to fill in the actions. Wherever the specification is silent or ambiguous, raise it with stakeholders. This is static testing and finds specification defects.

Step 5 – Mark infeasible combinations
Remove or mark (N/A) the combinations that cannot occur.

Step 6 – Minimize (optional)
Two columns can be merged when all three of these hold:
• they have identical actions,
• they differ in only one condition,
• all other conditions are equal.
That condition then becomes '–'. Repeat until no further merges are possible. Collapsing reduces the number of tests but carries a risk. If the implementation wrongly depends on the 'don't care' condition, a minimized test set may miss the defect. Use the full table when risk is high.

Step 7 – Derive and implement test cases
One test case per feasible column (see section 6).

5. Worked Example
Rules for an online shop:
• Free shipping is given if the customer is a member OR the order total is at least $100.
• A 10% discount is given only if the customer is a member AND enters a valid coupon.

Conditions:
• C1 = Member?
• C2 = Order total ≥ $100?
• C3 = Valid coupon?

Actions:
• A1 = Free shipping
• A2 = 10% discount

Full table (2^3 = 8 columns):
• R1: Y Y Y → A1, A2
• R2: Y Y N → A1
• R3: Y N Y → A1, A2
• R4: Y N N → A1
• R5: N Y Y → A1
• R6: N Y N → A1
• R7: N N Y → no action
• R8: N N N → no action

Minimization:
• R1 + R3 differ only in C2 and have the same actions → Y – Y → A1, A2.
• R2 + R4 → Y – N → A1.
• R5 + R6 differ only in C3 → N Y – → A1.
• R7 + R8 → N N – → no action.

Minimized table: 4 columns. Results:
• 100% decision table coverage of the minimized table needs 4 test cases.
• The full table would need 8.
• If only 3 of the 4 minimized columns are tested, coverage = 3/4 = 75%.

6. Implementing Test Cases from Rules
A column is an abstract test condition. To make it an executable test case, you add the following:

a) Concrete input values
Turn each condition entry into real data. For 'Order total ≥ $100 = Y', choose a value such as $100.00. Using the boundary value combines decision table testing with boundary value analysis. For 'N', choose e.g. $99.99.

b) Values for 'don't care' entries
Pick any valid value. Good practice is to vary these values across tests (sometimes Y, sometimes N). This increases the chance of detecting an implementation that wrongly depends on that condition.

c) Expected results
Take them directly from the action entries. Example: 'Shipping cost = $0; discount = 10% of total'. Also state that the actions which should NOT happen do not happen, e.g. 'no discount applied'.

d) Preconditions and test data setup
Example: a member account exists and a valid coupon code is configured.

e) Traceability
Link each test case to its rule ID and to the requirement.

f) Prioritization and ordering
Prioritize by risk and business importance. Group tests into test procedures or scripts. Tests can also be data-driven: the table rows become a data file read by one script.

g) Test cases for the minimized example:
• TC1 (Y – Y): member, order $50, valid coupon → free shipping, 10% discount.
• TC2 (Y – N): member, order $150, no coupon → free shipping, no discount.
• TC3 (N Y –): non-member, order $100.00, valid coupon → free shipping, no discount.
• TC4 (N N –): non-member, order $99.99, no coupon → standard shipping, no discount.
Notice that the don't-care conditions were varied across tests. TC3 uses a coupon even though non-members cannot get the discount, which checks the AND logic.

7. Strengths and Limitations
Strengths:
• systematic;
• reveals gaps and contradictions in requirements;
• clear coverage measure;
• easy for business stakeholders to review.

Limitations:
• the number of columns grows exponentially with the number of conditions;
• it does not model sequence or time (use state transition testing for that);
• minimization may hide defects;
• the quality of the tests depends on correctly identifying the conditions.

Very large tables can be split into several smaller, linked tables. Alternatively, risk-based selection or pairwise testing can be considered.

Exam Tips: Answering Questions on Decision Table Coverage and Implementing Test Cases from Rules

Tip 1 – Coverage items are columns, not conditions.
The coverage item is a feasible column. Do not count conditions or actions.

Tip 2 – Check whether the table is full or minimized.
If the question gives a minimized table, the minimum number of tests for 100% coverage equals the number of feasible columns in that table. If it asks about the full table, compute 2^n (or the product of values) and subtract infeasible columns.

Tip 3 – Subtract infeasible combinations.
Look for mutually exclusive conditions, e.g. 'payment by card' and 'payment by cash' if only one method is allowed. Infeasible columns are not coverage items.

Tip 4 – Know how many full columns a collapsed column represents.
A column with k dashes represents 2^k full-table columns (Boolean conditions). Use this to check that a minimized table is complete. The sum over all columns must equal the total number of feasible combinations. If it is less, the table is incomplete. If columns overlap with different actions, it is contradictory.

Tip 5 – Calculate the coverage percentage carefully.
Coverage = exercised feasible columns / total feasible columns. If two tests exercise the same column, it counts once. A test that matches no column, or an infeasible one, adds nothing.

Tip 6 – Map test inputs to columns precisely.
When given test data such as 'age 17, member, order $120', translate each value into Y/N using the exact boundaries in the specification. Is '≥ $100' or '> $100'? Many distractors exploit off-by-one boundary misreadings.

Tip 7 – Expected result questions.
Find the single column that matches all condition values. A '–' matches anything. Then read off all actions, including those that must NOT occur.

Tip 8 – Recognize good implementation practice.
Correct answers usually include:
• concrete values for every condition;
• expected results from the action part;
• varying don't-care values;
• combining with boundary values where useful;
• traceability to the rule.
Be suspicious of options suggesting that don't-care conditions can be left undefined in an executable test.

Tip 9 – Know the trade-off of minimization.
Questions may ask why you would test the full table. The answer is higher risk: the implementation might not respect the 'don't care' assumption. Minimization saves effort but can mask defects.

Tip 10 – Recognize the technique's limits in scenario questions.
If the scenario involves order of events or system states, state transition testing is more suitable. If it involves many independent parameters with little rule logic, combinatorial (pairwise) testing may be better. Decision tables suit combinations of conditions that drive different outcomes.

Tip 11 – Use a systematic method under time pressure.
Quickly sketch the table with the halving pattern (YYYYNNNN / YYNNYYNN / YNYNYNYN). Fill in the actions, then merge pairs. This avoids missing combinations in multi-step K3 questions.

Tip 12 – Eliminate distractors.
Common wrong answers:
• the number of conditions;
• 2^n when the question asks about a minimized table;
• the number of distinct actions;
• a count that includes infeasible columns.

Quick Practice
Q1: A full limited-entry table has 4 conditions. 3 combinations are infeasible. How many tests are needed for 100% coverage?
Answer: 2^4 - 3 = 13.

Q2: A minimized table has 6 feasible columns. The tests exercise columns 1, 2, 2, 4 and 6. What is the coverage?
Answer: 4 distinct columns out of 6 = 66.7%.

Summary
• Decision table testing models combinations of conditions and the resulting actions.
• Its coverage items are the feasible columns. 100% coverage means one test per feasible column of the table in use.
• Minimization reduces tests at the cost of some risk.
• Implementing tests means choosing concrete values (often at boundaries), varying don't-care values, defining expected results from the actions, and keeping traceability to each rule.
• In the exam: count columns correctly, exclude infeasible ones, map inputs precisely to conditions, and read every action.