Black box testing with Cause-Effect Graphs

cause-effect-graph-nodesI’ve been reading “The Art of Software Testing – 2nd Edition” by G.J. Myers. The book introduced me to a concept called Cause-Effect Graphs.

This provoked me to research further about it, and to think how I could implement it into my work.

Below is the summary of what I learnt. Unfortunately, I can not share an example of how I implemented it into my work due to concerns of confidentiality. But I’ll share links with other examples for further understanding of this concept.

Cause-Effect Graphing (CEG) is basically a Black-box testing technique that is used to create test cases according to the specifications provided. (—It is a type of Requirements-Based Testing, also known as Dependency modelling)

CEG can not be used in all scenarios. It can only be used in cases where the test output depends on a combination of test inputs.

For eg, you’re showing your users a set of results based on which one of the 2 options – A or B – they chose while requesting data. The type of output (results) here depend only on one test input (that could either be option A or option B). So, CEG is not possible here .

But, if the results depend on a combination of the selected option (A or B), the current date, the user’s nationality, and the user’s language, CEG could be applied because the output depends upon a combination of these inputs.

What CEG does is that it helps capture the relationships between specific combinations of inputs (causes) and outputs (effects).

—The causes and effects are represented as the  nodes of the graph.
I’m listing down a few advantages of CEG below:
  • —Unlike Boundary Value Analysis and Equivalence Partitioning, Cause-Effect Graphing takes into account input combinations
  • —Helps in selecting, in a systematic way, a set of high-yield test cases out of an astronomical set of input combinations.
  • —As a beneficial side-effect, it also points out incompleteness and ambiguities in the specifications.

Notations used – Nodes

Nodes can have either of 2 states:            0 (absent) or 1 (present)


Notations used – Constraints

Constraints define the relationship between a set of inputs

  • —E => c1 & c2 can not be 1 simultaneouslycause-effect-graph-constraints
  • —I => c1, c2, c3 can not be 0 simultaneously
  • —O => One, and only one,

of c1 & c2 must be 1

  • —R => For c1 to be 1, c2

must be 1

Notations used – “Masks” Constraint

If effect e1 is 1, effect e2 is forced to 0 cause-effect-graph-masks-constraint

Now, that I have introduced you to the building blocks of CEG, let’s go through the method:

  1. Divide the specifications into workable pieces. Trying to work with the whole specs all at once would make the process very, very complicated.
  2. Identify cause & effects in the specifications.Cause = A distinct input condition or equivalence class of input conditionsEffect = An output condition or a system transformation
  3. Analyze the semantic content of the specification & transform it into a Boolean graph linking the cause and effects   (Cause-Effect Graph)
  4. Annotate the graph with constraints describing combinations of causes and/or effects that are impossible due to syntactic/environmental constraints
  5. Convert graph into a limited-entry decision table by methodically tracing state conditions in the graph
      1. Select an effect to be the present state (=1)
      2. From the graph, find all combinations of causes (subject to constraints) that will set this effect to 1.
      3. Create a column in the decision table for each combination of causes.
      4. For each combination determine the states of all other effects and place these in each column
    considerations used when tracing cause effect graph
    CEG trace 1
    CEG trace 2
    The final table will look something like this:
    CEG table
  6. Each column in graph represents a test case. So, the last step would be to derive test cases from the table by converting each column to a separate test case.

To keep the number of test cases to a minimal set of high-yield test cases we can assimilate Boundary-value and Equivalence class in the test cases just derived.

I will also list the testing strategy given in the book when i write my next post.

Below are some links with examples of how CEG can be used to create tests. I hope this post was informative for you.

Chapter on CEG from VTU Learning

Good Postal Regulation example


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s