Cause-Effect Graphing Overview
"When looking into varying solutions, we found that Datamaker was also very useful for getting the right kind of data for testing and development. This was incredibly important for us and one of the main factors in our tool selection. Yes, we needed data for testing and development, but we also needed many data scenarios. Using all of the data from production would have simply been inefficient for us. We only needed a small amount of data, but rich spread of data."
Jochen Westheide,
The ARAG Group
Datamaker Data Design™ - because there's no substitute for good test data.
Grid-Tools Graphic Front-End
The graphic front end allows project teams to quickly create cause-effect graphs, complete with node relationships, constraints, and attributes. When a node is created, users are prompted to enter the required attributes, reducing the risk of incompletely defined nodes. When the cause-effect graph is completed, RBT then designs the test cases based on the requirements depicted in the graph. RBT also uses the cause-effect graph to further evaluate the requirements for logical consistency. The project team can use the test cases generated by RBT to review requirements with stakeholders, or they can use the structured English requirements document automatically generated by RBT. The more readable the requirements are, the more likely the project team is to develop the right application.
The tool gives you a number of options in generating test cases.
Test generation options
The "Run New" option will design a new set of tests based on the graph you have just entered.
The "Run Old" option will evaluate the coverage of a set of existing tests against the current version of the graph.
The "Run Both" option will evaluate the coverage of a set of existing tests and then supplement these tests to complete the coverage of the graph.
The "Revise Desc[riptions]" option allows you to modify the True or False definition of a node without having to rerun the graph. It just updates the data base with the new description. This is immediately reflected on all of the generated reports (e.g. Batch Test Cases). This is very convenient in cases where you have a long running graph and find that you want to tune the wording on a description. For example, you may have misspelled something or you want to bring the wording to be more in sync with other sets of tests.
Note: This feature can be used to factor in test cases that were not designed by RBT. There is a dialog for allowing the user to tell RBT about existing test cases, regardless of their source.
To design test cases RBT first generates the list of Functional Variations. These are the primitive combinations of data that must be tested.
Functional variation report
Errors in the requirements logical consistency will show up in this report.
The Variations are then packaged into highly readable test scripts. The scripts can then be reviewed by the subject matter experts to aid in validating that the requirements are correct. In effect, this moves customer acceptance testing up before coding starts.
The Script Test Definitions Report details every step of the test cases designed, including the input conditions and the expected results (or effects) of each step.
The highly optimized test design algorithms ensure that you get the maximum coverage for the minimum number of tests.
The tool also generates a number of other views of the test information. The first is the Test Definition Matrix. This is a compact view of the test cases. It can be exported as a comma delimited file and imported into Excel or into "home grown" test tools".
The tool's Definition Matrix uses a table format to display the state of each node in each test case, allowing at-a-glance understanding of each test case.
Another view is the Functional Variation Matrix. This matrix identifies which variations are in which test cases.
The Functional Coverage Matrix identifies which functional variations are in which test cases. An "X" means that the variation is in two or more tests. A "#" means the variation is only in one test.
The Functional Coverage Utility uses the Functional Coverage Matrix to calculate the status of testing. This allows the team and Management to make intelligent decisions on whether or not to release the application into production based on quantitative test status.
The Coverage Analysis Matrix allows the project team to quantifiably determine the status of testing. When one or more test cases are selected, the Coverage Analysis function calculates the selected test cases' percentage of weak and strong functional coverage.
Fewer Tests Dialog
This feature allows you to enter in a number less than or equal to the number of total tests and have RBT determine which is the optimal subset of tests - i.e. which tests would give you the greatest possible coverage.
Back to the top