Page History
Despite no explicit option currently, there are at least 4 3 methods that 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”for.”
| Table of Contents |
|---|
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 are able to 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 then manually correct any prohibited combinations by manually over-writing overwriting any “impossible to test for scenarios” that were generated. If 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.
| Info |
|---|
| Alternatively, if you will are only be using the tests one timeonce, you could simply export your generated tests and then manually overwrite the combinations you do not want to appear (in, say, Excel). |
...
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. In The third question should not appear in any other combination of answers for the first two questions, the third question should not appear at all.
The idea is to represent the combinations of parameters as values.
...
The method is fairly intuitive , but it has scalability limitations: . Listing all pairs of values with two large parameters , listing all pairs of values would be tedious and would negatively negatively impact your flexibility in setting the algorithm strength in Scenarios. And creating an overly-long list of values for your “flattened” parameter could result in significantly increasing 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.
...
To understand this approach, keep in mind remember that Test Case Designer treats information as text without over-analyzing the underlying intention.
...
| Info |
|---|
| 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. |
Method 4: Constraints vs Forced Interactions
The last approach leverages the fact that constraints can overwrite forced interactions, and vice versa.
We start with the “base” initial setup.
Then say that Q2=Yes can never be paired with Q1=No.
Lastly, on the Forced Interactions screen, we force the combination of Q2=Yes with Q1=No and accept the warning that informs us that our constraints logic marks that combination as invalid/impossible.
Doing so will result in the Forced Interaction overwriting the model’s constraints logic. We would get one scenario (and only one) in our data table that would include both Q1 = No and Q2 = Yes. And the correct Question 3 value would appear (“Not displayed”) because we forced it.
We still get the coverage of all pairs and eliminate invalid combinations.
...
| . |