An expanded parameter value used to be shown as, "value - value expansion", but the value expansion is likely the most relevant value to the test case, so the test cases UI now shows them as, "value expansion - value".
A classic defect of the pairwise genre.
This was an interesting 3-way defect involving a prior action (importing a test plan), specific data variation (pure integer parameter values), and a later action (editing one of the parameters that contained pure integers and saving the edit). By themselves, none of these 3 actions caused any issues. All 3 together combined to create a defect.
This is an unusual (though reasonable) user behavior. Just the kind of thing to include as variation in your test plans.
This was a regression.
Now when you are importing requirements, the import can contain new parameters and new parameter values that are not currently defined in your test plan. If new parameters or parameter values exist in your requirements import, they will be added to your test plan for you.
Adding
Hexawise now provides an option to create a sample of some parameters and parameter values in an empty test plan.
Unless you visit the Automate script view, you may not have an up-to-date script that matches your most recent test plan changes available to export. Hexawise used to allow you to export the out-of-date Automate script, but this is rarely what you want to do. Instead now Hexawise prevents an out-of-date script from being exported.
If your test plan only has Automate test scripts, and no manual testing auto-scripts, then Automate will be active by default when you navigate to the Auto-scripts tab.
This is an exciting productivity enhancer! When defining required scenarios, you'll often find that the scenario contains a testing idea, either a parameter or a parameter value, that your test plan does not yet account for. Before, this would mean breaking your flow of inputting required scenarios and opening the inputs tab to define a new parameter or parameter value. Now you can make these additions directly in the requirements UI.
The requirements import used to assume the first 3 columns in the import file were the designated name, description and expected outcome columns. It now looks at the column headers.
An unusual scenario involving two browser tabs editing the same test plan could result in a blank Hexawise UI after attempting to export. Not any more.
These are now escaped appropriately so Excel doesn't see the cells as formulas.
Thanks to Vikramjeet for reporting the issue.
Fixed a regression where the delete all constraints action actually deleted nothing.
“Tired, tired with nothing, tired with everything, tired with the world’s weight he had never chosen to bear.” ― F. Scott Fitzgerald
Hexawise now ensures your parameter inputs and constraint logic are always working well together through the use of the generated implied value pairs (constraints). This keeps you from having any "no possible value" scenarios in your generated test cases.
There are however certain bulk modifications you can make to your test plan in bulk edit where Hexawise knows you are going to end up with "no possible value" scenarios, but we don't want to simply prohibit those changes when you want to make them. Instead now, with this new addition, Hexawise will present a warning, and if the warning isn't heeded the test plan will contain a banner indicating it's in a state where some of the values in the generated test cases will contain "no possible value". Once the inputs and constraints are brought back in sync to be logically consistent (Hexawise still helps with this where it can) the banner will clear out on its own.
When we moved to the new graphical married pair creation dialog we stopped using the order in which parameter values were clicked to layout the dialog. We got feedback that even though the constraint can be expressed regardless of the order, it's less confusing if the click order is used for the layout. We now use click order in the dialog again.