It occasionally happened that by the time the new user accepted their invitation, the plan they'd been invited to share was no longer in existence. The new user would run into an error page. No longer.
Inserting a parameter into an auto-script step with the insert button as the only change didn't cause the change to register and so nothing was saved. This is resolved.
This only affected IE8 with certain project name sizes. A classic 2-way defect.
Normally sample plans are read-only, meant for you to read and learn from. It's often helpful to manipulate things while learning, and you may want to use a sample plan as a starting point for your own plan. For these reasons, sample plans now give you the (easier and more obvious) option to create a read-write copy for yourself.
Some parameter values would get bolded in these 2 screens because they contributed to an auto-script expected result or a requirement being fulfilled, but these outcomes aren't being displayed in these locations (like they are in an export) so the bolding made little sense.
Expected results weren't consistently correct in the rows they showed up in these two export locations. Now they are.
The alternate flow invited users get caused them to not get the new user tour. A classic pairwise defect.
It used to use "-1" in the filename, which is the internal identifier we use for mixed-strength. Not so user friendly!
Resolved.
The strengths of tests you could analyze used to be less than the strength of test you could generate for larger plans. No longer. You can now analyze any tests you can generate with Hexawise.
Hexawise can now analyze the coverage of your mixed-strength tests. Create some mixed-strength tests in the "Create Tests" screen, and then go to "Analyze Tests" and you'll see a mixed-strength option in the drop down which shows the analysis of the last mixed-strength tests you created.
An overly draconian security fix gone awry.
An overly draconian security fix gone awry.
If you add a requirement that has the same required parameter values as a requirement that already exists in your plan, you are warned, and asked if you really want to add the duplicate.
There is now a set of requirement manipulation links (add, edit, delete) at the right hand side of the requirement definition. This is handy for plans that have lots and lots of parameters so you are often scrolled all the way to the far right in the requirements panel.
There is now a spinner to decrease the likelihood that you add a requirement a second time by clicking Add while the first one is being added.
Now there is a message in this case that shows which requirement was satisfied by the test rather than a blank.
Very big plans that result in 5,000, 10,000, even 20,000+ parameter values in the overall test plan can tack a substantial amount of time for Hexawise to render (create the HTML that comprises the page) as each value gets some processing for things like bolding, purple italics, any value replacement, range expansion, etc.
This could result in a very long rendering time once the tests have been generated, sometimes so long as to time out the HTTP request.
Test plans that are very, very big like this now get a degraded rendering that forgoes the per value processing so that the rendering completes in a reasonable time. If a plan gets a degraded rendering it's explained in the user interface.
If you use Hexawise in multiple tabs, it's possible that the export dialog is open while you do something in the another tab that causes the cached generated tests to be cleared out. This would result in an error trying to export from the dialog. Hexawise is now smart enough to detect this rare situation and adjust.
The same security fix gone awry.
Most of the various panels you see in the Hexawise interface are collapsible and expandable and the current state is preserved so the interface stays how you last used it for that particular plan. There was a small exception to this in that the value pair panel auto-expanded as soon as you add a value pair (invalid pair or married pair). In this one case, where the panel auto-expanded, it wasn't sticky. So when coming back into the define inputs page for that plan the panel would be collapsed again.
This is a classic pair-wise defect. Value Pair panel collapse state is sticky? Check! Value Pair panel collapse state is sticky when value pair panel auto-expands due to value pair addition? Broken!
Broken no more.
When generating mixed-strength tests, you can't select fewer than n parameters to receive n-way coverage. For example, it doesn't make sense to ask for 3-way coverage on just 2 parameters. Hexawise has a user message explaining this, but this was covered up (literally in this case) in the user interface by a regression that happened when we changed how test generation results are retrieved. This issue is fixed.
Thanks to Geordie for pointing out the problem.
Mixed-strength tests start out with all parameters set to 2-way strength, but mixed-strength tests for this were still generated even if 2-way tests had already been generated. Rather than computing these as mixed-strength, Hexawise will now re-use 2-way, or 3-way or n-way tests from cache that match an all n-way mixed-strength test request.
The export type has to be represented somewhere, since you can export both at the same time into 1 zip file, but now the export type is in the directory name rather than the file name so the file name is more descriptive of the tests inside (file name is the test plan name and the strength of the tests, assuming it includes generated tests).
OPML importing is much more robust to a variety a variations in how the mind mapping or outlining tool might have exported the test plan inputs as OPML. Automated regression tests now in place on this to boot! QA FTW!