Learning Objectives
By the end of this lesson you will be able to:
- Identify rules that can be merged using "don't care" (–) notation
- Apply rule merging without losing test coverage
- Recognize the limit of reduction and when to stop
The Redundancy Problem
In the loan example from the previous lesson, we had 8 rules — 7 of which resulted in rejection. Must you write 7 separate rejection test cases? No. Many of those rules are logically equivalent: the system takes the same path (reject) for the same reason (bad age, bad income, or bad credit). Writing all seven teaches you nothing new about the system.
The technique for reducing this is rule merging, using a "don't care" (–) notation.
The "Don't Care" Condition
When two rules differ only in the value of one condition, and both produce the same actions, you can merge them into one rule where that condition is marked – (don't care).
Before merging:
| R5 | R6 | R7 | R8 | |
|---|---|---|---|---|
| C1: Age valid | N | N | N | N |
| C2: Income OK | Y | Y | N | N |
| C3: No default | Y | N | Y | N |
| Reject | X | X | X | X |
Since age is invalid (N) in all four, and rejection happens regardless of income and credit, we can merge:
| R5-8 (merged) | |
|---|---|
| C1: Age valid | N |
| C2: Income OK | – |
| C3: No default | – |
| Reject | X |
One test case covers all four combinations.
When Merging Is Safe
Merging is safe when:
- The conditions being collapsed to "–" genuinely don't affect the outcome
- The specification confirms the behavior (not just your assumption)
- You are not losing coverage of a condition's effects in other rules
The Merged Final Table
Applying rule merging to our loan example:
| R1 (Approve) | R2 (Default) | R3 (No Income) | R4 (Both bad) | R5+ (Age invalid) | |
|---|---|---|---|---|---|
| C1: Age valid | Y | Y | Y | Y | N |
| C2: Income OK | Y | Y | N | N | – |
| C3: No default | Y | N | Y | N | – |
| Approve | X | ||||
| Reject | X | X | X | X |
Five test cases instead of eight. All coverage retained.
The Limit of Reduction
Do not over-reduce. If reducing a table obscures which condition is actually causing the rejection, keep the rules separate. The goal is clarity and efficiency, not minimalism at any cost.
Pro Tip: Always keep at least one test case per unique action. If "Approve" and "Reject" are two different actions, you must have at least one test case triggering each.
Summary
Rule merging reduces test case volume without losing coverage. The key tool is "don't care" notation: when a condition's value does not affect the outcome, collapse the two rules into one. This lesson completes the decision table toolkit — you now know how to build and optimize a table for any multi-condition system.