Cause Effect Graphing
Cause Effect Graphing
Cause Effect Graphing
By Gary E. Mogyorodi
Introduction
This article addresses the second RBT technique - Cause-Effect Graphing. The first
article, in the December 2002 issue of the JSTP, described Ambiguity Reviews and
included a sample ambiguity review of a set of requirements for which I will design test
cases in this article.
The test case design challenge is to derive the necessary and sufficient set of test cases to
cover 100% of the functionality for the system under test. Without 100% functional
coverage, there is a virtual certainty that functionality will go into production untested.
There are many test case design techniques, but few ensure that the test cases will provide
100% functional coverage. The Cause-Effect Graphing technique begins with the set of
requirements, and determines the minimum number of test cases to completely cover
those requirements.
1
Functional requirement - A functional requirement specifies what the system must be
able to do, in terms that are meaningful to its users.
Page 1
Test Case Review
Once the test cases have been derived by the test case designer, the RBT process includes
the review of these test cases by the following stakeholders:
• The author of the requirements verifies that he/she agrees with the test case designer’s
translation of requirements to test cases.The domain experts review the test cases in
order to determine the answer to the following question: “Are we building the right
system”?The developers review the test cases to clarify their understanding of the
requirements. The developers learn what they will be tested on, and can therefore
develop the software to succeed.
By performing these reviews, everyone on the project team can obtain the same
understanding of what will be built.
Traditional Test Case Design Techniques
There are a number of test case design techniques, including Equivalence Class
Partitioning and Boundary Value Analysis. These techniques rely on the test case
designer to manually work out the proper combinations of test cases. Often, the test case
designer does not use a formal test case design technique and relies on his/her “gut feel”
to assess whether test coverage is sufficient.
While these techniques do generate combinations of test cases, they often fall short on
providing full functional coverage. Too often the normal flow or “go path” functionality
has overlapping, redundant test cases, while exceptions and error conditions go untested.
Cause-Effect Graphing
The Cause-Effect Graphing technique was invented by Bill Elmendorf of IBM in 1973.
Instead of the test case designer trying to manually determine the right set of test cases,
he/she models the problem using a cause-effect graph, and the software that supports the
technique, CaliberRBT™, calculates the right set of test cases to cover 100% of the
functionality. The cause-effect graphing technique uses the same algorithms that are
used in hardware logic circuit testing. Strict test case design in hardware ensures
virtually defect free hardware.
Cause-Effect Graphing also has the ability to detect defects that cancel each other out,
and the ability to detect defects hidden by other things going right. These are advanced
topics that won’t be discussed in this article.
Page 2
The starting point for the Cause-Effect Graph is the requirements document. The
requirements describe “what” the system is intended to do. The requirements can
describe real time systems, events, data driven systems, state transition diagrams, object-
oriented systems, graphical user interface standards, etc. Any type of logic can be
modeled using a Cause-Effect diagram. Each cause (or input) in the requirements is
expressed in the cause-effect graph as a condition, which is either true or false. Each
effect (or output) is expressed as a condition, which is either true or false.
The cause-effect graph that represents this requirement is provided in Figure 1. The
cause-effect graph shows the relationship between the causes and effects.
In Figure 1, A, B and C are called nodes. Nodes A and B are the causes, while Node C is
an effect. Each node can have a true or false condition. The lines, called vectors,
connect the cause nodes A and B to the effect node C.
All requirements are translated into nodes and relationships on the cause-effect graph.
There are only four possible relationships among nodes, and they are indicated by the
following symbols:
Page 3
The Decision Table
The cause-effect graph is then converted into a decision table or “truth table”
representing the logical relationships between the causes and effects. Each column of the
decision table is a test case. Each test case corresponds to a unique possible combination
of inputs that are either in a true state, a false state, or a masked state (the masked state
will be described in Figure 4 below).
Since there are 2 inputs to this example, there are 22 = 4 combinations of inputs from
which test cases can be selected.
Figure 2 represents the decision table derived for the cause-effect graph in Figure 1.
Notice that there are only three test cases. However, these three test cases cover 100% of
the functionality for this example. The fourth combination of inputs (A= true and B =
true) does not add any additional functional coverage, and is a redundant test case. Each
relation is tested with the right combinations of causes so that all defects are covered for
that relation, resulting in 100% coverage.
Page 4
For more technical information about Cause-Effect Graphing, refer to the following:
Richard Bender
Bender & Associates
17 Cardinale Lane
Queensbury, NY 12804
518 743-8755
G. J. Myers,
The Art of Software Testing,
Wiley, 1979.
Page 5
Let’s Create a Cause-Effect Graph
The following postal regulation determines postage surcharges. This regulation applies
only to parcels, not other types of postal items, and only to parcels sent to South America.
Other postal items are envelopes and post cards. There is no postage surcharge for
envelopes and post cards. For parcels which people mail to South America between
December 1 and December 24 of each year, the system will apply the surcharges in Table
1 in addition to the standard postage of $5.00 US:
For parcels which people mail to South America outside of December 1 to December 24
of each year, the system will apply the surcharges in Table 2 in addition to the standard
postage of $5.00 US:
Table 2 - Country & Weight Surcharge outside the dates December 1 to December 24
(In a real life problem, the specific details of Table 2 would be supplied here. For this
example, they have been excluded.)
Page 6
The test case designer translates the requirements into the cause-effect graph shown in
Figure 4 (created using CaliberRBT™).
The node I10 represents the state in which the item is sent to South America AND the
postal item is a parcel AND the item is mailed between December 1 and December 24.
There are a number of mask statements in the cause-effect graph. The mask statements
define constraints on the system under test. As an example, the mask (Argentina,
Weight_High, 33_Pounds, Weight_Low) means that when Argentina is the country, then
the weight divisions associated with Brazil are irrelevant inputs.
Page 7
The Cause-Effect Graph is translated into the following decision table (output from
CaliberRBT™):
Each column in Figure 5 represents a test case. The inputs are listed under the Causes,
while the outputs are listed under the Effects. Each value in the matrix can be either T =
true, F = false, or M = masked (an input that is masked is irrelevant to that test case).
Each column represents a unique combination of inputs.
Page 8
The following 8 test cases are derived for the Postal Regulation requirements using the
Cause-Effect Graphing technique:
Cause(s):
The item is NOT sent to South America.
Effect(s):
These conditions are out of scope for the Postal Regulation problem.
Cause(s):
The item is sent to South America.
The postal item is NOT a parcel.
Effect(s):
These conditions are out of scope for the Postal Regulation problem.
Cause(s):
The item is sent to South America.
The postal item is a parcel.
The item is NOT mailed between December 1 and December 24.
Effect(s):
See Table 2 for postage surcharges.
Cause(s):
The item is sent to South America.
The postal item is a parcel.
The item is mailed between December 1 and December 24.
The country is Argentina.
Effect(s):
The postage surcharge is $11.
Page 9
TEST#5 -- The Postal Regulation
Cause(s):
The item is sent to South America.
The postal item is a parcel.
The item is mailed between December 1 and December 24.
The country is NOT Argentina.
The country is NOT Brazil.
Effect(s):
The postage surcharge is $15 US.
Cause(s):
The item is sent to South America.
The postal item is a parcel.
The item is mailed between December 1 and December 24.
The country is Brazil.
The item weighs more than 33 pounds.
Effect(s):
The postage surcharge is $21 US.
Cause(s):
The item is sent to South America.
The postal item is a parcel.
The item is mailed between December 1 and December 24.
The country is Brazil.
The item weighs 33 pounds.
Effect(s):
The postage surcharge is $19 US.
Page 10
TEST#8 -- The Postal Regulation
Cause(s):
The item is sent to South America.
The postal item is a parcel.
The item is mailed between December 1 and December 24.
The country is Brazil.
The item weighs less than 33 pounds.
Effect(s):
The postage surcharge is $17 US.
In Summary
Figure 5 shows there are 8 inputs to the Postal Regulation requirements (i.e., Continent,
Postal_Item_Type, Dates, Argentina, Brazil, Weight_High, 33_Pounds, Weight_Low). It
is interesting to note that with 8 inputs, there are 28 = 256 combinations of inputs from
which test cases can be selected. The Cause-Effect Graphing technique derived only 8
test cases, but these 8 test cases cover 100% of the functionality described in the
requirements. No other test cases are required to improve functional coverage.
Additional test cases would only provide redundant coverage already supplied by some
portion of each of the 8 original test cases.
Page 11