Page History
Table of Contents | ||
---|---|---|
|
Overview
Invalid constraintsĀ restrict parameter values that canĀ neverĀ be tested together.
In specific scenarios, system allows user to define what parameter values can never be tested together or in the other hand, scenarios where parameter values can only be tested together.Ā
For that, user can apply constraints to support these cases.
So that the model can understand the requirements, you have the option to define invalid constraints (values that can never be tested together), and/or bound constraints (values that can only be tested together) to train the model.
Invalid constraints
Invalid constraintsĀ restrict parameter values that canĀ neverĀ be tested together.
In this example, let's assume Internet Explorer (IE) is not supported on Apple computers so it would be impossible for a tester to execute a test case that instructed them to launch IE from a Mac running on its native operating system. Accordingly, we do not want any tests generated to include combinations such as āOS Xā and āIE8ā in the same test case.
On the Rules ->Constraints screen, you will need to click on two red Xās. Hover over the first Value of the Invalid Pair and click on the red X that appears
Find the second Value that can never appear together with the first one, hover over it, and click on the red X to create your āInvalid Pairā
As you enter your Constraints, you will see them listed to the left:
After you enter these two Invalid Pairs, clicking on the āScenariosā button will create a completely new set of test cases that excludes those two pairs of Values (and only those two pairs of Values). Each test with āOS Xā as the operating system will have a browser other than IE.
As you use the Invalid Pair feature and the related Bound Pair one, keep in mind these usage tips:
Tip |
---|
Do you need to addĀ a lotĀ of Invalid Constraints?
Watch out for āNot Applicableā Values.
|
Bound constraints
Bound constraintsĀ restrict parameter values that canĀ onlyĀ be tested together.
Consider these parameters & values:
You will have the following issue when you click on the āScenariosā button:
Even though the test calls for not adding the hotel, the data row proceeds to specify the preference and type of room, which is clearly incorrect.
To solve this, you first need to add āNot Applicableā as parameter values
This is because something will need to appear in test cases that include the value āDo Not Add a Hotelā.
We will want āNot Applicableā to appear for both āHotel Chain Preferenceā and āType of Roomā in every scenario that includes the value āDo Not Add a Hotelā.
Info |
---|
The exact syntax of the conditional value and its position in the list don't matter, it could have been "N/A" as the last value. |
Next, youāll want to make sure that āDo Not Add a Hotelā only gets paired with the āNot Applicableā Values.Ā You have two options under the āConstraintsā tab. One is quick, the other is slow. Letās see the slow option, first:
Namely, itās adding a lot of āInvalid Constraintsā as described in the previous article in this section.
How to use Bound Constraints
UI Steps | ||||||
---|---|---|---|---|---|---|
| ||||||
|
When you add a Bound Pair, Xray Test Case Designer will constrain the first value chosen against all the other values in the parameter of the second value chosen. In the example above, creating a bound constraint of āDo Not Add Hotelā and āHotel Chain Preferenceā = āNot Applicableā means you are really invalidating these options:
- āDo Not Add a Hotelā with āHotel Chain Preference = Marriottā (this combination will never appear).
- āDo Not Add a Hotelā with āHotel Chain Preference = Hiltonā (this combination will never appear).
- āDo Not Add a Hotelā with āHotel Chain Preference = Motel Oneā (this combination will never appear).
- āDo Not Add a Hotelā with āHotel Chain Preference = Vivanta by Tajā (this combination will never appear).
And because we created a MUTUALLY BOUND constraint, we are also invalidating these combinations:
- āDo Add a Hotelā with āHotel Chain Preference = Not Applicableā (this combination will never appear).
As you use the Bound Constraint feature, keep the following tips in mind:
- You can use the Invalid Constraint Feature to accomplish anything that the Bound Constraint feature can do.
- The Invalid Constraint feature is frequently less confusing for new users . Donāt hesitate to use the Invalid feature instead of the Bound Constraint feature.
- If you have more than 10 or so Bound Constraints or Invalid Constraints in a plan, you might find that it is easier and faster to document your paired values in Excel. If so, we would recommend (a) adding multiple paired values before you export into Excel, and (b) ensuring that you use the exact spelling of Values (e.g., ācutting and pastingā is usually safer than typing)
- Especially watch out for situations where you have MULTIPLE related āNot Applicableā values in a plan. Would it make sense to create a āBound Constraintā between, say, āHotel Chain Preference = Not Applicableā and āType of Roomā = Not Applicableā? In the example above, it WOULD make sense to include that Bound Constraint. Every time āHotel Chain Preferenceā = āNot Applicableā we would want āType of Roomā to also be āNot Applicableā also. Similarly, every time āType of Roomā = Not Applicable, we would want āHotel Chain Preferenceā to also be āNot Applicableā. This is an example of a type of constraint that the human brain would handle effortlessly without even consciously applying logical rules.
āBound Constraintsā are rules for your model algorithm to ensure that two values must appear together. Knowing which type to use depends on your plan structure and business & technology requirements.
We will be using this set of values to demonstrate:
As a reminder, to apply a bound constraint, you need to hover over value 1, click the green arrow icon to the right from the value name, then do the same for value 2, and select the appropriate option from the 3 provided ones.
One-way Bound Pair
The underlying relationship type: many-to-one, represented by WHEN-THEN statements in the left column.
We would like to exclude combinations like āBreed of Animal = Shiba Inuā and āType of Animal = Catā from the generated scenarios. We have 2 breeds for each of the first 2 types of animals. Therefore, we can set up 4 one-way bound pairs from "Breed of Animal" to "Type of Animal":
You can check your logic by reading the statement at the bottom of the dialog.
The order in which you set the pair matters!
In this case, we wouldn't be able to say WHENĀ āType of Animal = Catā THENĀ āBreed of Animal = Siameseā because that would prevent 'Cat + Persian' from appearing and would leave 'Persian" without any possible pairing.
Note |
---|
You may argue that the statement at the bottom still looks correct in this direction, however you need to keep in mind how the word "must" is interpreted by the algorithm. Since the evaluation is done at the "pair of values" level, "must have Breed of Animal as Siamese" = "must NOT have Breed as Persian, Shiba Inu, Golden Retriever, Arabian" - of which "Persian" is incorrectly excluded, therefore this direction wouldn't work for this example. We could use such direction if we had multiple types that can be with only 1 breed. |
Mutually Bound Pair
The underlying relationship type: one-to-one, represented by ALWAYS-ALWAYS statements in the left column.
With Mutually Bound Constraints, the values are exclusive to each other. In this example, there is only one horse breed in the second parameter. So, with 1 constraint, we can specify that "Horse" should not be paired with "Siamese, Persian, Shiba Inu, Golden Retriever" AND "Arabian" should not be paired with "Cat, Dog" - i.e., "Horse" and "Arabian" must only be tested together.
The final set of rules for this model (in the verbal form) would look like this:
In essence, Bound Constraints and Invalid Constraints perform similar tasks: they ensure that certain values only or never appear together - making all generated scenarios valid within the model scope. From a different point of view, Bound Constraints and Mutually Bound Constraints actually invalidate many values and Invalid Constraints bind many values, behind the scenes.
"Skip" constraints
"Skip" constraints are only available under the Advanced Mode which is enabled per request (toggle in the top left of the Constraints screen).
"Skip" constraints allow for certain parameters to be excluded from test cases when it is not appropriate for them to appear. It is a faster alternative to the "Not applicable" + Bound Pairs approach. However, as the feature is in the beta stage,Ā please note that there are a couple open defects, specifically around the interaction of "Skip" constraints with the regular ones. So if you encounter any issues, feel free to reach out to SupportĀ or avoid skips for the time being.
How to Use Skip Constraints
For example, letās use this plan below for a flight booking system:
In this model, only customers who are in First Class get in-flight dining. Coach and Business class customers do not get in-flight dining. Therefore, test cases with Coach and Business class customers should have no value for āFood Choiceā.
First, navigate to Rulesā Constraints.Ā Next, click the toggle to change to Advanced Mode ā that is the only way to implement "Skip" constraints:
Once in Advanced Mode, we use the following syntax for "Skip" constraints:
Ā Ā Ā Ā Ā Ā Parameter[Parameter Value] >> Parameter(s) to be skipped
So, for our example, the syntax is this:
The ability to include multiple values in the same constraint is an aspect of the Advanced Mode that is not limited to "Skip" constraints.
Now, when we generate our test suite by navigating to Scenarios, any row that includes āTicket Typeā as āCoachā or "Business" will have no value for āFood Choiceā:
You can also skip multiple parameters that are listed next to each other in the Parameters screen. For example, letās say that Coach customers now get no food, drink, or checked bag. Thus, they should have blanks for each of those parameters. Since we have those 3 sequentially in the table of parameters (refer to the model screenshot at the start of this article), we canĀ use the following syntax:
Ā Ā Ā Ā Ā Parameter[Parameter Value] >> First Parameter to be skipped :: Last parameter to be skipped
The boundaries are inclusive, therefore, for our example, that looks like this:
Now, when we generate our test suite by navigating to Scenarios, any rows with āCoachā for āTicket Typeā have no value for āFood Choiceā, āDrink Choiceā, or āChecked Bagā:
The final component of "Skip" constraints is the āskip to endā capability. In this case, we can tell Xray Test Case Designer that for some parameters values, skip all parameters listed later (below) on the āParametersā page.
So, for our example, we could return to our Parameters page and reorder the elements so that āFood Choiceā, āDrink Choiceā, and āChecked Bagā are the last three parameters:
Then, we use the syntax below to skip to end:
Ā Ā Ā Ā Ā Parameter[Parameter Value] >> First Parameter to be skipped::!!
For our example, that looks like this:
Lastly, you can do a quick review of available options & syntax by clicking the āUsageā button in top-right section of the Advanced Mode:
View a Constraint
UI Steps | ||||
---|---|---|---|---|
| ||||
|
Edit a Constraint
To edit a constraint, you need to change view to "bulk" . Then you can edit the constrain type selecting the corresponding operator.Ā
It is not possible to edit a constrain at the Standard View. In the Standard View you are only allowed to delete and create a new constrain.
Delete a Constraint
To delete a constraint, hover the constraint and select the delete option:
Bound constraintsĀ restrict parameter values that canĀ onlyĀ be tested together.Another option is to, on bulk view mode, delete the desired constraint line: