Designing test cases using Cause-Effect Graphing Technique

Designing test cases using Cause-Effect Graphing Technique

Can you explain how you can design test cases using the Cause-Effect Graphing Technique?

    Requires Free Membership to View

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

The Cause-Effect Testing Technique is another of several efforts for mapping input to output/response. In the Cause-Effect Graphing Technique, input and output are modeled as simple text, such as this:

Cause --> intermediate mode --> effect

See the Wikipedia article "Cause-effect graph" for additional information.

Much more information about the Cause-Effect Graphing Technique can be found in the "Cause-Effect Graphing User Guide", which is an entire PDF for the use of Bender RBT testing tool. (Note that this manual was written in 2006, so it might be somewhat out of date.)

The goal of cause-effect graphing is to reduce the number of test cases run. Many input/modifiers/effect combinations have the same output and exercise the same code in the system under test. By reducing the combinations, fewer tests can be run while still achieving the same confidence in quality.

Software test case design resources:
How to design test cases

Granularity in test case design

How to design test cases from use cases

A somewhat related modeling concept is PICT -- Pairwise Interdependent Combinatorial Testing. This technique goes a step beyond cause-effect and actually applies combinatorial theory to reduce the number of combinations needed to be tested.

Each theory has its application. In a highly related system where cause and intermediate effect are tightly coupled, it might be a challenge to model the system in PICT (although some PICT tools, including Microsoft's free PICT modeling tool, do allow you to weight various factors as well as create combinations).

My concern about cause-effect is simple: How could you model cause-effect on a high-availability Web service with 30 methods, each containing 40 or 50 parameters? By manually identifying each cause and effect, you'll spend so much time detailing the test that I'm not convinced you could actually test the application. This is why tools like Bender RBT exist -- to help automate this process.

My biggest complaint about a methodology like cause-effect is its lack of real-world application. I doubt your manager would tolerate your spending five or six days modeling your application into a cause-effect graph. Your manager is more likely to expect you to apply good testing sense and develop cases quickly, but keeping an eye on critical combinations. Still, further research is warranted, and if you can efficiently apply this model to your efforts, you'll be rewarded with higher quality at a reduced input cost.

This was first published in December 2008