Dynamic Testing Techniques – Cause and Effect Graph.
Test case writing forms an integral part of testing, whether it is Manual or Automation. Every project is exclusive and has a <n> number of test conditions that need to be covered.
We should focus on two points whenever we write test cases. These are:
- Mitigating the Risk
This paper revolves around the second point which is “Coverage”. To be precise – Requirements Coverage.
What You Will Learn:
Test Case Writing Techniques For Dynamic Testing
- Equivalence Partitioning
- Boundary Value Analysis
- Decision table
- Cause and Effect graph technique
- State Transition diagram
- Orthogonal Array Testing(OATS)
- Error Guessing.
We have some really good papers 1st, 2nd and 3rd points (Equivalence Partitioning, BVA and Decision tables) here in STH. I am going to discuss point 4 which is the Cause and Effect graph.
Introduction To Cause And Effect Graph
The Cause and Effect Graph is a dynamic test case writing technique. Here causes are the input conditions and effects are the results of those input conditions.
Cause-Effect Graph is a technique that starts with a set of requirements and determines the minimum possible test cases for maximum test coverage which reduces test execution time and cost. The goal is to reduce the total number of test cases, still achieving the desired application quality by covering the necessary test cases for maximum coverage.
But at the same time obviously, there are some downsides to using this test case writing technique. It takes time to model all your requirements into this Cause-Effect Graph before writing test cases.
The Cause-Effect Graph technique restates the requirements specification in terms of the logical relationship between the input and output conditions. Since it is logical, it is obvious to use Boolean operators like AND, OR and NOT.
Now let’s try to implement this technique with some examples:
- Draw a Cause and Effect graph based on a requirement/situation.
- Cause and Effect Graph is given, draw a Decision table based on it to draw the test case.
Let’s see both of them one by one.
Draw A Cause And Effect Graph According To Situation
The “Print message” is software that reads two characters and, depending on their values, messages is printed.
- The first character must be an “A” or a “B”.
- The second character must be a digit.
- If the first character is an “A” or “B” and the second character is a digit, then the file must be updated.
- If the first character is incorrect (not an “A” or “B”), the message X must be printed.
- If the second character is incorrect (not a digit), the message Y must be printed.
The Causes of this situation are:
C1 – First character is A
C2 – First character is B
C3 – the Second character is a digit
The Effects (results) for this situation are:
E1 – Update the file
E2 – Print message “X”
E3 – Print message “Y”
First, draw the Causes and Effects as shown below:
Key – Always go from Effect to Cause (left to right). That means, to get effect “E”, what causes should be true.
In this example, let’s start with Effect E1.
Effect E1 is for updating the file. The file is updated when
– The first character is “A” and the second character is a digit
– The first character is “B” and the second character is a digit
– The first character can either be “A” or “B” and cannot be both.
Now let’s put these 3 points in symbolic form:
For E1 to be true – the following are the causes:
– C1 and C3 should be true
– C2 and C3 should be true
– C1 and C2 cannot be true together. This means C1 and C2 are mutually exclusive.
Now let’s draw this:
So as per the above diagram, for E1 to be true the condition is (C1 C2) C3
The circle in the middle is just an interpretation of the middle point to make the graph less messy.
There is a third condition where C1 and C2 are mutually exclusive. So the final graph for effect E1 to be true is shown below:
Let’s move to Effect E2:
E2 states print message “X”. Message X will be printed when the First character is neither A nor B.
This means Effect E2 will hold true when either C1 OR C2 is invalid. So the graph for Effect E2 is shown as (In blue line)
For Effect E3.
E3 states print message “Y”. Message Y will be printed when the Second character is incorrect.
This means Effect E3 will hold true when C3 is invalid. So the graph for Effect E3 is shown as (In Green line)
This completes the Cause and Effect graph for the above situation.
Now let’s move to draw the Decision table based on the above graph.
Writing Decision Table Based On Cause And Effect graph
First, write down the Causes and Effects in a single column shown below
The Key is the same. Go from bottom to top which means traverse from Effect to Cause.
Start with Effect E1. For E1 to be true, the condition is (C1 C2) C3.
Here we are representing True as 1 and False as 0
First, put Effect E1 as True in the next column as
Now for E1 to be “1” (true), we have the below two conditions –
C1 AND C3 will be true
C2 AND C3 will be true
For E2 to be True, either C1 or C2 has to be False shown as,
For E3 to be true, C3 should be false.
So it is completed. Let’s complete the graph by adding 0 in the blank column and include the test case identifier.
Writing Test Cases From The Decision Table
Below is a sample test case for Test Case 1 (TC1) and Test Case 2 (TC2).
In a similar fashion, you can create other test cases.
(A test case contains many other attributes like preconditions, test data, severity, priority, build, version, release, environment, etc. I assume all these attributes to be included when you write the test cases in the actual situation)
Summarizing the steps once again:
- Draw the circles for Causes and Effect Graphs
- Start from Effects and move towards the Cause.
- Look for mutually exclusive causes.
This finishes the Cause and Effect graph dynamic test case writing technique. We have seen how to draw the graph and how to draw the decision table based on it. The final step of writing test cases based on the decision table is comparatively easy.
About the Author: This is a guest article by Shilpa Chatterjee Roy. She is working in the Software Testing field for the past 8.5 years in various domains.
Feel free to discuss your test case writing methods in the comments below.