Cause-Effect Graphing
A visual technique that maps causes (inputs and conditions) to effects (outputs and actions) using logical operators. Cause-effect graphing is the systematic predecessor to decision table testing — it reveals which condition combinations actually matter before you commit them to a table.
1 The Hook
A team building loan-approval logic for a NZ lender writes a decision table straight from memory. The spec has a few conditions — income above a threshold, clean credit history, deposit large enough — so they jot down the combinations that seem to matter and move on. The table looks tidy. It ships.
Months later an auditor finds applicants who were approved when they should have been declined, and others declined when they qualified. The cause: the table missed a combination. The team had reasoned informally — "if income is fine and credit is clean, approve" — and never drew out what happens when income is fine, credit is clean, but the deposit is short and a second condition flips. That interaction path was never on the table because nobody mapped the logic before writing it down.
The mistake was skipping a step. Building a decision table from intuition feels faster, but intuition silently drops combinations — especially the ones where a "false" branch of one condition changes the outcome. Drawing the logic first, as a graph of causes feeding effects, forces every path into the open before a single test case is committed.
2 The Rule
Before building a decision table from a complex specification, map the logic as a cause-effect graph — causes (conditions that can be true or false) on the left, effects (outputs/actions) on the right, joined by AND / OR / NOT operators — so that every effect-producing path, including the negation branches, is made explicit instead of left to intuition.
3 The Analogy
Wiring a house before you flick the switches.
A NZ sparkie does not test power points by guessing which switch does what. They draw the wiring diagram first — this switch AND that breaker feed this circuit; this light works only when the master switch is NOT off. The diagram shows every path electricity can take. Then testing each point is mechanical: follow the lines. Skip the diagram and you find the dead socket only after the gib is up and the wall is painted.
A cause-effect graph is the wiring diagram for a specification. Causes are the switches and breakers, effects are the lights and sockets, and the logical operators are the wires connecting them. Draw it first and the decision table — testing every point — becomes mechanical. Skip it and the missed combination is the dead socket you only discover after release.
What it is
Cause-effect graphing (CEG) was developed in the 1970s as a formal way to model the logical relationships between inputs and outputs in a system specification. Before building a decision table, you draw a graph that makes the logic explicit — causes on the left, effects on the right, connected by logical relationships.
A cause is any condition that can be true or false: a field value, a user permission, a system state, a business rule. An effect is any observable output or action: an error message displayed, a record saved, an email sent, an account locked.
The graph is not the deliverable — the decision table derived from it is. But the graph forces you to think through every logical path before you write a single test case. It prevents the common mistake of building a decision table from intuition and missing interaction paths.
Why senior-level? Cause-effect graphing requires reading a specification carefully enough to extract all causes and effects, then modelling their logical relationships correctly. Getting the operators wrong produces a decision table with gaps or redundant cases. This is a design skill, not a mechanical one.
Logical operators in cause-effect graphs
The graph uses five logical operators to connect causes to effects:
- AND — all connected causes must be true for the effect to occur. Example: valid username AND valid password AND account not locked → login success.
- OR — at least one connected cause must be true. Example: invalid username OR invalid password → show generic error.
- NOT — the effect occurs when the cause is absent (false). Example: NOT account locked → allow login attempt.
- NAND (NOT AND) — the effect occurs when NOT all causes are true simultaneously. Useful for mutual-exclusion rules.
- NOR (NOT OR) — the effect occurs only when all causes are false. Example: no errors detected → proceed to next step.
Causes and effects are numbered (C1, C2… for causes; E1, E2… for effects) so they can be referenced unambiguously in the derived decision table.
How to apply it
- Read the specification — identify every distinct input condition and system state that can be true or false. These become your causes (C1, C2, C3…).
- Identify effects — identify every distinct output or action the system can produce. These become your effects (E1, E2, E3…).
- Draw the graph — place causes on the left, effects on the right. Connect them with the appropriate logical operators. An intermediate node can be used when a combination of causes first produces an intermediate condition, which then triggers an effect.
- Check for constraints — some combinations of causes are impossible (mutually exclusive) or always occur together. Mark these with constraint notations (E = exclusive, I = inclusive, O = one and only one, R = requires).
- Convert to a decision table — enumerate the cause combinations that produce each effect. Each column in the decision table is one row in a test suite.
- Derive test cases — one test case per column in the decision table, covering each distinct combination of causes.
Do not skip the graph step. Teams that jump straight to a decision table often miss effect-producing paths because they are reasoning informally. The graph makes every path visible before you commit to a table structure.
Worked example: user login
The specification reads: “A user can log in if their username is valid, their password is correct, and their account is not locked. If the username or password is invalid, show a generic error. If the account is locked, show a lock message. After three failed attempts, lock the account.”
First, extract causes and effects:
- C1: Username is valid
- C2: Password is correct
- C3: Account is not locked
- C4: This is the third consecutive failed attempt
- E1: Login succeeds (redirect to dashboard)
- E2: Show generic “invalid username or password” error
- E3: Show “account locked” message
- E4: Lock the account
The logical relationships: E1 fires when C1 AND C2 AND C3. E3 fires when NOT C3. E2 fires when (NOT C1 OR NOT C2) AND C3. E4 fires when C4.
| Condition / Effect | TC1 | TC2 | TC3 | TC4 | TC5 | TC6 |
|---|---|---|---|---|---|---|
| C1 Username valid | T | T | T | F | F | F |
| C2 Password correct | T | T | F | T | F | F |
| C3 Account not locked | T | F | T | T | T | F |
| C4 Third failed attempt | F | F | T | T | T | F |
| E1 Login success | ✓ | — | — | — | — | — |
| E2 Generic error shown | — | — | ✓ | ✓ | ✓ | — |
| E3 Lock message shown | — | ✓ | — | — | — | ✓ |
| E4 Account locked | — | — | ✓ | ✓ | ✓ | — |
Six test cases cover all meaningful cause-effect combinations. TC2 is particularly easy to miss without the graph: the account is already locked (C3 is false) even when the credentials are correct (C1 and C2 are true). The graph forces you to consider this path explicitly.
TC6 represents someone trying to log in when the account was locked by a previous session — another easily overlooked case. The graph surfaces it because C3 being false independently of the other causes produces E3 regardless of C1, C2, and C4.
From graph to decision table: the key step
Once the graph is drawn, converting to a decision table is mechanical:
- List every cause as a row in the conditions section.
- Enumerate valid combinations of true/false values. Eliminate impossible combinations (marked by constraint notation on the graph).
- For each valid combination, evaluate which effects fire using the logical operators from the graph.
- Each column = one test case. Collapse columns where the effects are identical and no intermediate distinction matters.
The number of columns in the table is bounded by the number of possible cause combinations minus the constrained/impossible ones. For n boolean causes, you start with 2² combinations and prune down. With four causes, you start at 16 — the login example above pruned to 6 meaningful cases because several combinations produce identical effects.
ISTQB mapping
| Syllabus ref | Topic | Level |
|---|---|---|
| CTFL 4.4 | Cause-effect graphing as precursor to decision table design | Foundation (awareness) |
| CTAL-TA 3.3 | Cause-effect graphing — formal application, logical operators, constraint notation | Advanced / Senior |
| CTAL-TA 3.3 K4 | Analyse a specification to create a cause-effect graph and derive a decision table | Advanced LO |
At Foundation level you need to know that cause-effect graphing exists and that decision tables can be derived from it. At Advanced (CTAL-TA) level you must be able to construct the graph and derive the table from a real specification — this is a K4 (analyse) learning objective.
Common mistakes
- Confusing causes with effects — “account locked” can be both a cause (a system state that prevents login) and an effect (the action of locking after three failures). Be precise: is this something that exists before the action, or something that happens as a result of the action? Number them separately.
- Missing negation paths — every “if X then Y” in a spec implies a “if NOT X” path. Draw it. Teams routinely miss the false branch of a cause because they focus on the happy path.
- Treating the graph as the deliverable — the graph is a thinking tool. The decision table is the test design output. Always complete the conversion.
- Ignoring constraint notation — if two causes are mutually exclusive and you test them as both true, you are testing an impossible scenario. Mark exclusivity constraints on the graph before generating the table.
- Not revisiting the graph when specs change — a change to one condition can ripple through the graph and invalidate several test cases. Treat the graph as a living document alongside the spec.
4 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
For a Studylink student-allowance eligibility rule, state which logical operator (AND, OR, NOT, NAND, NOR) connects the causes to each effect, and explain why.
Show model answer
a) Enrolled full-time AND under income threshold AND NZ resident -> allowance granted = AND. Every connected cause must be true for the effect to fire. b) Income missing OR enrolment unconfirmed -> flag for review = OR. At least one cause being true triggers the effect. c) NOT after the cut-off date -> waive late penalty = NOT. The effect occurs when the cause (being after cut-off) is false/absent. d) No errors AND no warnings -> "all clear, proceed" = NOR. The effect occurs only when both error and warning causes are false — that is NOT (errors OR warnings), the definition of NOR. The trap is (d): it is tempting to call it AND, but the underlying causes are "errors present" and "warnings present", and the effect fires only when both are false, which is NOR.
A tester analysed a "withdraw KiwiSaver for first home" rule and produced the causes and effects below. The analysis has two classic errors: it confuses a cause with an effect, and it misses a negation path. Rewrite the cause/effect list correctly and name the two errors.
C1: Member has been in KiwiSaver 3+ years
C2: It is the member's first home
C3: Withdrawal approved
E1: Withdrawal approved
Rule: if C1 AND C2 then E1
Rewrite correctly:
Show model answer
Correct analysis: Causes: - C1: Member has been in KiwiSaver 3+ years - C2: It is the member's first home Effects: - E1: Withdrawal approved - E2: Withdrawal declined (with reason shown) Logic: - E1 fires when C1 AND C2. - E2 fires when NOT C1 OR NOT C2. Error 1 — cause/effect confusion: "C3: Withdrawal approved" was listed as a cause AND as effect E1. "Withdrawal approved" is an effect (the action the system takes), not a cause (a pre-condition that is true or false before the action). It should appear only as an effect. Error 2 — missing negation path: the original only modelled the approve path (C1 AND C2). Every "if X then approve" implies an "if NOT X then decline" branch. The decline effect (E2) and its condition (NOT C1 OR NOT C2) were missing, so the table would have no test cases for the rejection cases — exactly where eligibility bugs hide.
An online GST-return submission for IRD has this rule: "Submit the return if the IRD number is valid AND the period is open AND there are no unresolved validation errors. If the IRD number is invalid, show an identity error. If the period is closed, show a period-closed message. If validation errors exist, block submission and list them." Extract the causes and effects, state the logic for each effect, and sketch a small decision table.
Show model answer
Causes:
- C1: IRD number is valid
- C2: Filing period is open
- C3: No unresolved validation errors
Effects:
- E1: Return submitted
- E2: Identity error shown
- E3: Period-closed message shown
- E4: Submission blocked and errors listed
Logic:
- E1 fires when C1 AND C2 AND C3.
- E2 fires when NOT C1.
- E3 fires when C1 AND NOT C2.
- E4 fires when C1 AND C2 AND NOT C3.
Small decision table:
TC1 TC2 TC3 TC4
C1 valid T F T T
C2 open T - F T
C3 no errors T - - F
----------------------------------
E1 submitted x
E2 identity x
E3 period closed x
E4 blocked/errors x
A "-" means "don't care": once C1 is false (TC2) the identity error fires regardless of C2 and C3, which is why drawing the graph first matters — it shows that an invalid IRD number short-circuits the other causes. A senior would confirm the impossible/irrelevant combinations are collapsed rather than enumerated as separate test cases.
Self-Check
Click each question to reveal the answer.
Q1: Why draw a cause-effect graph instead of writing the decision table directly?
Because building a table from intuition silently drops combinations — especially paths where a "false" branch of one condition changes the outcome. The graph forces every effect-producing path into the open before any test case is committed, so the table that follows is complete rather than a best guess.
Q2: What is the difference between a cause and an effect, and why does confusing them cause bugs?
A cause is a condition that is true or false before the action (a field value, a permission, a system state). An effect is an observable output or action the system produces. Listing something like "withdrawal approved" as a cause double-counts it and distorts the logic — the same item ends up both triggering and being triggered, which corrupts the derived table.
Q3: What does the NOR operator mean in a cause-effect graph, and give an example?
NOR (NOT OR) means the effect occurs only when all connected causes are false. Example: "proceed to next step" fires only when there are no errors AND no warnings — that is, NOT (errors OR warnings). It is easy to mislabel as AND, so check whether the underlying causes are the negative conditions.
Q4: What is the single most commonly missed path when people skip the graph?
The negation path. Every "if X then Y" in a spec implies an "if NOT X" branch, and teams that reason informally focus on the happy path and drop the false branch of a cause — which is exactly where the rejection and error-handling defects live.
Q5: Why are constraint notations (E, I, O, R) important before generating the decision table?
Some cause combinations are impossible (mutually exclusive) or always occur together. Marking constraints — exclusive, inclusive, one-and-only-one, requires — lets you prune impossible columns so you do not waste test cases on scenarios that can never happen, and avoids testing contradictory states.
Related techniques
Cause-effect graphing leads directly to Decision Table Testing — the graph is the analysis step, the table is the design step. If you are already comfortable with decision tables, you are doing informal cause-effect analysis. Formalising it as a graph is worth the effort when the specification is complex or ambiguous.
The causes in a CEG are equivalence partitions. Combining cause-effect graphing with Equivalence Partitioning ensures each cause is itself a well-defined partition (not an ill-defined or overlapping condition).
When causes are not independent — when knowing one cause changes the probability or meaning of another — consider Domain Analysis to understand the inter-variable relationships before building the graph.
Practice this technique: Try Junior Practice 09 — Checkbox & radio logic.