Automation requires a lot of maintenance effort. There's the need of doing refactoring at many different levels, including at the specification level. This is even more true if you're adopting BDD and Cucumber. As your projects grow, the number of Cucumber Scenarios/Backgrounds will also increase, as will also the amount of Cucumber steps used by them.

Since (Cucumber) steps can, and shall, be used across different test specifications, you may need to do some refactoring on your existing steps in order to avoid duplicates and as means to foster reusability.

Thus, the Automated Steps Library provides one central place to see and manage all the Cucumber steps used in the context of some given project, allowing you to classify/label steps and refactor them (update, merge). You can even quickly identify the entities using those steps.

Steps are added automatically to the Automated Steps Library upon the creation/edition of Tests or Pre-Conditions. As soon as they're in the library, they can be used afterwards for easing the creation/updating of Cucumber Tests/Pre-Conditions, using autocomplete and filtering steps based on labels.

You can now be much more proeficient using the the enhanced editor for Cucumber based Tests/Pre-Condiitons, right inside Jira.

Learn more here.

Xray provides powerful capabilities for analysis of test results and coverage on a per environment basis, allowing users to easily understand how tests and requirements are on specific target environments.

However, Xray is somehow limited on the management capabilites of Test Environments; they are created similar to labels and they're available to all your Jira projects. You may require more advanced management capabilities for your Test Environments, such as the ability of defining and manage them on a per-project basis. Fortunately, there is Apwide Golive (previously known as "Apwide Test Environment Manager") which complements Xray built-in features, allowing you to fully manage Test Environments, their availability amongst other.

Learn more here.

Two new gadgets so you can easily track your QA progress in your Jira dashboards: Requirements List Gadget and the Overall Test Results Gadget .

The Requirements List Gadget provides an enhanced list of requirements, including hierarchical information (e.g. Epic > Story), along with completeness information and respective amount of Tests, analyzed in the context of some version or Test Plan. This information is similar to the one seen at the end of the page in the Overall Requirement Coverage Report whenever drilling-down on some requirements.

The Overall Test Results Gadget provides an overall overview of the status of some Tests, in the context of a version or Test Plan. Thus, you can see the amount of Tests currently passing or failing, using a pie chart or in a table layout.

Learn more about these and all other gadgets here.

Performance improvements

Continuing our previous and on-going work, we're doing some architectual changes that will provide benefits across several different areas in future versions. Some of this improvements have been addressed in previous v3.1.x releases and v3.2.0 adds some more, including the calculation of the Test Plans overall status/progress bar, global and per-folder (in the Board).

The work we've done so far will allow us to provide additional improvements on several areas, which we'll be doing gradually.

Improving performance is an on-going effort, so expect additional enhancements to come in future versions.

We know that the edition of Tests is quite dynamic; we also know that some users want to get notified upon changes of the Test/Pre-Condition specification while others don't.

Since Test cases are abstracted as Jira issues, you can also have changes on all the standard fields you may have at the issue level.

On the other hand, Jira's notification schemes don't allow you to define notifications on a per issue type basis, and you may want to get updates on Stories, Bugs and not on Tests, or vice-versa.

Thus, we have created a specific event that will be triggered whenever the specification of a Test/Pre-Condition is changed, giving you the ability to define notifications for it.

It will be triggered upon:

• adding/removing/updating steps in Manual Tests;
• updating the "Generic Test Definition" of Generic Tests;
• updating the "Cucumbert Scenario" of Cucumber Tests;
• updating the "Conditions" of Pre-Conditions.

Learn more here.