Despite no explicit option currently, at least 3 methods could help you successfully handle N-way relationships.

For example, you might want to prevent a specific 3-way combination from appearing in your generated tests because it would be “impossible to test for.”


Method 1: Manually fixing individual tests after test generation (either with “Freezing” or post-export)

Starting with the most obvious approach, you can (1) model constraints as well as you can do so with the constraint handling capabilities available today, (2) generate your optimized scenarios (which would erroneously include a few 3-way / n-way combinations you would like to prevent), then (3) you would manually fix the wrong combinations after they appear.

You could use TCD’s Freeze Feature to turn your generated set of scenarios into forced combinations of inputs. With your tests in the “frozen” state, you could manually correct any prohibited combinations by manually overwriting any “impossible to test for scenarios” generated. Suppose you expect to be modifying this set of tests multiple times. In that case, this option is recommended (because the “fixes” you make on the Frozen Tests (Forced Interactions) screen will remain in place for all future test sets you generate from this model.

Alternatively, if you are only using the tests once, you could export your generated tests and then manually overwrite the combinations you do not want to appear (in, say, Excel).

Method 2: Nested values

To demonstrate other methods, we will use a simple example where the behavior of the third parameter depends on the value combination from the first two. Specifically, if the answers to Question 1 and Question 2 are both “Yes”, then Question 3 should allow users to give a Yes or No answer. The third question should not appear in any other combination of answers for the first two questions.


The idea is to represent the combinations of parameters as values.


This allows you to “flatten” the hierarchy down to 2 levels and use the Constraints as you normally do (because constraints between 2 values can be easily handled).

The method is fairly intuitive but has scalability limitations. Listing all pairs of values with two large parameters would be tedious and negatively impact your flexibility in setting the algorithm strength in Scenarios. And creating an overly-long list of values for your “flattened” parameter could significantly increase the number of tests generated. One mitigation strategy could be Value Expansions for pairs that behave similarly from the perspective of the N-way relationship.


Method 3: Fake Values

To understand this approach, remember that Test Case Designer treats information as text without over-analyzing the underlying intention.


That means, as long as the string is different, it can have separate constraints despite representing the exact same variation idea.


In Q2, “Yes” is reserved for Q1 = “Yes” and “Yes*” is reserved for Q1 = “No”.


For automation (where the literal value is more important), the value expansion can be added to “Yes*” to replace the value name on export since TCD Automate only reads value expansions if they exist.



  • No labels