CAUSE AND EFFECT GRAPHING

Notes taken from Glenford Myer's The Art of Software Testing.

One weakness of boundary-value analysis and equivalence partitioning is that they do not explore combinations of
input circumstances. For instance, perhaps a program fails if the product of two quantities exceeds some limit (e.g.,
the program runs out of storage). Such an error would not necessarily be detected by boundary-value testing.
The testing of input combinations is not a simple task, because, even if one equivalence-partitions the input
conditions, the number of combinations is usually astronomical. If one has no systematic way of selecting a subset
of input conditions, an arbitrary subset is usually selected, leading to an inefficient test.
Cause-effect graphing is a technique that aids in selecting, in a systematic way, a high-yield set of test cases. It has a
beneficial side effect in pointing out incompleteness and ambiguities in the specification.
A cause-effect graph is a formal language into which a natural-language specification is translated. The graph is
actually a digital-logic circuit (a combinatorial logic network), but rather than using standard electronics notation, a
somewhat simpler notation is used. No knowledge of electronics is necessary other than an understanding of
Boolean logic (i.e., understanding the logic operators and, or, and not).
The following process is used to derive test cases:
1. The specification is divided into "workable" pieces. This is necessary because cause-effect graphing becomes
unwieldy when used on large specifications. For instance, when testing a time-sharing system, a "workable piece"
might be the specification for an individual command. When testing a compiler, one might treat each programminglanguage statement individually.
2. The causes and effects in the specification are identified. A cause is a distinct input condition or an equivalence
class of input conditions. An effect is an output condition or a system transformation (a lingering effect that an input
has on the state of the program or system). For instance, if a transaction to a program causes a master file to be
updated, the alteration to the master file is a system transformation; a confirmation message would be an output
condition. Causes and effects are identified by reading the specification word by word and underlining words or
phrases that describe causes and effects. Each cause and effect is assigned an unique number.
3. The semantic content of the specification is analyzed and transformed into a Boolean graph linking the causes and
effects. This is the cause-effect graph.
4. The graph is annotated with constraints describing combinations of causes and/or effects that are impossible
because of syntactic or environmental constraints.
5. By methodically tracing state conditions in the graph, the graph is converted into a limited-entry decision table.
Each column in the table represents a test case.
6. The columns in the decision table are converted into test cases.