A pairwise defect, only affecting IE8 at specific screen resolutions.
Thanks to Amanda for reporting the defect.
As the window height decreased, space would no be apportioned properly like the other tabs. This is fixed.
HTML/XML content is now escaped before exporting to Excel or any of the Excel based export formats (like HPQC).
Thanks to Cortney and Wayne for reporting this issue.
Exporting these at the same time would result in both files containing the HP QC export. Either worked fine singly, so this is a classic pairwise defect.
These notes now don't have a title bar.
Administrators for paying customers can custom configure the HP QC export for their own HP QC instance. This now includes the ability to provide alternative names for the fields that are always present in the export.
Fixed a graphical glitch and allow the dialogs to be dismissed with the enter key.
We've just added help file instructions for using the Married Pairs feature (together with a worked example that explains WHEN and WHY you will want to use it.
This information about how to use Hexawise's Married Pairs feature is available here
If you dismissed the pair removal confirmation dialog with the keyboard rather than the mouse (a truly classic pairwise defect) the highlighting of the pair in the parameter/values table would get stuck until a refresh. No longer is this the case.
They used to be in created at order, but they now match the value pair ordering in the UI (which is in what we call, "plan order").
We will no longer suggest any plan name for your copied plan (defaults to: Copy of plan name) that will conflict with a plan you (or the project) already has.
If you do something really tricky, such as simultaneously move the copy to a project that has a plan with the name that we suggest. If you do that, then you are on your own, and you get what you deserve (a scolding warning message) you sneaky devil.
Copying a plan could result in the new copy not having the expected result paramater names selected for the conditions. This is now resolved.
Parameters are now put in "plan order" in invalid pairs and bi-directional married pairs, where the ordering is inconsequential, but uni-directional married pairs were similarly re-ordered, which changes their semantics. No longer.
Resolved.
These fields could get awfully cramped in the UI. They are now more expansive.
Certain sequence of events could result in a blank HPQC export. No longer.
You can now click on the Mind Map export radio buttons before clicking the checkbox. This is more user friendly.
In most cases you'll want to directly d/l exports. Do note that if the plan is extremely complex and the export takes so long that your browser client times-out, you may have to use the email option, which is not subject to browser timeout limitations.
In case you are curious about the technical details. This was a relatively rare 3-way bug. It only occurred when:
These the variables together caused there to be a number cell with a carriage return in it, which Excel is distinctly unhappy about.
Thank you to Mary for finding and reporting the issue.
If you happen to resize the browser window with a Hexawise modal dialog box open, it'll now respond much better in keeping the modal dialog roughly where it should be.
This works now.
This dialog is too big for tiny screens and both the OK button and X could be obscured leaving you no way to dismiss the dialog other than to refresh the page. You can now dismiss the dialog with enter or ESC.
We've swapped out the JavaScript plumbing that powers the Web UI for Hexawise, so if you see any issues on your configuration, please let us know.
We can now talk to you with a message that pops up when you log in. Be afraid. Be very afraid.
In our Auto-Script screen, we want to make it easy for testers to determine when the Expected Results they've entered will appear and when they won't. So we've color coded them. When users create Expected Results and then highlight test scripts on the bottom of their screen, the color of the Expected Result is supposed to change from green (in tests that contain the Expected Result) to red (where the Expected Result does not appear). In one weird case, this wasn't working.
It turned out to be a pairwise bug. Specifically, it wasn't working properly when a user:
Incidentally, we're classifying this one as a "grapefruit juice bug" (blog post coming soon) because our lead developer wrote this:
"Justin, The fix is in place. Unsurprisingly it was a pairwise issue. The kind that developers would tell a tester 'that can't exist.'
Cheers, Sean"
Thank you Prathiba for bringing this issue to our attention!