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.
"Strength of Combinations" link from achievements was not working.
Link to the "Key Concepts" information for the "Strength of Combinations" quiz was broken
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.
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.
Now it does.
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.
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 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.
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.
If you have some requirements, then freeze your test cases, and later need to thaw the test cases, your required test cases are preserved. Your prior required test cases will then contain a value for all parameters, but they will no longer be removed completely when you thaw.
Improve disabled disabled state and disabled message when HP ALM and Gherkin export are disabled.
Getting started, intermediate and advanced user guides are available in the Hexawise help.