There is a new "Your Plans" dialog with important new capabilities:
Let us know if you have any trouble with the new dialog, and enjoy!
Only the first parameter to newly exceed 8 parameter values would get mentioned in the warning. Now it mentions all parameters that newly exceed 8 parameter values during a bulk add or edit.
As Expected Result value could return to original setting during editing subsequent expected result values in some cases.
Special thanks to Mohanned for reporting the problem.
There were issues round tripping plans through export and import with special characters (such as < & > " etc.) used in Auto-Script Expected Results.
A very classic pair-wise defect of specific set of user actions paired with unusual data. Neither caused an issue without the other.
Removing a parameter that is used in a requirement with bulk edit could result in the parameter not being removed from the requirement in some cases (after continuing through the warning dialog).
Parameter values w/ special XML/HTML characters (such as < & > " etc.) weren't getting escaped properly in recent versions of Chrome and so they'd be stored on the server as encoded values. This is resolved now.
Be aware that it could come up that existing plans that were edited in Chrome before this change may require manual cleanup. (Edit or remove the Auto-Script step's Expected Result, then save it again).
Note, this is a relatively rare 3-way defect discovered in production, you have to have XML/HTML special characters in your parameter value, you have to use the value in an Auto-Script step's Expected Result, and you have to be adding the Expected Result in a recent version of the Chrome browser.
Special thanks to Mohanned for reporting the problem.
Internet Explorer 8 (released in March of 2009) is no longer supported in Hexawise.
As of this date:
We recommend the latest version of Firefox or Chrome (which are on rapid release cycles) for best performance and compatibility.
We support Internet Explorer 9, 10 and 11. If you are using Internet Explorer, make sure you aren't in compatibility mode.
We support Safari 7+ (Mac).
In the test plan analysis page there is now an option to see an interactive matrix chart of pairwise coverage.
The new matrix chart visualizes the pairwise coverage in a set of 2-way tests after any given number of test cases. When the matrix chart appears, it automatically animates from no tests, to all the test, and then back down to the test that achieves at least 80% pairwise coverage. You can the explore the ramifications of any amount of coverage by moving the test case slider back and forth with your mouse.
Red cells in the matrix occur where a pair of values has not yet been tested together in a test case. Green cells in the matrix occur where the pair of values has been included in at least one test case. Black cells in the matrix appear where two parameter values cannot be paired together due to the value pairs constraints in the test plan.
We're excited to hear what you think about the new matrix charting, as always, feedback and suggestions are greatly encouraged!
Once the developers get their 3D holographic monitors, we'll start working on the matrix chart for 3-way tests, and as soon as multidimensional aliens arrive on the scene, we'll start working on 4, 5 and 6-way matrix charting.
If a parameter newly exceeded 8 parameter values after a bulk add or edit, the usual warning message wasn't displayed.
You can now set one or more parameters as 1-way in multi-strength tests. 1-way causes Hexawise not to pair the parameter values of the 1-way parameter with every other parameter value of every other parameter. You will have at least one test with every value of 1-way parameters, but you are not guaranteed to achieve pair-wise coverage of 1-way parameters.
You can often reduce your total number of tests by using mixed-strength and setting 1-way on a parameter with a large number of values that you are certain is not going to interact with any other parameters to cause a defect. If the parameter you're marking as 1-way does not have the most or second most number of parameter values in your plan, then you're not likely to actually save any tests by selecting 1-way coverage. Be certain to compare the number of tests you generate with and without marking parameters as 1-way to ensure you are getting meaningful savings for the coverage tradeoff.
If you have achieved Expert or Guru level (what's the hold up? Get cracking!) you can generate 1-way tests. 1-way tests merely ensure that every parameter value is tested once and don't achieve pairwise coverage. You will have as many 1-way tests as the number of parameter values in the largest parameter in your plan.
1-way tests are useful in rare circumstances for doing quick smoke tests on systems under test. Please use 1-way tests thoughtfully and with caution. These are not pairwise tests.
An empty error header would show in the UI when opening the UI to copy a plan in Firefox.
There were a few combinatorial issues when inviting users to a project. The wrong error message would display if the user was already a member of the project, or already had an outstanding invitation to the project or to another project.
These issues are resolved and the error message in these cases is clear, and an invitation to a different project no longer conflicts with a new invitation.
These exports were broken by a recent network security configuration change.
Thanks to Jenny for reporting the issue
Zoom, zoom!
You now get credit for completing the intro tour, even if you exit it out of it at the end rather than complete it.
tl;dr Mike is an amazing tester and found a complicated latent defect in Hexawise that had gone undiscovered for years. Unfortunately there's no simple way to describe this defect, so our apologies for the complex prose if you chose to read on...
If you have a large number of requirements and they cause 1-way coverage (all values of the parameter) to be completed on a parameter with a large number of values (let's call it parameter A), and you still have additional requirements after completing the 1-way coverage on parameter A, but those requirements didn't also require a value for the parameter A, you could trigger a defect where Hexawise would use a value of parameter A in a test that was satisfying a requirement to achieve 2-way coverage with a value of another parameter, without also locking in that value of A as that value of A for that particular test. The "any value" that is then reported for A in that test is not accurate, as a specific value is required there, and more problematic, the "any value" replacement value eventually provided for value for A might not be chosen as the same value that was used to achieve the 2-way coverage, leaving your generated tests without complete coverage.
This unusual set of circumstances is the first defect we've ever found in Hexawise that results in incomplete coverage. Major kudos to Mike for both finding the defect, providing a brilliant defect report, and also doing some initial detective work that made isolating the bug simpler. We have some pretty amazing testers as users of Hexawise!