If you are editing your auto-scripts outside the tool in Excel, the expected results conditions for a a step used to be marked with bolding. This proved to be brittle to different versions of Excel representing bolding in different ways, so this has been replaced with the curly bracket { } syntax used elsewhere throughout the Excel file format.
To see an example of this, look at the sample Excel import file linked from the "Create New Test Plan" dialog, or export an Excel export of a plan that has at least one auto-script step with an expected result condition, then look at the "Auto-Script Definitions" tab.
If your login to Hexawise times out, we prompt you to log back in. Not a big disruption. But what if you timed out just before submitting a big edit to your plan, or you just completed showing your competency by answering some questions to level up? In some of these scenarios, the action you were trying to take would be lost.
We've done a lot of work to try to eliminate these cases and ensure that you'll never lose what you were trying to do to a timed out login. It's not perfect yet, but it's much, much better.
This link, located in the header bar of the Auto-Script panel anytime you have more than 2 steps in your Auto-Scripts was low contrast. Now it isn't.
If you had plans with a very large number of parameters and very large number of generated test values the export dialog would take a long time to load. While the export will take a while in this case, the export dialog should not.
In rare cases, the latter of numerous requirements could be ignored and not included in the generated tests.
Thanks to Andrew for reporting the issue.
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 one has been around for a couple years now. We've seen it pop up once a month or so in our automated bug reporting system, but could never replicate it. That's because the interactions it requires to trigger the defect are of the "those could never interact variety". It required a specific browser, specific data, and a specific sequence of events including an action that you wouldn't suspect has any relation to the data.
Andrew "Sherlock Holmes" Shindyapin finally tracked it down:
If you are in Internet Explorer, AND you create a new plan, AND you enter a plan name that contains unicode characters into the dialog, AND you then click on the "what kind of files" link, then you got an error.
Now you don't.
Once there were enough value pairs to force a scroll bar and if the parameter names were long enough, not enough space was reserved for the delete icon forcing Chrome to resize it into a tiny, Alice in Wonderland icon. This was a 3-way bug if you are keeping track: Chrome, lots of value pairs, long parameter names and values.
In Internet Explorer, when selecting a parameter from the parameter name drop down to reuse it from another plan, the parameter values would all be on one line rather than newline delimited. This is fixed.
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.
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.
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.