Dismissing with the X now behaves the same as dismissing with the "cancel" link.
Including one or more trailing commas at the end of a set of comma-delimited parameter values in bulk edit would cause the parameter and values on the next line to be interpreted incorrectly.
You can now hover over truncated long plan names to get the full name.
Happy New Year everybody!
We're getting back into the swing of things here at Hexawise HQ after the holidays with a nice, easy one.
Some unusual cases could cause errors when saving parameter values when blank requirements existing. Spooky action at a distance? Only in very specific cases? That's what combinatorial testing is all about!
Exporting would fail in some cases when there were requirements with no values specified. A pairwise defect.
A pairwise defect around interactions with certain sequences of value pairs would prevent requirements import from completing successfully. This has now been resolved.
Some of the quiz questions in the Identifying Variation self-assessment quiz were improved to be more clear and relevant.
Link to the "Key Concepts" information for the "Strength of Combinations" quiz was broken
"Strength of Combinations" link from achievements was not working.
Now it does.
This is representative of an interesting and sneaky class of pairwise defects. If you have some thing, call it X, that applies or happens every time any number of things, call them Y's, happen, then you have a potential for a defect if 99 out of the 100 Y's properly cause X to happen, but one of them doesn't.
To make this example more concrete, in this case, test plan revisions are created every time a test plan is manipulated (which happens in many dozen different ways). All of these various manipulations caused a revision to be created, except for bulk delete which did not.
Once a set of test cases gets very large (hundreds of tests), lots of parameters, Hexawise starts to display a slimmed down display of the test cases where any values aren't replaced, and bolding of parameter values forced by requirements doesn't happen, etc.
In those cases, the expected results column that shows the expected results from requirements (if any) was also not shown. This could be confusing as to if Hexawise is actually using the specified requirements (it is). These expected results are now always displayed.
Thank you to Aditya for requesting the improvement.
Previously the description had a dangling reference to an expected result when there was none, and it did not include the expected result description. Now it doesn't and now it does respectively.
Now it does.
The most recently generated strength wasn't shown first by default if 2-way strength test cases also existed. 2-way test cases were shown instead until another strength was selected.
Fixed some 2-way, 3-way and even 4-way defects found in production with determining if expected results from auto-script steps apply to a test case or not. These defects involved parameter values that have been value expanded (2-way), value expanded and condition with "is not" (3-way), and value expanded and condition with "is not" and the other values that it "is not" are also value expanded (4-way)
The test plan strength picker in the Auto-scripts preview panel did not reflect the selected new strength after you used it.
Today marks a big new release of some functionality that has been in beta testing for quite a few months. We started calling this set of functionality "Hexawise 3.0" internally. Specifically,
There's too much to list everything, but some important highlights are:
We are calling this "Part 1" as there are other substantial improvements under the "Hexawise 3.0" umbrella that have not yet been rolled out.
We hope you enjoy the vastly improved Hexawise experience and are very appreciative of the customers that have been beta testing this with us for the past few months.
Drop us a note or a chat message to let us know what you think!
Parameter name→value replacement in test case name and test case description fields of the HP QC / ALM export was not working properly if the parameter name contained certain special characters (a classic pairwise defect).
Thanks to Kavya for reporting the issue.
A 2-way error, browser specific.
Chrome specific, so a 2-way defect.
A relatively rare 3-way defect in production. To trigger the issue you needed a test case with any "any value" that was then replaced with a value that happened to cause a value pair constraint violation so was then replaced with a value that happened to be a range. In this case, the range stayed as is and was not changed to a value within the numeric range.