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 (please, let us know if it doesn’t):

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 model, involves 3 steps.

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

It’s important to understand why we start by looking at the last row. Hexawise front-loads the interaction coverage as shown on the Analysis tab - Coverage Graph (tests earlier in the table achieve more coverage ). Therefore, by the end of the test suite, there are only a few interactions that are mandatory for Hexawise 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 Hexawise 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: when “I” is chosen, Parameter 5 is always “3”, i.e. can’t be “9”.

This logical conflict creates the NPV – Hexawise 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 with (constrained against) Parameter 5=7 and Parameter 5=9.

For more information on “unassigned” or “not applicable” values, please see our support articles - for example, this one.