What is cause-effect graphing and when is it more useful than a decision table?

Cause-effect graphing (introduced by Myers in "The Art of Software Testing") models the system as a Boolean graph: causes (input conditions) on the left, effects (output conditions) on the right, connected by logical operators (AND, OR, NOT) plus constraints (mutual exclusion, requirement, mask).

When it beats a decision table:

• Many inputs that aren't independent. A decision table with 10 inputs has 1024 rows; many will be impossible because of constraints ("can't be Premium and Free simultaneously"). Cause-effect graphing models those constraints explicitly and only enumerates the reachable combinations.
• Complex logical relationships. "A or B, but not both, requires C unless D" is awkward in a decision table and natural in a graph.
• Reusable across similar features. The graph is closer to a model than a flat table; graphs of related features can share substructure.

When a decision table beats it:

• Few inputs, simple combinations. A 4-input boolean rule set is clearer as a 16-row table than a graph.
• Stakeholders need to read it. A decision table reads like a spec; a cause-effect graph reads like a logic diagram.

Worked example: a loan-approval system with causes creditScore ≥ 700, incomeVerified, debtRatio < 0.4, hasBankruptcy. Effects: approved, requiresReview, rejected. Constraints: hasBankruptcy masks all positive effects; approval requires all three positives. From the graph you derive minimum test cases that cover every cause's effect on every effect: typically far fewer than the 2^4 = 16 rows of a decision table because constraints prune impossible combinations.

Tooling: most teams don't use formal cause-effect graphing tools (they're niche); the technique is more often a thinking aid. Decision tables and pairwise testing have eaten its market share. But understanding it shows depth of test design vocabulary.