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.
The mistake I see most often is not skipping the graph — it is drawing the graph and then ignoring the constraint notation step. Teams identify causes, draw the operators, convert to a table, and ship 16 test columns for four causes. Half of those columns are physically impossible: the spec says a benefit type is either active or pending, never both, but nobody marked the E (exclusive) constraint. The impossible columns crowd out time for the real ones, and testers convince themselves they have comprehensive coverage. Meanwhile the actual bugs are in the valid columns nobody got to. In CoverNZ claims or Studylink eligibility work, I have seen this waste entire test cycles. Mark your exclusivity constraints before you count a single column.
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 Industry Reality
- Requirements arrive as prose, not logic. Real specifications are written by business analysts or product owners who have never heard of cause-effect graphing. Your first job is translating ambiguous language like “the system should handle various login scenarios” into numbered causes and effects — a skill that takes longer than the graph itself.
- Most teams skip the graph entirely and go straight to a table. In practice, cause-effect graphs appear in ISTQB study guides more often than in sprint backlogs. What experienced testers actually do is an informal mental version of the technique: they consciously list the boolean conditions and trace each “if NOT” path before writing test cases. The formal graph notation is most valuable when the logic genuinely has 4+ interacting causes and a business stakeholder needs to sign off on coverage.
- Legacy codebases have undocumented implicit causes. The spec says three causes. The actual system behaves as if there are five — because a feature added two years ago introduced a hidden account-status flag that nobody updated the spec for. Senior testers smoke out these ghost causes through exploratory sessions and code review before committing the graph.
- Time pressure compresses the process. Under sprint pressure, the real-world version of this technique is: spend 15 minutes sketching causes and effects on a whiteboard or sticky notes, identify the negation paths verbally, and then write the decision table. That is still cause-effect graphing — just without formal notation. The discipline matters more than the diagram.
- NZ regulated domains are where this technique earns its keep. Revenue NZ tax logic, Studylink eligibility rules, and CoverNZ claims processing involve multiple interacting boolean conditions with legal consequences for missed paths. In these contexts, a formal graph with constraint notation is defensible evidence that test coverage was systematic — useful if a missed combination surfaces in a complaint or audit.
5 When to Use It — and When Not To
✓ Use it when
- The specification has 3 or more interacting boolean conditions feeding the same output — the combinatorial space is large enough to miss paths informally.
- The domain is regulated or high-stakes: financial eligibility, tax, insurance, healthcare, legal workflows. You need traceable evidence that every logical path was considered.
- A stakeholder or auditor will sign off on test coverage — a graph with constraint notation is far more persuasive than “we tested the main scenarios.”
- The team is building a decision table from scratch and two people are getting different tables from the same spec — the graph resolves disagreements about the logic before anyone writes a test case.
- The spec contains mutual-exclusion rules (“a user cannot be both active and suspended”) that need constraint notation to avoid testing impossible states.
✗ Skip it when
- There are only 1–2 conditions and the logic is simple. Boundary value analysis or a quick mental check is faster and sufficient — the graph adds ceremony without adding insight.
- The system is UI-heavy with few real boolean rules: visual layout testing, usability, accessibility. The technique applies to logic, not appearance.
- You are in early exploratory testing of a poorly understood system. Explore and learn the domain first; build graphs once you know what the causes actually are.
- The spec is not yet stable and changes weekly. Maintaining a cause-effect graph through volatile requirements is expensive — wait for the logic to stabilise before formalising it.
- The team already has a well-maintained decision table that everyone trusts. Retrofitting a CEG to justify an existing table is usually not worth the effort.
Context guide
How the right level of cause-effect graphing effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| Revenue NZ / Revenue NZ — GST, income tax, or Working for Families eligibility logic | Essential | Multiple interacting boolean rules with legislative consequences. Missed paths mean incorrect assessments and potential audit liability. A formal graph with constraint notation is defensible evidence. |
| CoverNZ / Benefits NZ — claim approval or benefit eligibility portals | Essential | Eligibility rules involve 4–6 interacting conditions (residency, income, stand-down, existing entitlement). Regulatory complaints and OIA requests create accountability pressure — systematic coverage evidence is not optional. |
| Harbour Bank / Southern Bank / KiwiFirst Bank — lending, KiwiSaver withdrawal, or payment-approval rules | High use | Banking logic has compound conditions (credit score AND deposit ratio AND existing debt). A formal graph prevents missed short-circuit paths and satisfies RBNZ prudential review requirements for test coverage evidence. |
| TransitNZ / HealthNZ — internal workflow automation (permit approval, patient triage routing) | Medium | Logic is moderately complex; a lightweight whiteboard graph catches the non-obvious paths without requiring full formal notation. Most useful when the workflow is stable and sign-off is needed before go-live. |
| Spark / Pacific Air — customer self-service UI (plan selection, booking modifications) | Low | UI-heavy flows with few hard boolean rules. Exploratory and usability testing surface issues faster. Reserve cause-effect analysis for the back-end pricing or eligibility engine, not the front-end interaction layer. |
| LandNZ — land title transfer or e-dealing validation rules | High use | Title transfer rules combine instrument type, encumbrance status, consent requirements, and lodgement timeframe. A cause-effect graph exposes which conditions must all clear before a transfer can proceed, preventing incorrect rejections or approvals. |
Trade-offs
What you gain and what you give up when you choose cause-effect graphing.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Forces every negation path and short-circuit interaction into the open before a single test case is written — no logical paths survive on intuition alone. | Time-consuming to construct correctly. Extracting causes and effects from prose specifications, drawing the graph, applying constraint notation, and verifying it with a BA can take hours for a complex module. | You have 1–2 conditions only and the interactions are trivially obvious — a quick equivalence partition or mental walkthrough is faster and sufficient. |
| Produces a minimum, non-redundant test set. Constraint notation prunes impossible columns, and collapsing equivalent effects removes duplicate cases — the resulting table is lean rather than bloated. | High maintenance cost when requirements are volatile. A spec change can invalidate several graph arcs at once; if the graph drifts from the spec it provides false confidence rather than real coverage. | The specification is still changing weekly — wait for the logic to stabilise before formalising it. Use exploratory testing to learn the domain first. |
| Generates auditable, traceable coverage evidence. In regulated NZ domains (Revenue NZ, CoverNZ, Benefits NZ), a signed-off cause-effect graph attached to the test plan demonstrates systematic analysis to auditors and regulators. | Requires specialist knowledge to apply correctly. Misidentifying causes as effects, or choosing wrong operators, produces a graph that looks complete but generates a flawed decision table — potentially worse than no graph at all. | The team already has a trusted, well-maintained decision table. Retrofitting a cause-effect graph to justify an existing table rarely adds value and consumes time that could go to testing. |
| Surfaces specification ambiguity early. Drawing the graph with a BA or product owner forces agreement on whether conditions are AND or OR — disagreements that would otherwise surface as bugs after development is complete. | Not suited to non-logical domains. Visual layout, accessibility, performance, and usability issues cannot be modelled as boolean causes and effects — applying the technique here wastes time and produces no useful coverage. | The system behaviour is primarily driven by state transitions (session flow, multi-step wizards) — use state transition testing to model the flow first, then apply cause-effect analysis to the decision logic within individual states. |
Enterprise reality
How cause-effect graphing changes when you are coordinating 200–300 developers across 10+ squads in a NZ enterprise
- At this scale, cause extraction is automated. Tools like Tricentis Tosca and Jira's Xray plug-in ingest requirement text and generate draft cause/effect lists; testers validate and prune rather than start from a blank page. Manual extraction from Word documents is a small-team practice — enterprise QA teams build this step into the CI pipeline so graphs regenerate whenever acceptance criteria change in Jira.
- Revenue NZ's tax and social-policy systems must demonstrate systematic test coverage to the Office of the Auditor-General under the Public Finance Act 1989. At Revenue NZ, a signed-off cause-effect graph attached to each test plan is not optional process overhead — it is the evidence artefact that satisfies the OAG's assurance requirements. Missing it means a qualified audit finding, not just a missed defect.
- With 10+ squads sharing a rule engine (common in Harbour Bank's lending platform or TeleNZ's billing system), each squad owns a subset of causes. A central QA guild maintains the master graph and owns cross-squad constraint notation — ensuring that exclusivity (E) and requires (R) constraints that span squad boundaries are captured once and applied everywhere, rather than each team independently re-deriving them with inconsistent results.
- Enterprise environments run cause-effect graphs inside model-based testing (MBT) frameworks — Conformiq or MBTsuite generate the decision table and test scripts directly from the graph. This eliminates manual table construction at volume: a rule engine with 12 boolean causes produces 4,096 raw combinations; automated pruning via constraint notation reduces this to a tractable test set without human enumeration.
◆ What I would do
Professional judgement — when to reach for cause-effect graphing, when to skip it, and what to watch for.
The bottom line: The value of cause-effect graphing is not the graph — it is the habit of forcing every "if NOT X" path into the open before committing to a test set. Use formal notation when the domain is regulated, the logic is complex, or stakeholder sign-off is required. Use the mental model always.
6 Best Practices
- ✓ Extract causes and effects before drawing anything. Write a numbered list of every distinct boolean condition (causes) and every observable output (effects) and get a colleague or the business analyst to review it. Argument about the list catches scope errors before they corrupt the graph.
- ✓ Keep causes boolean. A cause is either true or false at a given moment. If you find yourself writing “C1: user has a premium, basic, or trial account,” split it: one cause per state or use equivalence partitioning to define the partition first.
- ✓ Number causes and effects from the start. C1, C2, C3… E1, E2, E3… consistently. Cross-referencing between graph and decision table by number is far less error-prone than using natural-language labels in a large table.
- ✓ Draw the negation path for every “if X then Y.” For each positive effect path, explicitly draw what happens when the leading cause is false. This single habit catches the majority of missed rejection and error-handling paths.
- ✓ Use intermediate nodes for complex chains. When C1 AND C2 produce an intermediate state (e.g., “credentials valid”) that then combines with C3 to produce E1, add the intermediate node. It makes the graph readable and ensures the decision table captures the two-stage logic correctly.
- ✓ Mark constraint notation before generating the table. Identify impossible combinations (E — exclusive), combinations that must co-occur (R — requires), and combinations where at least one must be true (I — inclusive). Remove or flag constrained columns before counting test cases.
- ✓ Collapse equivalent columns in the decision table. If two cause combinations produce identical effects and there is no intermediate distinction, merge them into one test case with “don’t care” entries. The goal is minimum test cases for complete logical coverage, not exhaustive enumeration.
- ✓ Version the graph alongside the specification. When requirements change, update the graph first and highlight which effects are affected. This makes the impact of a spec change visible before anyone touches existing test cases.
- ✓ Cross-check against exploratory findings. After deriving your test cases from the graph, do a quick exploratory session. Defects found through exploration that were not predicted by the graph indicate a cause or constraint you missed — update the graph to include them.
- ✓ In NZ regulated contexts, save the graph as a test-design artefact. For Revenue NZ, CoverNZ, Benefits NZ, or banking integrations, attach the signed-off cause-effect graph to your test plan or defect record. It is evidence that your test design was systematic rather than ad-hoc.
7 Common Misconceptions
❌ Myth: “Cause-effect graphing is just a fancy name for a decision table.”
Reality: A decision table is the output of cause-effect graphing, not the same thing. The graph is an analysis step that models the logical operators (AND, OR, NOT, NAND, NOR) connecting causes to effects. Without the graph, teams build decision tables from intuition and routinely miss negation paths — especially when one “false” branch of a cause short-circuits the remaining conditions. The graph makes those paths visible first; the table mechanically captures them second.
❌ Myth: “You only need to draw the happy path — the error cases are obvious.”
Reality: Error paths are almost never obvious, and “obvious” is exactly how bugs survive until production. A login spec with four causes generates up to 16 combinations; teams that reason informally typically cover 4–5. The negation paths — what happens when C1 is false while C2 and C3 are true — are precisely the combinations that get skipped. Cause-effect graphing exists specifically to force these paths into the open. In NZ financial and government systems, missed rejection logic has resulted in real regulatory penalties.
❌ Myth: “This technique is too formal and slow for Agile sprints.”
Reality: The discipline, not the diagram, is what matters. A 15-minute whiteboard session listing C1, C2, C3 and tracing each NOT-path is cause-effect analysis. The formal graph notation with constraint markers is appropriate when the logic is complex, the domain is regulated, or coverage needs to be signed off. Senior testers adapt the formality to the risk level — they do not skip the thinking because the sprint is short; they do the thinking faster and document it proportionally.
Senior engineer insight
The moment that changed how I think about this technique was realising the graph is not about documentation — it is about forcing disagreement early. When you draw the graph with a BA or product owner in the room, every operator becomes a negotiation: "Is this AND or OR?" That question surfaces ambiguity in the spec before a single test case exists. I have had stakeholders rewrite acceptance criteria on the spot because a graph made a gap in their own logic visible for the first time.
A secondary shift: once I started drawing intermediate nodes — a "credentials valid" node fed by C1 AND C2, which then combines with C3 — my decision tables became dramatically smaller because the intermediate logic collapsed redundant columns naturally.
Most common mistake: teams draw the graph for the happy path only and call it done. Every positive arc in the graph has a negation arc. If you have not drawn the NOT-branch for every cause, you have not finished the graph — you have just produced a flowchart of what works, not a map of what can fail.
From the field
We were testing a Work and Income NZ online eligibility checker — six interacting boolean conditions covering residency, age, income band, partner income, existing benefit status, and a recent stand-down period. The product team had a decision table. It had eight columns. I drew the cause-effect graph on a whiteboard in 20 minutes and we counted 14 valid combinations after applying the exclusivity constraint on benefit status. Six columns were missing. When we tested them, three produced incorrect eligibility outcomes: two false approvals and one wrongful decline.
The lesson that generalises: any time a government or financial eligibility rule is written as prose by a policy team and handed to developers, there will be implicit constraint assumptions that never made it into the spec. The cause-effect graph is what makes those implicit assumptions legible — and testable — before the system goes live and real applicants are affected.
8 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 Revenue NZ has this rule: "Submit the return if the Revenue NZ number is valid AND the period is open AND there are no unresolved validation errors. If the Revenue NZ 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: Revenue NZ 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 Revenue NZ number short-circuits the other causes. A senior would confirm the impossible/irrelevant combinations are collapsed rather than enumerated as separate test cases.
Why teams fail here
- They draw the graph for approval paths only and skip the negation arcs — leaving every rejection, error, and edge case path untested and undetected until production.
- They skip constraint notation and test impossible cause combinations (e.g. a user simultaneously active and suspended), wasting cycles on scenarios the system can never reach while missing the ones it can.
- They list an effect (an action the system produces) as a cause (a pre-condition that exists before the action), which corrupts the logical model and produces a decision table with circular or nonsensical columns.
- They treat the graph as a one-time artefact and never update it when requirements change — so the decision table and test cases drift out of sync with the spec and provide false assurance of coverage.
Key takeaway
Cause-effect graphing is not a diagramming exercise — it is the discipline of forcing every logical path, especially the negation paths, into the open before a single test case is written, so that the decision table you derive is complete by construction rather than optimistic by intuition.
How this has changed
The field moved. Here is how Cause-Effect Graphing evolved from its origins to current practice.
Cause-effect graphing published by Myers in "The Art of Software Testing" (1979) as a systematic method for deriving test cases from complex logical conditions. Intended to complement decision tables with a graphical representation of cause-and-effect relationships.
ISTQB adopts cause-effect graphing into the test design curriculum. Used primarily in safety-critical domains where complex logical interdependencies must be systematically documented and tested. Rarely applied in mainstream commercial software development.
Model-based testing tools begin automating test case generation from state machines and logical models — making manual cause-effect graphs less necessary. Decision tables, which are easier to construct and maintain, largely replace cause-effect graphing in practice.
Cause-effect graphing survives primarily in academic test design syllabi and specialist safety domains. In mainstream agile delivery, the technique is rarely taught or used — combinatorial testing tools generate equivalent coverage automatically.
AI tools can analyse requirements for causal relationships and propose test cases — an automated form of what cause-effect graphing was designed to achieve manually. The technique remains conceptually important for understanding test design principles even if the manual method is rarely applied directly.
Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Cause-Effect Graphing — and what strong answers look like.
Explain what cause-effect graphing is and how it differs from a decision table.
Strong answer: Cause-effect graphing models the logical relationships between inputs (causes) and outputs (effects) as a graph with AND, OR, and NOT nodes. From the graph, you derive a decision table — but the graph reveals the logical structure first, making it easier to identify impossible combinations and redundant test cases before constructing the table. A decision table alone lists rules without showing why those combinations were chosen. Cause-effect graphing is most useful when input conditions interact in complex ways; for simple orthogonal conditions, going straight to a decision table is faster.
Mid/Senior
When would you choose cause-effect graphing over pairwise testing for combinatorial test design?
Strong answer: When the relationships between conditions are strongly interdependent — where certain combinations are impossible or always produce the same result regardless of other conditions. Pairwise testing assumes all parameter combinations are independent and valid; cause-effect graphing explicitly models constraints and dependencies. For a form where choosing "bank transfer" as a payment method disables credit card fields, cause-effect graphing produces a smaller, more targeted test set by capturing that constraint. Pairwise testing would generate invalid combinations that do not correspond to real user scenarios.
Senior/Lead
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.
Q6: Your team is testing an Benefits NZ benefit-eligibility portal that has four interacting boolean conditions: NZ residency, age threshold met, income below cap, and no existing benefit of the same type. A colleague suggests skipping the graph and writing the decision table directly because “four conditions is not that many.” What is your response, and what specific risk does skipping the graph introduce here?
A: Four boolean causes generate up to 16 combinations. Without the graph, teams instinctively list the obvious approval path and two or three rejection paths, missing interactions where one false cause short-circuits the others. The specific risk here is the "no existing benefit" condition: if a person is already receiving a related benefit, that alone should block approval regardless of residency, age, or income — a short-circuit that is easy to drop when reasoning informally. In an Benefits NZ context, that missed combination means either incorrectly approving a double-payment or wrongly declining an eligible applicant, both of which carry regulatory and reputational consequences. The graph surfaces the short-circuit path explicitly before the table is written.
Q7: What is the key difference between cause-effect graphing and decision table testing, and in what order should they be used?
A: Cause-effect graphing is the analysis step that models the logical operators (AND, OR, NOT, NAND, NOR) connecting conditions to outputs — it reveals which combinations are possible and how they interact. Decision table testing is the design step that captures those combinations as columns of true/false values paired with expected effects. They are not alternatives; the graph comes first. Skipping straight to a decision table means building it from intuition rather than from explicit logical modelling, which is exactly how negation paths and short-circuit interactions get dropped. Think of the graph as the architect's structural drawing and the decision table as the inspection checklist derived from it.
Q8: A developer reviewing your test plan says, “Cause-effect graphing is overkill — we already have unit tests for each condition individually, so every combination is covered.” What is wrong with this reasoning and how do you respond?
A: Unit tests that exercise each condition in isolation do not cover interactions between conditions. A login feature tested with "valid username" and "valid password" as separate unit tests still does not cover what happens when username is valid, password is correct, but the account was locked by a concurrent session — a combination that only emerges when the conditions interact. Cause-effect graphing exists precisely to map those interaction paths. In NZ-regulated systems like a RealMe identity verification flow or a KiwiSaver withdrawal rule, the defects that matter are almost always in the interaction paths, not in the individual conditions. Unit coverage and combination coverage are complementary, not substitutes.
Q9: An interviewer asks: “When would you choose NOT to use cause-effect graphing?” What are the two strongest signals that the technique is not worth the effort, and what would you use instead?
A: The two strongest signals are: (1) fewer than three conditions with no interacting logic — when a spec has one or two boolean conditions, the combinations fit on a napkin and boundary value analysis or a quick mental check is faster and sufficient; and (2) a specification that is changing frequently — maintaining a formal graph through volatile requirements costs more than it saves, and the graph quickly drifts out of sync with the spec. In both cases, experienced testers do informal cause-effect thinking (mentally tracing NOT-paths) without formal notation, reserving the full graph for complex, stable, or regulated scenarios such as CoverNZ claims rules or Revenue NZ filing logic where traceable coverage evidence is needed for audit sign-off.
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.