Quick Test Case Design 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.
Quick Design - Orthogonal Pairs / Optimized Pairs Based Test Design Engine
Nullam fermentum, lorem nec venenatis vestibulum, nisl turpis pulvinar tortor, vitae volutpat lacus magna in nisl. Proin vehicula mollis elementum. Morbi aliquet nulla ut leo consequat pulvinar.
Defining a Variable in Quick Design
For each Variable you define the States you want to test.
Defining a State in Quick Design
QD concatenates the Variable description with the State description in the generated test scripts. This saves typing and ensures consistent wording of test scripts. In the above example the final description would read "The customer is a Corporate customer".
If needed, you then apply constraints across the Variables/States which identify combinations of data which are physically impossible at this point in the system. However, you still want to do full negative testing.
Defining a Constraint in Quick Design
In this example the constraint rule is that only corporate customers may have building loans. Other functions prior to this one would have rejected any attempt by retail customers or government customers from getting this type of loan. The production data base would not contain any building loans for any customer other than corporate customers. Therefore, we do not want to generate any tests at this point contrary to this rule. Note, however, that in testing the predecessor functions you should have tried creating a building loan for the other customer types. The test result should have been that the loan application was rejected.
Quick Design then generates all possible pairs across the Variables/States. This is documented in the Pairs Report.
Quick Design Pairs Report
Note that two of the pairs have a yellow "I" next to them. These are the infeasible pairs - i.e. they violated the constraint we set up.
Quick Design then merges the pairs into tests, again ensuring that no constraints are violated. You have two choices in generating tests: Orthogonal Pairs or Optimized Pairs. In Orthogonal Pairs testing each pair occurs the same number of times across the set of test cases. In Optimized Pairs each pair is in at least one test. The goal is to do this in the fewest number of tests possible. We generally recommend orthogonal pairs for configuration testing and optimized pairs for function testing.
Quick Design Test Scripts Report
In designing test cases, Quick Design gives you the same options as in the graphing component to create new tests, evaluate old tests, supplement existing tests, and revise test descriptions. Again, the existing tests need not have been created by RBT.
As in RBT, you get the coverage report.
Quick Design Pair Coverage Report Optimized Tests
As in the Cause-Effect Graphing component there is a feature to measure test coverage and identify an optimal subset of tests.
You also get the Test Definition Matrix.
