A cause-effect graph is a test design technique that organizes complex condition logic into a diagram, then converts it into test cases. By visualizing multi-condition and complex AND/OR/NOT logic that can’t be managed in a decision table alone, it enables thorough, gap-free test design.
This article explains how to build a cause-effect graph (Cause-Effect Graph) with a step-by-step approach and concrete examples.
👉 How it differs from decision tables: The key difference is whether you organize conditions directly into a table, or visualize them in a diagram first — and that difference becomes significant with complex logic.
💡 In one sentence
Cause-effect graph = A technique that turns “if this happens, then that happens” into a diagram — then mechanically derives test cases from it
📌 Summary (30 seconds)
A cause-effect graph is a technique for organizing the relationship between causes (conditions) and effects (behaviors) in a diagram, then converting that diagram into a decision table to generate test cases.
- ✔ You have 6 or more conditions
- ✔ AND / OR / NOT logic is complex and intertwined
- ✔ Your decision table has grown unmanageable
→ This is the test design technique for exactly those situations.
📊 Cause-Effect Graph Example (Login Process)
👉 Left = causes (input conditions), Right = effects (behaviors). Top = happy path, Bottom = error path — a typical pattern.
👉 Each combination of conditions determines which effect (success or failure) fires.
| C1 (ID correct) | ──┐ | AND ∧ | ──→ | E1 Login success | ← Happy path |
| C2 (Password correct) | ──┘ | ||||
| ¬C1 (ID wrong) | ──┐ | OR ∨ | ──→ | E2 Error shown | ← Error path |
| ¬C2 (Password wrong) | ──┘ | ||||
C = Cause E = Effect ¬ = NOT ∧ = AND ∨ = OR → = transition
With a cause-effect graph, complex condition combinations are mechanically converted into test cases through a “diagram → decision table” pipeline — producing high-quality test design with no gaps and no duplicates.
📌 Who This Article Is For
- QA engineers and developers learning cause-effect graphs for the first time
- Anyone whose decision table has too many conditions to organize effectively
- Those who want to systematize test design for complex business logic
- Those studying for ISTQB and want to understand cause-effect graphs
✅ What You’ll Learn
- The concept behind cause-effect graphs, the logic symbols, and how to build one
- How to derive a decision table from a completed graph
- The decision criteria for choosing between cause-effect graphs and decision tables
👤 About the Author
Written by Yoshi, a QA and test automation engineer with 15+ years of hands-on experience. Cause-effect graphs are actively used for verifying complex business logic in production. Code is publicly available on GitHub: github.com/YOSHITSUGU728/automated-testing-portfolio
“6+ conditions and the decision table is getting out of hand.” “There’s complex OR/AND/NOT logic between conditions and I can’t fit it in a table.” — have you hit these walls?
- Decision table columns grow exponentially as conditions increase
- Mixed AND/OR/NOT logic can’t be fully expressed in table form
- It becomes impossible to trace which combination of conditions maps to which result
Cause-effect graphs solve these problems. By visualizing the causal relationships in a diagram first, then converting to a decision table, even complex logic can be organized systematically.
📌 Key Points of Cause-Effect Graph Testing
- A test design technique that expresses “cause (input condition) → logical operation (AND/OR/NOT) → effect (expected behavior)” as a graph
- Converting the graph into a decision table mechanically derives exhaustive test cases
- Used as a precursor to decision tables when handling 6+ conditions with complex logic
- What Is a Cause-Effect Graph?
- What Are the Core Elements of a Cause-Effect Graph?
- How to Build a Cause-Effect Graph: 4 Steps
- Example: Cause-Effect Graph and Decision Table Conversion (Membership Discount System)
- Cause-Effect Graph vs Decision Table: How to Choose
- ⚠️ 4 Common Pitfalls in Cause-Effect Graph Testing
- FAQ
- 📋 Summary
What Is a Cause-Effect Graph?
A cause-effect graph is a test design technique that expresses the logical relationship between input conditions (causes) and expected behaviors (effects) in graph form, then derives a decision table from that graph.
The technique was developed by IBM in the 1970s and is defined as a test design technique in ISTQB. Where a decision table organizes condition combinations directly in a table, a cause-effect graph takes a two-step approach: first organize the causal relationships visually, then convert them into a decision table.
| Aspect | Decision Table | Cause-Effect Graph |
|---|---|---|
| Approach | Conditions organized directly into a table | 2-step: graph → table |
| Condition count | ~2–5 conditions | Handles 6+ conditions |
| Logic representation | Implicit (conditions listed as rows) | Explicit (AND/OR/NOT shown in diagram) |
| Visual overview | Gets hard to read with many columns | Full picture clear in the diagram |
| Learning curve | Low (intuitive) | Moderate (symbols need to be learned) |
What Are the Core Elements of a Cause-Effect Graph?
A cause-effect graph consists of nodes and links. Learning the logic operation symbols is the first step to building one.
Node Types
| Node Type | Symbol | Meaning | Example |
|---|---|---|---|
| Cause | C1–Cn | Input conditions / prerequisites | Username is correct / Age is 18+ |
| Effect | E1–En | Expected behaviors / outputs | Login success / Error message shown |
| Intermediate node | I1–In | Intermediate state grouping multiple causes via logic | “Both username AND password are correct” |
Logic Operation Symbols
📊 Cause-Effect Graph Logic Symbols
| Symbol | Name | Meaning | Example |
|---|---|---|---|
| → | Identity | If cause is true, effect is true | C1 is true → E1 is true |
| ∧ | AND | Effect is true only if ALL causes are true | C1 AND C2 true → E1 true |
| ∨ | OR | Effect is true if ANY cause is true | C1 OR C2 true → E1 true |
| ¬ | NOT | Effect is true only if cause is false | C1 is false → E1 true |
※ Combine these symbols to express complex condition relationships
Constraint Symbols
Constraint symbols indicate combinations that should never occur between causes or effects.
| Symbol | Name | Meaning |
|---|---|---|
| E | Exclusive | Cannot both be true simultaneously (at most one is true) |
| I | Inclusive | At least one must always be true |
| O | One and only one | Exactly one must always be true |
| R | Requires | When C1 is true, C2 must also be true |
| M | Mask | When E1 is true, E2 must be false |
How to Build a Cause-Effect Graph: 4 Steps
| Step | What to Do |
|---|---|
| STEP 1 | Extract “causes (input conditions)” and “effects (expected behaviors)” from the specification |
| STEP 2 | Connect causes and effects with AND/OR/NOT logic operators to draw the graph |
| STEP 3 | Add constraint symbols (E/I/O/R/M) between causes and between effects |
| STEP 4 | Read the graph in reverse to identify all valid patterns, then convert to a decision table |
Example: Cause-Effect Graph and Decision Table Conversion (Membership Discount System)
Here’s how to apply cause-effect graph design to an e-commerce discount logic — a concrete cause-effect graph example with decision table conversion.
Spec (Extract Causes and Effects)
| Type | ID | Description |
|---|---|---|
| Cause | C1 | User is a premium member |
| Cause | C2 | User has a coupon |
| Cause | C3 | Purchase total is $50 or more |
| Effect | E1 | Premium discount (10% off) applied |
| Effect | E2 | Coupon discount (5% off) applied |
| Effect | E3 | Bulk discount (3% off) applied |
Logic Relationships (Graph Content)
| Rule | Logic Expression |
|---|---|
| Premium member → premium discount applied | C1 → E1 (identity) |
| Has coupon AND not premium → coupon discount applied | C2 AND ¬C1 → E2 |
| $50+ AND not premium AND no coupon → bulk discount | C3 AND ¬C1 AND ¬C2 → E3 |
Converting the Graph to a Decision Table
Once the graph is built, read it in reverse for each effect to identify what combination of causes fires it, then populate the decision table.
| Condition / Effect | C1 | C2 | C3 | C4 | C5 | C6 |
|---|---|---|---|---|---|---|
| Premium member (C1) | Y | Y | N | N | N | N |
| Has coupon (C2) | Y | N | Y | Y | N | N |
| $50+ purchase (C3) | – | – | Y | N | Y | N |
| → E1: Premium discount | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| → E2: Coupon discount | ❌ | ❌ | ✅ | ✅ | ❌ | ❌ |
| → E3: Bulk discount | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
The conversion makes the structure explicit: “E1 fires whenever C1 is true, regardless of coupon status” / “E2 fires when C1=N and C2=Y” / “E3 only fires when neither C1 nor C2 is true and the total is $50+.”
Cause-Effect Graph vs Decision Table: How to Choose
Cause-effect graphs and decision tables are closely related, so knowing when to use which is important. In short, the difference between a cause-effect graph and a decision table is: whether you organize conditions directly into a table, or use a diagram to clarify them first.
| Criterion | → Decision Table | → Cause-Effect Graph |
|---|---|---|
| Condition count | 2–5 conditions | 6 or more |
| Logic complexity | Simple Yes/No conditions | AND/OR/NOT mixed and complex |
| Constraints between conditions | Few or no constraints | Many exclusive / inclusive constraints |
| Team communication | A table is enough to convey it | A diagram communicates better |
💡 Decision Flow
- 2–5 conditions → design directly with a decision table
- 6+ conditions or complex AND/OR/NOT → draw a cause-effect graph first, then convert to a decision table
- Both techniques ultimately produce a decision table as the final deliverable
💡 Real-World Example: When Decision Tables Break Down
Attempting to design permission management logic (admin / standard / guest × 5 permission types × 3 states) directly as a decision table produced 50+ columns — completely unmanageable.
After organizing the logic with a cause-effect graph, unnecessary conditions and missing exclusive constraints became clear, and the final table was reduced to around 20 cases. “Untangle the chaos in a graph, then drop it into a table” — this process alone takes test design quality up a full level.
When It’s a Good Fit / When It’s Not
✅ Good fit
| ✖ Not a good fit
|
Tools for Drawing Cause-Effect Graphs
| Tool | Features | Cost |
|---|---|---|
| draw.io | Browser-based, VS Code plugin available, easy diagram export | Free |
| Lucidchart | Team sharing, real-time collaboration, Confluence integration | Paid (free tier available) |
| Miro | Whiteboard style, great for collaborative brainstorming | Paid (free tier available) |
| Microsoft Visio | Enterprise standard, rich shape library and templates | Paid |
⚠️ 4 Common Pitfalls in Cause-Effect Graph Testing
Here are the mistakes that are easy to make when applying cause-effect graphs in practice.
① Using a cause-effect graph when the conditions are simple
With 2–4 conditions, going straight to a decision table is simpler and faster. A cause-effect graph is a tool for visualizing complex logical relationships — applying it to simple cases just adds unnecessary overhead. Match the technique to the complexity of the logic.
② Forgetting constraint symbols — impossible cases slip into the decision table
If you forget to add an Exclusive constraint (E) between causes that can’t both be true — like “payment: credit card” and “payment: cash on delivery” — the decision table ends up with impossible test cases baked in. After converting to a table, always verify: “can this combination actually occur?”
③ Stopping at the graph and skipping the decision table conversion
The cause-effect graph is an intermediate artifact — its purpose is to produce a decision table. Being satisfied with the graph and not completing the conversion to test cases defeats the point entirely. Always follow through: graph → decision table → test cases.
④ Not using intermediate nodes — the graph becomes a tangled mess
Without intermediate nodes (I) to group multiple causes, the lines from causes to effects become a spaghetti diagram. Group “C1 AND C2” into intermediate node I1, then draw a single line from I1 to the effect — this cleans up the graph considerably.
FAQ
Q. When should I use a cause-effect graph?
Use it when you have 6+ conditions, complex AND/OR/NOT logic, or many constraints between conditions. For simple logic with few conditions, a decision table is better. The signal to reach for a cause-effect graph is: “I tried building a decision table and it got out of control.”
Q. Which is better — cause-effect graph or decision table?
Neither is superior — they’re complementary. Decision tables are simpler and more intuitive for fewer conditions. Cause-effect graphs are better for visualizing complex logic with many conditions. In production, the typical approach is “organize with a cause-effect graph, then convert to a decision table.”
Q. How is cause-effect graph testing covered in ISTQB?
ISTQB Foundation Level covers “the concept, purpose, and relationship to decision tables.” Understanding that “a cause-effect graph is a technique for deriving decision tables, expressing the logical relationships between causes (inputs) and effects (outputs) in graph form” is sufficient for the exam. The Advanced Level requires more depth.
Q. Are there tools specifically for cause-effect graphs?
Dedicated tools include CTE (Classification Tree Editor) and Agora Test Manager. General diagramming tools like draw.io (free), Microsoft Visio, and Lucidchart all work well too. The most cost-effective workflow in production is: build the graph in draw.io, then manually convert to a decision table.
📖 Related Articles
In production, the workflow I use for complex business logic with 6+ conditions — permission systems, discount rules, approval flows — is to build the cause-effect graph in draw.io, review it with the team, then convert to a decision table. The graph becomes a shared language: dev, QA, and business stakeholders can all look at the same diagram and review the logic together. That shared understanding is the biggest practical advantage.
📋 Summary
- Cause-effect graph is a test design technique that expresses “cause → logic operation (AND/OR/NOT) → effect” relationships as a diagram
- Converting the graph to a decision table mechanically derives exhaustive test cases
- Use it as a precursor to decision tables when you have 6+ conditions and complex AND/OR/NOT logic
- Constraint symbols (E/I/O/R/M) explicitly mark impossible combinations, letting you eliminate invalid test cases upfront
- Always follow through to the decision table conversion — the graph is the means, not the end
A cause-effect graph’s two-step approach — organize complexity visually, then convert to test cases — enables systematic test design for logic that would break a decision table on its own. Drawing one simple graph with 3–4 conditions is the fastest way to make it click. Once you’ve built that mental model, the path to more complex business logic opens up naturally. Building just one graph is the shortcut to genuine understanding.
