The Checksum Procedure for Decision Tables

5 minutes 5 Questions

In the ISTQB Advanced Level Test Analyst syllabus, decision table testing is a rule-based technique. It models combinations of conditions and the resulting actions, with each column representing a rule. A full decision table lists every combination of condition values. For n Boolean conditions this gives 2^n rules, and in general the total is the product of the number of possible values of each condition. Full tables quickly become large, so Test Analysts often collapse them. Columns that share the same actions are merged, and conditions whose value does not affect the outcome are marked with a dash, meaning do not care or irrelevant. Collapsing makes the table harder to check, because it is easy to lose a combination or to create rules that overlap. The checksum procedure is a simple arithmetic check that confirms a collapsed table is still complete and consistent. First, calculate the expected total, which is the number of combinations in the full table, for example 2^4 = 16 for four Boolean conditions. Second, give each rule in the collapsed table a rule count. A column with no dashes counts as 1. A column with dashes counts as the product of the number of values of each condition marked with a dash, so one Boolean dash gives 2 and two Boolean dashes give 4. Third, add up the rule counts of all columns and compare the sum with the expected total. If the sum is lower, some combinations are missing and the table is incomplete. If the sum is higher, the rules overlap: a single combination is covered by more than one column. Overlapping rules are harmless if their actions are identical, which is simply redundancy. They are a contradiction if the actions differ, and that points to an ambiguous or faulty specification. A matching sum is good evidence of completeness, but the analyst should still check for overlaps that cancel out gaps. Applying the checksum lets Test Analysts validate their models, find specification defects early, and derive a minimal yet complete set of test cases from the collapsed table.

The Checksum Procedure for Decision Tables (ISTQB CTAL-TA: Rule-Based Test Techniques)

Overview
Decision table testing is one of the core rule-based test techniques in the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus. Real decision tables are often minimized (collapsed) to reduce the number of rules and therefore the number of test cases. Minimizing a table merges columns using "don't care" entries, shown as "-" or "N/A".

Merging columns can introduce errors. Combinations can be lost, or two rules can end up covering the same combination. The checksum procedure is a simple arithmetic check that confirms the collapsed table still accounts for every possible combination of conditions exactly once.

Why It Is Important
The checksum matters for five reasons:
1. Completeness: It proves that no combination of conditions has been accidentally dropped while collapsing the table. A missing combination means untested business logic.
2. Consistency (no overlap): It reveals rules that overlap, where one combination is covered by two columns. If those columns specify different actions, the specification is contradictory. That is a defect you can find before any code is run.
3. Static testing value: Applying the checksum during test analysis often exposes gaps and ambiguities in the requirements. This supports early defect detection, a key Test Analyst responsibility.
4. Confidence in coverage: Decision table coverage is measured against the rules (columns). A table that passes the checksum gives a trustworthy basis for that coverage measure.
5. Exam relevance: CTAL-TA questions are K3/K4 (apply/analyze). You may be asked to verify a collapsed table, find a missing or overlapping rule, or calculate how many combinations a rule represents.

What It Is
The checksum procedure compares two numbers.
(a) The total number of possible combinations of condition values. This equals the product of the number of possible values of each condition. For n Boolean (true/false) conditions this is 2^n.
(b) The sum of the combinations represented by each rule in the collapsed table.

Each rule (column) represents a certain number of combinations:
  • A rule with no "don't care" entries represents exactly 1 combination.
  • Each "don't care" entry in a rule multiplies that rule's count by the number of possible values of that condition.
  • For Boolean conditions, each "-" doubles the count. A rule with k dashes represents 2^k combinations.
If (b) equals (a), and no two rules match the same combination, the table is complete and non-redundant.

How It Works: Step by Step
Step 1: List every condition and the number of values it can take. Boolean conditions have 2 values. Multi-valued conditions (for example, Membership = Bronze/Silver/Gold) have as many values as listed.
Step 2: Calculate the total number of combinations as the product of the value counts.
Step 3: For each rule, multiply together the value counts of the conditions marked "don't care". If a rule has no dashes, its count is 1.
Step 4: Add the rule counts together.
Step 5: Compare the result with the total:
  • Sum = total: the checksum passes. The table is very likely complete with no overlaps.
  • Sum < total: one or more combinations are missing.
  • Sum > total: one or more rules overlap, meaning a combination is covered more than once. Check whether the overlapping rules have conflicting actions.

Worked Example 1: Boolean Conditions
A loan approval table has three conditions:
  • C1: Customer has a good credit score
  • C2: Customer has a stable income
  • C3: Customer has collateral
The total is 2 x 2 x 2 = 8 combinations.

Collapsed table:
  • R1: C1 = T, C2 = -, C3 = - (two dashes, so 2 x 2 = 4)
  • R2: C1 = F, C2 = T, C3 = - (one dash, so 2)
  • R3: C1 = F, C2 = F, C3 = T (no dashes, so 1)
  • R4: C1 = F, C2 = F, C3 = F (no dashes, so 1)
Checksum: 4 + 2 + 1 + 1 = 8. This equals the total, so the table is complete.

Worked Example 2: A Defective Table
Suppose R2 was written as C1 = -, C2 = T, C3 = -.
  • R2 now counts 2 x 2 = 4.
  • The new sum is 4 + 4 + 1 + 1 = 10, which is greater than 8.
  • This shows an overlap. The combinations (T, T, T) and (T, T, F) are covered by both R1 and R2.
If R1 and R2 have different actions, the specification is contradictory.

Worked Example 3: Multi-Valued Conditions
A discount table has three conditions:
  • Membership: Bronze, Silver or Gold (3 values)
  • Order over 100: T or F (2 values)
  • Coupon: T or F (2 values)
The total is 3 x 2 x 2 = 12.

Some example rule counts:
  • A rule with Membership = - and Coupon = - represents 3 x 2 = 6 combinations.
  • A rule with only Order = - represents 2.
The rule counts must sum to 12.

Infeasible Combinations
Some combinations are impossible. For example, "age < 18" and "age > 65" cannot both be true. You have two options:
  • Keep such combinations in the table, marked as infeasible, and still include them in the checksum.
  • Remove them, and then compare the sum against the total minus the number of infeasible combinations.
Either way, they must be accounted for explicitly.

Limitation to Remember
A matching sum is a necessary but not always sufficient proof. One missing combination and one overlapping combination can cancel each other out. A careful analyst therefore also checks that no two rules can match the same combination. Two rules cannot overlap if at least one condition has contradicting values in them, for example T in one rule and F in the other.

Exam Tips: Answering Questions on The Checksum Procedure for Decision Tables
  • Start with the total. Always calculate the product of condition values first. For Boolean-only tables it is 2^n: 3 conditions give 8, 4 give 16, 5 give 32.
  • Count dashes per column. For Boolean conditions, a column with k dashes is worth 2^k. Write the value under each column before adding.
  • Watch for multi-valued conditions. A dash on a 3-valued condition multiplies by 3, not 2. This is a common trap in distractor options.
  • Interpret the result correctly. A sum below the total means missing rules. A sum above the total means overlapping or redundant rules. Questions often ask "what does this indicate?"
  • Identify the culprit. For a missing rule, expand each collapsed column mentally and find the combination no column covers. For an overlap, find two columns that do not contradict each other on any condition.
  • Check overlap actions. If overlapping rules lead to different actions, the answer is usually "contradiction or defect in the specification". If they lead to the same actions, it is "redundancy".
  • Separate combinations from test cases. The checksum counts combinations covered. The number of test cases for full decision table coverage equals the number of rules (columns) in the collapsed table, not the total combinations.
  • Account for infeasible combinations. If the question mentions them, adjust the expected total accordingly.
  • Remember the purpose. If asked why the checksum is used, the answer is to verify the completeness and correctness of a collapsed decision table. It is not used to derive the actions or expected results.
  • Manage your time. Write the counts in a small row beneath the table on your scratch paper. This turns a K4 analysis question into simple addition and avoids careless mistakes.

Summary
The checksum procedure follows a simple pattern:
  • Total combinations = product of the condition value counts.
  • Each rule's weight = product of the value counts of its "don't care" conditions.
  • The sum of the rule weights must equal the total.
It is a quick, powerful way to confirm that a minimized decision table is complete and free of overlaps. It frequently reveals specification defects before testing even begins.
Test mode:
Start practice test

CTAL-TA - The Checksum Procedure for Decision Tables Example Questions

Test your knowledge of The Checksum Procedure for Decision Tables

Question 1

A test analyst checks a minimized decision table for a delivery fee service. Its conditions are member (Y, N); order size (small, large); and zone, whose final list of values is still being agreed. The rules are: R1: member=Y, zone=-, size=- -> free delivery; R2: member=N, zone=urban, size=- -> fee A; R3: member=N, zone=rural, size=small -> fee B; R4: member=N, zone=rural, size=large -> fee C; R5: member=N, zone=suburban, size=- -> fee D. The analyst uses the checksum procedure to find the number of zone values for which this table would match its full table. For how many zone values does the checksum equal the number of rules in the full table?

Correct Answer: Three zone values, as the checksum of 12 then equals the 12 rules of the full table

With z zone values, the checksum is 2z for R1 (zone and size both dashes), plus 2 for R2, 1 each for R3 and R4, and 2 for R5, giving 2z+6. The full table has 2×2×z = 4z rules, so the two match only when z is 3, where both equal 12.
Two values gives a checksum of 10 against 8 full rules, so some combinations would be covered twice. Four values gives 14 against 16, so two combinations would be missing. The dash in R1 adds only 2 per extra zone value, while the full table grows by 4, so not every number of values works.
Key concept: decision table checksum validation of a minimized table.

Question 2

A test analyst updates a verified minimized discount table. Membership is Y or N, and payment is card, voucher or cash. The table has these rules: R1: member=Y, payment=- -> 10% discount; R2: member=N, payment=card -> 5% discount; R3: member=N, payment=voucher -> no discount; R4: member=N, payment=cash -> no discount. A new condition is added: express delivery, Y or N. It only matters for non-members paying cash, who are refused when express=Y. The analyst adds express=- to R1, R2 and R3. R4 becomes R4a: member=N, payment=cash, express=N -> no discount. A new rule is added, R4b: member=N, payment=cash, express=Y -> refuse order. Which checksum should the analyst get for the updated table, and what is it compared against?

Correct Answer: Checksum 12, matching the 12 columns of the extended full table

Each rule covers 2 to the power of its don't-care count combinations, extended across the multi-valued payment condition. R1 covers 3 payments times 2 express values, giving 6. R2 and R3 cover 2 each, and R4a and R4b cover 1 each. The total is 12, which equals the full table of 2 x 3 x 2 combinations.
A matching checksum only shows completeness and no overlap. It does not prove the logic matches the requirement. A total of 7 ignores that adding express doubles the coverage of every existing rule. Counting 5 confuses the number of rules with the number of combinations covered.
Key concept: checksum verification of a minimized decision table after adding a condition.

Question 3

A tester checks a colleague's minimized decision table for a delivery charge service before deriving test cases. The conditions are customer type (private, business or public), payment (card or invoice) and express delivery (Y or N). All 12 combinations are feasible. The rules are: R1: type=private, payment=-, express=- -> standard charge; R2: type=business, payment=card, express=- -> card charge; R3: type=business, payment=invoice, express=- -> invoice charge; R4: type=public, payment=card, express=- -> card charge; R5: type=public, payment=invoice, express=- -> invoice charge. The colleague's checksum worksheet scores every rule as 2, totals 10, and reports that two combinations are missing. Which conclusion is correct?

Correct Answer: R1 should score 4, giving a checksum of 12 that matches the full table, so no missing or overlapping combinations are indicated

R1 fixes only customer type, so its two don't-care conditions (payment with 2 values, express with 2 values) cover 2 x 2 = 4 combinations. The other four rules each cover 2, giving 4 + 8 = 12, which equals the full table (3 x 2 x 2), so no gap or overlap is indicated.
The 'proven equivalent' option overstates the check, because a matching checksum cannot rule out offsetting errors or wrong actions. A score of 6 for R1 adds the value counts instead of multiplying them. Keeping R1 at 2 ignores its second don't-care condition.
Key concept: decision table checksums, where each rule covers the product of the value counts of its don't-care conditions.

More The Checksum Procedure for Decision Tables questions
21 questions (total)
Start 21 question test

Other Rule-Based Test Techniques concepts

Combining Metamorphic Testing with Random TestingDecision Table Coverage and Implementing Test Cases from RulesFull Decision Tables and Infeasible RulesMetamorphic RelationsMetamorphic Testing and the Test Oracle ProblemMetamorphic Testing for Non-Functional Testing and AI-Based SystemsMinimizing Decision Tables with Don't-Care ValuesReviewing Decision Tables: Consistency, Completeness and Overlapping RulesSource Test Cases and Follow-Up Test Cases
All Rule-Based Test Techniques questions · CTAL-TA practice test