Learning Objectives
By the end of this lesson you will be able to:
- Convert a cause-effect graph into a decision table
- Apply the transformation algorithm to identify the minimum required test cases
- Evaluate a C-E-derived test suite for completeness
The Transformation Algorithm
The power of cause-effect graphing is that it generates test cases algorithmically — no creativity or guesswork required. The algorithm works backward from effects to causes.
For each effect:
- Force the effect to be true (active)
- Trace back through the graph to find which combination of cause values produces it
- For AND nodes: all inputs must be true
- For OR nodes: test each input being the sole true input (to isolate each path)
- For NOT nodes: the input must be false
This gives you one test case per unique path to each effect.
Then: force the effect to be false (inactive) and find the minimal set of causes that prevents it.
Worked Example
Graph (simplified):
- C1 AND C2 → E1 (Order placed)
- NOT C2 → E2 (Out of stock)
- NOT C3 → E3 (Payment failed)
Test cases for E1 = true:
- C1=Y, C2=Y, C3=Y → E1 active (also: E2 and E3 are inactive)
Test cases for E1 = false:
- C1=N, C2=Y, C3=Y → E1 inactive (C1 is the failure point)
- C1=Y, C2=N, C3=Y → E1 inactive (C2 is the failure point — also triggers E2)
- C1=Y, C2=Y, C3=N → E1 inactive (C3 is the failure point — also triggers E3)
Total: 4 test cases cover all paths through this graph.
Handling Constraints in the Transformation
When your graph has constraint annotations, add test cases specifically for constraint violations:
- For E (exclusive): add a test where both constrained causes are true → must be rejected
- For I (inclusive): add a test where all are false → must be rejected or warned
- For R (requires): add a test where the requiring cause is true but the required one is false → must be blocked
Comparing C-E to Decision Tables
| Decision Table | Cause-Effect Graph | |
|---|---|---|
| Best for | Exhaustive enumeration | Complex directional flows |
| Constraint handling | Implicit (conditions just don't appear) | Explicit (E, I, O, R annotations) |
| Reduces automatically to | Merged rules | One test case per path |
| Starting point | Condition list | Specification narrative |
They are complementary, not competing. A C-E graph often generates the same test cases a decision table would — but the graph is better for specifications written in prose, while tables are better for tabular requirements.
Pro Tip: When you can't decide which technique to use, the answer is usually "both, briefly." Sketch the C-E graph for the big picture, then build a table for the most complex interaction cluster.
Summary
The transformation from C-E graph to test cases is mechanical and complete. Work backward from each effect, isolate each path to that effect, and add constraint violation tests. The result is a minimal test set that covers every logical path through the specification — and catches the implementation mistakes that simpler techniques miss.