How to Fix “No Possible Values” Faster

Learn a strategy for identifying the cause of “no possible value” appearing in your tests and for fixing the corresponding constraint conflict.

We’ve done multiple updates internally to address the constraint solver and introduce implied pairs to help reduce the number of “no possible values” (NPVs) in your test suite. However, there are still instances where the logic is complex enough or the sequence of actions is very specific – those situations can lead to NPVs appearing in your model.

Note: this document covers the NPVs caused by the flaws in user logic. Other scenarios, like 3-way constraints, could cause the NPVs that can most commonly be corrected manually after export.

The model used in this example has the following structure:

For the constraints, we will focus on a simple case involving only Parameters 4 and 5. According to the business rules for the system, parameter 5 represents the sub-class of parameter 4 and, in general, there has to be a 1-to-1 relationship with the preceding row. However, the system update added two values (7 and 9) which are not assigned to any values of Parameter 4 by design.

Intuitively, a test designer proceeds with the current model and applies the constraints in the following way:

After completing the last pair, the NPV banner should appear:

But, at the first glance, everything looks alright according to the business rules – 2 values for parameter 5 are unassigned and the others are in 1-to-1 relationships. Now the key question: why do NPVs still happen and how do we fix them?

One of the solutions, especially useful on larger models, involves 3 steps.

Step 1: Go to “Scenarios” tab in the ribbon and find the last row where “no possible value” appears (can use DesignWise search field/ Ctrl+F on Windows/ Command+F on Mac)

It’s important to understand why we start by looking at the last row. DesignWise front-loads the interaction coverage as shown on the Analysis tab – Coverage Graph (tests earlier in a model achieve more coverage than tests later in the model). Therefore, by the end of the test suite, there are only a few interactions that are mandatory for DesignWise to include since they have not been tested together yet (normal black font) and the rest are selected to maximize variation beyond the selected n-way level of coverage (italics).

Because of this, the NPV in any row can only be caused by the parameter values in normal black font. At the bottom of the set, there is the minimum amount of such values; in this example, “I” and “9”.

Step 2: Now that we know the “guilty” values, go back to the Constraints tab and check all the relationships associated with both (refer to the list above).

Parameter 5 = 9 doesn’t have any constraints. But, in DesignWise logic, it means “9” can be assigned to (i.e. paired with) any value of the Parameter 4, including “I”.

Now, for Parameter 4 = I, there is no flexibility: as you can see from the list on the left, when “I” is chosen, Parameter 5 is always “3”, i.e. can’t be “9”.

This logical conflict creates the NPV – DesignWise can not select the pair of values which satisfies contradicting conditions.

Step 3: Once the problem is identified, find the right solution.

The specific correction depends on the model and business logic. In this case, the value “unassigned” should be added to Parameter 4 and matched (constrained against) Parameter 5=7 and Parameter 5=9.