Possibility of auto-creating a value pair where both values are from the same parameter

This possibility of auto-creating this logical tautology was removed and the DB was swept of any cases where this had occurred.

New user tour

Some of the text in the tour was improved to be more clear for new users.

Missing implied value pairs

Two cases of level 1 value pairs that can be logically implied but were missed and were not auto-created for you are now created properly.

Thank you Rick for bringing this issue to our attention!

Support resources

The great resources at help.hexawise.com and hexawise.tv are now mentioned in the support page.

Value pair ordering in side panel

Hexawise's ability to present the value pairs in the most logical, top to bottom, left to right, order is much improved after some defects in ordering were resolved.

Exporting mind maps

The exporting of mind map files is now allowed regardless of whether the user first deselects the option to export Excel files.

Thank you, Pratibha!

Assistance avoiding "no possible values" in test cases

Hexawise now analyzes the logic of your value pairs (invalid pairs and married pairs) to determine if other value pairs are necessary to avoid having "no possible values" in your test cases. If additional value pairs are needed, Hexawise creates them and lets you know what that it did.

The analysis is thorough, it will create the needed value pairs in all 24 possible scenarios where they are necessary. Here are two examples:

Existing: when A is A1 then B is B1
New: when B is B1 then C is C1
Logically implied and added: when A is A1 then C is C1

Existing: A is A1 never B is B1
New: C is C1 always A is A1
Logically implied and added: B is B1 never C is C1

But the analysis is only 1 level deep. it won't find value pairs necessitated by multi-level relationships that may exist, and so it's still possible to have "no possible values" in test cases. Here's an example of a 2-level logical necessity it won't find for you automatically:

Existing: when A is A1 then B is B1
Existing: when C is C1 then D is D1
New: when B is B1 then C is C1
Logically implied and added: when A is A1 then C is C1
Logically implied and added: when B is B1 then D is D1
Logically implied but NOT added: when A is A1 then D is D1

NOTE: This only works while creating new value pairs, so it won't help you eliminate "no possible values" in existing test plans caused by already existing value pairs (unless you delete your value pairs and recreate them).

Ordering issue creating uni-directional married pairs

The order of the created uni-directional married pair would be reversed in certain cases. This is now fixed.

Export is via email

This change addresses an issue when exporting very large plans. The HTTP request/response cycle could time out before the export had been completely generated in some cases.

If you preferred our old export option, please let us know by emailing us at support@hexawise.com. Thank you.

Expected results always export to the first step of the auto-script

This is addressed and expected results export as expected now.

Expected results now stay put on the correct auto-script step when copying plans

Thanks to Justin G. for pointing out this issue.

Issues exporting certain Unicode characters

Some isolated issues exporting involving certain Unicode characters in certain positions in the plan have been addressed.

Scroll to the new expected result form on clicking to add an expected result

If you have lots of expected results on a step, and you click to add more, you could easily not notice that the form for adding new expected results is now shown since it would be out of sight. Hexawise now scrolls to the form when you click the link.

Sort order of value pairs

Value pairs in the side panel are now sorted in Param (primary) Param Value (secondary) order rather than in the order they are created. This makes scanning down the list of value pairs to ensure you have all the pairings you need much easier.

"Jitters" in the define inputs page on narrow screens or windows

Color-coding on expected results to show if they apply to the selected test

The test that's selected in the auto-scripts preview will drive color coding (red and green) of the expected result to show wether that test will trigger the expected result or not.

Tooltips on long notes could expand to the left rather than the right and so be off the screen

Married pair creation improperly disallowed

There was a case where bi-directionally marrying a pair where the 1st value of the new pair matched the 2nd value of an existing pair would not be allowed and a (non-existent) conflict would be reported. This is a pairwise defect for those keeping track at home.

Show the how-to progress checklist immediately after login

Before it wasn't visible until a plan was selected.

Allow more than 2 "is not" conditions on the same parameter in expected results

This is valid, but wasn't previously allowed.

Range expansion when ranges overlap

Parameter values that are ranges that also overlap with other values of the same parameter could be very confusing. You couldn't be certain which value was being tested in a specific test and it could make it appear as if value pairs aren't being respected.

Hexawise now detects range values which overlap with another range value or value of the same parameter and doesn't expand them (they stay their literal value "1-100" rather than some expansion, "59").

Expected results content in how-to progress checklist is updated

Corresponds to how expected results now work in auto-scripts.

Requirements and Auto-Script tutorial notice

Now takes you directly to the tutorial rather than to an interstitial link.

No warning about deleting expected results during bulk edit

Removing parameters (completely or by changing their name) during bulk edit operation now warns you if the operation will result in expected results getting changed or removed.

You can update a parameter name without affecting the expected results by using the single, rather than bulk, update.

Thanks to Harmony for reporting the issue.

Encoding issues with special characters in value pair values

This only occurred if the value was long enough to need truncated, the special character was early enough in the value to be before the truncation, and the value was used in a value pair. The rare 3-way defect caught in the wild!