Cause-Effect Graphing

What Is Cause-Effect Graphing? #

Cause-effect graphing is a systematic technique that translates natural language specifications into a Boolean logic graph, which is then converted into a decision table. It bridges the gap between ambiguous requirements and precise test cases.

Why Use Cause-Effect Graphing? #

Decision tables are powerful but have a weakness: with many conditions, you get 2^N rules, most of which may be impossible or redundant. Cause-effect graphing solves this by modeling the logical relationships and constraints between inputs, so you only generate meaningful combinations.

Key Concepts #

• Cause: An input condition or stimulus (left side of the graph)
• Effect: An output or system response (right side of the graph)
• Boolean operators: AND, OR, NOT — connecting causes to effects
• Constraints: Rules that limit which combinations of causes are possible

The Process #

Boolean Operators in Graphs #

Identity: If cause C1 is true, effect E1 is true.

C1 ────── E1

NOT (negation): If cause C1 is true, effect E1 is false.

C1 ──~──── E1

AND: Effect E1 is true only when both C1 AND C2 are true.

C1 ──┐
     ├─ AND ── E1
C2 ──┘

OR: Effect E1 is true when C1 OR C2 (or both) are true.

C1 ──┐
     ├─ OR ── E1
C2 ──┘

Example: Login System #

Specification:

• If username is valid AND password is correct, grant access
• If username is valid AND password is incorrect, show “wrong password”
• If username is invalid, show “user not found”

Causes:

• C1: Username is valid
• C2: Password is correct

Effects:

• E1: Grant access
• E2: Show “wrong password”
• E3: Show “user not found”

Graph:

C1 ──┐
     ├─ AND ── E1 (grant access)
C2 ──┘

C1 ──┐
     ├─ AND ── E2 (wrong password)
~C2 ─┘

~C1 ────────── E3 (user not found)

Constraints Between Causes #

Real-world inputs often have dependencies. Constraints model these:

Example: Payment method selection

• C1: Credit card selected
• C2: PayPal selected
• C3: Bank transfer selected

Constraint: O (One-and-only-one) — exactly one payment method must be selected.

This eliminates combinations where 0 or 2+ methods are selected, drastically reducing the decision table.

Converting to a Decision Table #

For the login example:

Note: When C1 is false (R3), C2 is irrelevant (marked -) because the system shows “user not found” regardless of the password.

Advanced Cause-Effect Graphing #

Complex Example: Order Discount System #

Specification:

• Cause C1: Customer is a VIP member
• Cause C2: Order total > $100
• Cause C3: Coupon code applied
• Constraint: C1 and C3 are mutually exclusive (E) — VIP members cannot use coupons
• Effect E1: 10% discount (VIP)
• Effect E2: 15% discount (VIP + order > $100)
• Effect E3: Coupon discount applied
• Effect E4: No discount

Graph construction:

C1 AND C2 ──── E2 (15% VIP + volume)
C1 AND ~C2 ── E1 (10% VIP only)
~C1 AND C3 ── E3 (coupon discount)
~C1 AND ~C3 ─ E4 (no discount)

Constraint E between C1 and C3

Decision table after applying constraint:

C3 is forced false when C1 is true due to the Exclusive constraint.

Without the constraint, we’d have 2^3 = 8 rules. With it, we have only 4 meaningful combinations.

Handling Large Specifications #

For complex systems with many causes and effects:

1. Decompose. Break the specification into independent subsections, each with its own graph.
2. Chain effects. An effect from one graph can become a cause in another.
3. Number systematically. Use C1-Cn for causes, E1-En for effects, consistent with requirements traceability.

Tool Support #

While cause-effect graphs can be drawn by hand, tools help with large specifications:

• BenderRBT — commercial tool that automates graph-to-table conversion
• Manual approach — draw in any diagramming tool (draw.io, Mermaid), convert to decision table manually

Common Mistakes #

1. Missing negations. Don’t forget to model what happens when a cause is false.
2. Ignoring constraints. Without constraints, you’ll generate impossible test cases.
3. Confusing causes with effects. Causes are inputs you control; effects are outputs you observe.

Exercise: Build a Cause-Effect Graph #

Scenario: A file upload system has these rules:

• C1: File size <= 10MB
• C2: File type is allowed (jpg, png, pdf)
• C3: User is authenticated
• C4: Storage quota not exceeded

Rules:

• If C3 is false → E1: “Please log in” (regardless of other conditions)
• If C3 AND C1 AND C2 AND C4 → E2: “Upload successful”
• If C3 AND NOT C1 → E3: “File too large”
• If C3 AND NOT C2 → E4: “File type not allowed”
• If C3 AND C1 AND C2 AND NOT C4 → E5: “Storage full”

Constraint: R (Requires) — C1, C2, C4 require C3 (only evaluated when authenticated)

Task: Draw the graph, apply constraints, build the decision table, and count the test cases.

Pro Tips #

• Use cause-effect graphing when decision tables get too big. If you have 6+ conditions, a full decision table has 64+ rules. Constraints from cause-effect analysis can cut this dramatically.
• Pair with requirements review. Building the graph often reveals ambiguities, contradictions, and gaps in the specification — making it a valuable review technique too.
• Document the graph. The visual representation is excellent for communicating test logic to developers and product owners.
• Apply error priority order. In real systems, validations often have priority (auth first, then input validation, then business rules). Your graph should reflect this.