Great work!

XP to next level

BugEater

Mapping Triggers to Outcomes

Learning Objectives

By the end of this lesson you will be able to:

  • Distinguish between causes (inputs) and effects (outputs) in a specification
  • Draw a basic cause-effect graph using AND, OR, and NOT connectors
  • Explain the difference between cause-effect graphing and decision tables

Why Another Technique?

Decision tables work beautifully when you can enumerate all condition combinations. But some specifications describe logic more naturally as a flow: "this triggers that, which in combination with that other thing causes this outcome." The logic flows directionally, like a circuit.

Cause-effect graphing (CEG) is the technique that models this directional logic explicitly — making it easy to see which combinations of causes lead to which effects, and which combinations are impossible.

The Building Blocks

Causes (C) — input conditions that can be true or false:

  • C1: User is logged in
  • C2: Item is in stock
  • C3: Payment is verified

Effects (E) — observable outcomes:

  • E1: Order is placed
  • E2: "Out of stock" message shown
  • E3: "Payment failed" alert shown

Intermediate nodes — internal logic states that combine causes before producing effects.

The Connectors

Between nodes, you draw logical connectors:

  • (identity): If C1 is true, the connected node is true
  • (AND): Connected to the node only if ALL inputs are true
  • (OR): Connected to the node if AT LEAST ONE input is true
  • ¬ (NOT): Inverts the input — true becomes false, false becomes true

Building Your First Graph

Specification: "An order can only be placed if the user is logged in AND the item is in stock AND the payment is verified. If the item is not in stock, show an out-of-stock message."

C1 (logged in) ─┐
                 ├─[AND]─→ E1 (order placed)
C2 (in stock) ──┤
                │
C3 (payment) ───┘

C2 ──[NOT]──→ E2 (out-of-stock message)

This graph immediately shows:

  • E1 requires all three causes
  • E2 is triggered by the absence of C2
  • C2 participates in both paths (interesting — worth a dedicated test case)

Reading a C-E Graph for Test Cases

Each leaf node (cause) can be true or false. The graph tells you which combinations produce which effects. You need at least:

  • One test case that triggers each effect
  • One test case that doesn't trigger each effect
  • Test cases that exercise each connector

Pro Tip: When a cause appears in multiple paths (like C2 above), it's a high-value test focus. Changing its value affects multiple outcomes simultaneously — exactly where developers make mistakes.

Summary

Cause-effect graphing translates a specification's conditional logic into a visual circuit. Causes are inputs, effects are outputs, and connectors describe how they combine. The graph reveals which causes are load-bearing — the ones where a mistake will ripple through multiple outcomes. In the next lesson, you'll add constraint annotations that handle the most complex real-world rules.

Quiz

In cause-effect graphing, a "cause" is best described as:

What does an "effect" represent in a cause-effect graph?

Which relationship means "both conditions must be true for the effect to occur"?

What is the primary value of building a cause-effect graph before writing test cases?