I’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 simultaneously
- I => c1, c2, c3 can not be 0 simultaneously
of c1 & c2 must be 1
must be 1
Notations used – “Masks” Constraint
If effect e1 is 1, effect e2 is forced to 0
Now, that I have introduced you to the building blocks of CEG, let’s go through the method:
- Divide the specifications into workable pieces. Trying to work with the whole specs all at once would make the process very, very complicated.
- Identify cause & effects in the specifications.Cause = A distinct input condition or equivalence class of input conditionsEffect = An output condition or a system transformation
- Analyze the semantic content of the specification & transform it into a Boolean graph linking the cause and effects (Cause-Effect Graph)
- Annotate the graph with constraints describing combinations of causes and/or effects that are impossible due to syntactic/environmental constraints
- Convert graph into a limited-entry decision table by methodically tracing state conditions in the graph
Select an effect to be the present state (=1)
From the graph, find all combinations of causes (subject to constraints) that will set this effect to 1.
Create a column in the decision table for each combination of causes.
For each combination determine the states of all other effects and place these in each column
The final table will look something like this:
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