General Configuration

By default, the workflow toolbar for a test is not shown when viewing it. If the workflow toolbar is needed for any reason, select this box.

By default, Zephyr Squad checks for new software updates.

By default, Zephyr Squad adds the "Test" issue type on every new software or business project that is created. If this is unchecked, then new software or business projects will not get the "Test" issue type. If you need to add it later, do so from that project's administration page, issue types section.

By default, the Zephyr Permission Scheme is disabled. This feature allows users to add more control over the security of the test issue and details.

Zephyr Squad now writes easy-to-read logging information into its own log file. This file will have the details on the service calls, information messages, and error message details.

Maximum log file size of zephyr-jira.log.

Maximum number of zephyr-jira.log backup files.

Determine what issues types a Test issue can be created from in all Jira projects. Selected issue types will have an additional option in the More Actions drop-down to allow creating test issues and linking directly back in one action.

By default, Issue Security is disabled. This feature allows users to add more control over the security of the test as an issue in the project.

Administrators now have the ability to enable or disable the viewing of filters for labels or All on "Test Summary" page. By default, both options are disabled.

By default, the Zephyr Dashboard is selected when a user clicks on the Test Metrics menu item in the top-level Tests menu. This can be replaced with an existing dashboard by selecting that dashboard from the drop-down list here.

For context, the "executedOn" property for a test execution isn't updated if the execution is updated with the same status. For example, if the execution status is set to "PASS" and the user updates the execution status with "PASS" again, then the "executedOn" property of the test execution will not be updated.

When users enable this, Zephyr Squad will update the "executedOn" property of the already created execution even in the scenario that the execution status is update with the same execution status.

The reason that some users may need this enabled is for the scenario when users are triggering automation scripts to create/update the execution status within the same test cycle. If the "executedOn" property isn't updated for this scenario, then users utilizing automation scripts may not be able to generate accurate test automation reports. Reports would not be able to determine the number of test cases executed.

Within the test metrics dashboard, it houses all the supported gadgets by Zephyr. By configuring the gadget cache configurations, Zephyr can populate the data within those gadgets based on the cache interval set by the administrator.

For example, if the cache interval is set to 1 hour, then the gadget data and all the graphs will remain the same for the hour. The cache interval will take effect after the 1 hour has passed and will continue to be updated every hour.

The reason that this may be used is to provide improved performance for the test metrics dashboard. Every single gadget refresh call contains an API call and each API call can be extremely resource intensive depending on the data for the gadget. By enabling and configuring the gadget cache configurations, Zephyr is only processing the cached data which significantly improves the performance of the dashboard.

By default, the execution workflow is enabled and if the user wants to refrain from configuring the workflow for projects, then this option can be enabled or disabled.

Zephyr provides the execution workflow feature to be able to log the time for all executions based on the Jira issue (test) data.

For example, Jira issues go through the workflow life cycle which cycles through the following and Zephyr's test execution maintains the same life cycle. All the time information regarding time tracking for the execution is also used from the Jira issue time tracking data.

To-Do → In-Progress → Done

In Zephyr Squad, test cycles and folders can be cloned. By default, the option to append the "CLONE" prefix is enabled and when you clone both test cycles and folders, the "CLONE" prefix will be present.

The "CLONE" prefix is an option that can be enabled and disabled through the general configuration settings for Zephyr Squad.

The reason that this may be enabled is because users may want to include the "CLONE" prefix added to their cloned test cycles and folders to be able to distinguish which one is the original test cycle/folder and which one is the cloned one. Users may want to disable this option if they plan to rename the cloned test cycle/folder rather than using the same name with the "CLONE" prefix attached as well.

In Zephyr Squad, test cycles and folders are viewed in the cycle summary page. By default, Display Release Versions is enabled and it will display all test cycles whether or not the test cycle version/release is released or not. The option to Display Archive Versions is disabled and it will not display any of the test cycles for the version/release on the cycle summary that have been archived.

The Display Archive Versions is an option that can be enabled and disabled through the general configuration settings for Zephyr Squad.

The reason that users may want to enable this option is to be able to view all the test cycles and folders regardless of whether or not it was in a version that was released or archived. This way, users can have access and be able to view all current and previous test cycles and folders. Some users may want to disable this option if they have too many test cycles and folders and would like to view only the current test cycles and folders and not the test cycles/folders from the released or archived versions.

For the sake of a clearer UI, you can hide or show the Help menu item.

For the sake of a clearer UI, you can hide or show the Test Automation menu.

By default, this is on, which means that when a defect is filed from a test execution, that defect (issue) will have a link pointing back to the test. Disable this if too many remote links are being created in that issue.

By default, this is on, which means that when a defect is filed from a test execution, that defect (issue) will have a remote link pointing back to that specific test execution. Disable this if too many remote links are being created in that issue.

By default, this is off, which means that when a defect is filed from a test step execution, that defect (issue) will have a link pointing back to the step. Disable this if too many remote links are being created in that issue.

By default, this is off, which means that when a defect is filed from a test step execution, that defect (issue) will have a remote link pointing back to that specific step. Disable this if too many remote links are being created in that issue.

By default this is off, which means links are outbound from defects and inbound to tests (i.e. Test <-- Defect or in other words, Test "is blocked by" Defect and Defect "blocks" Test). Select this if you want them to go the other way around.

Link types can be selected from here and applied to all existing links between tests and defects. Different link types can be set up in Jira's configuration and they can be selected from the drop-down menu here. By default, Relates, Blocks, Cloners and Duplicates are available.

Link types can be selected from here and applied to all existing links between requirements and tests. Different link types can be set up in Jira's configuration and they can be selected from the drop-down menu here. By default, Relates, Blocks, Cloners and Duplicates are available.

Ever so often Zephyr Squad's indexes (alongside Jira's indexes that apply to tests) need to be regenerated. This can help in various cases when and is a common requirement when information is being updated consistently and accurate information is not being displayed in Jira. Administrators can re-index all projects or just a selection of some projects from here. Once the projects have been selected, click on the Re-Index button. This might take some time based on the amount of data and users present in the system.

If you are using a Jira cluster, you can run Zephyr re-indexing on any node. If you do that, all of your nodes will be set to maintenance mode (in this case, the Zephyr functionality will not be available). After re-indexing completes, all the changes will be automatically pushed to the other nodes of the cluster.

http://JIRA_URL/rest/zapi/latest/execution/jobProgress/0001568626803755-664089f649e-XXXX?type=reindex_job_progress

The Zephyr index file is saved locally on each node, while the Zephyr index snapshot file is stored in a shared home directory:

\shared home directory\zfj\index_backup 

(the file is not configurable).

If you need to recover the index file, you will have to do that manually. Once you do that, it will become available to the other nodes.

To monitor the health of the index files, use the Integrity Checker for the index on the "General Configuration" page under the Data Center option.

Cleanup cycle indexes. This may take a long time depending on data size.