If you used the test plan dialog to change certain aspects of a test plan, such as its name or project, and that plan also happens to be the plan that you are currently editing (2-way defects), then those aspects would be stale and would continue showing the old data until you refreshed or changed plans.
We made some upgrades to some important system software that should result in noticeable performance increases for many Hexawise operations.
This was a strange pairwise defect.
In Hexawise, plans are shared in a project. We now made it easier to share a plan into a new project. When you click the share action, there's now an option to select existing projects, or to create a new project right there.
Want to guess if this bug was a pair-wise defect? If you guessed 'yes', you're a winner!
If a user was invited to a project by someone that did not originally create the project, the invitation said that the project creator is inviting them to the project. Now it correctly identifies the inviter to the invitee in the invitation.
Fixed a regression that occurs only when exporting with no test cases. A classic pairwise defect.
Searching in the plan revisions dialog, then coming back into it kept the old search criteria, which then also caused layout issues in the dialog. This is a classic combinatorial defect caused by a sequence of specific actions.
The email you get when a project has been shared with you now includes a list of the test plans in the project and links to the test plans.
The requirements traceability of requirements to the test cases where they appear was only exported as a sheet in the HP QC/ALM export. It is now also exported as a sheet in the Excel export and a CSV file in the CSV exports.
You can now hover over truncated long plan names to get the full name.
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.
Dismissing with the X now behaves the same as dismissing with the "cancel" link.
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!
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.
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
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.
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.
Now it does.