Understanding the Transition from Zephyr Squad to Zephyr
This topic explains how Zephyr differs from Zephyr Squad (now Zephyr Essential), why the change was made, and what you can expect across test cases, test cycles, test execution, and reporting. Use this topic to understand the key differences before you start the migration. When you are ready to begin, see Migrate to Zephyr.
The biggest change: test cases are no longer Jira issues
In Zephyr Squad, test cases were Jira issue types of the type "test." They behaved like any other Jira issue, such as a bug, story, or task. Test steps were created and managed within the Jira issue, traceability was set up through Jira issue links, and test cases, cycles, and reports were all project-specific. Sharing test assets across Jira spaces was not possible.
In Zephyr, test cases are standalone Zephyr test entities rather than Jira work items. This improves performance because test details no longer need to be fetched from both Jira and Zephyr Squad separately. Test cases live in a structured test library, separate from your Jira issue backlog, and test steps are managed within the test case in a clean, structured format.
Why upgrade?
Zephyr is designed for growing teams and enterprise needs. It offers improved visibility, reporting, and test management workflows. The goal of the transition is not to force a new way of working, but to give your team a platform that supports your current processes and allows you to adopt advanced capabilities over time.
Whether your team follows Agile, Waterfall, Hybrid, or a custom workflow, Zephyr can be configured to align with how you plan, design, execute, and report on testing. Teams can start with a simple approach that mirrors their current process and gradually adopt capabilities such as reusable test assets, traceability, version control, and data-driven testing as their needs evolve.
Working directly from your Jira work item
Zephyr lets you manage testing without leaving Jira. From any Jira work item, such as a story or bug, you can do the following:
Create new test cases.
Link existing test cases from the same or other projects.
Create or link test cycles.
Trigger one-off test executions.
When you create a test case from a Jira work item, traceability links are established automatically, so requirements and testing activities remain connected without any additional effort. This streamlined workflow reduces context switching, saves time, and improves productivity for both testers and developers.
Full traceability
Zephyr provides end-to-end traceability across all your Jira projects, from requirements to defects. You can associate test cases with user stories, epics, bugs, and other Jira issues, and view how testing activities relate to development work at every stage. This ensures better test coverage and makes it easier to audit which requirements have been tested and what the outcomes were.
Traceability can be created directly from a Jira work item through the Zephyr menu, or through the traceability tab on test cases, test cycles, or test plans.
Test cases in Zephyr
In Zephyr, test cases are managed as dedicated testing assets rather than Jira issues. This provides a centralized location for test design, execution, traceability, and maintenance.
Each test case includes standard fields such as Priority, Objective, Component, Labels, and Test Data. Administrators can configure custom fields to capture information specific to their team's process. The Component field is linked directly to Jira Components, and test cycles can be linked to Jira Release Versions, making it easier to organize testing around planned releases.
You can also do the following from a test case:
Associate test cases with user stories, epics, bugs, and other Jira issues directly through the traceability tab or the Zephyr menu on a Jira work item, without using Jira issue links.
Add screenshots, files, or detailed descriptions to improve test clarity.
Organize test cases in folders and subfolders, and use filters or search to find them quickly.
Note
Any data created in Zephyr Squad during the migration process is not transferred. If your team continues testing during migration, those test cases and results need to be recreated manually in Zephyr afterward. See Migrate to Zephyr for details.
Reusing test cases with Call to Test
Call to Test is a modular testing feature that lets you reuse test steps across multiple test cases by calling an existing test case as a reusable module. This supports nested calls, so complex test scenarios can be broken into manageable parts. When you update a shared test case, the change is automatically reflected everywhere it is called.
This is useful for common workflows such as login, user registration, or checkout validation. Define the steps once, reuse them everywhere, and update them centrally.
Data-driven testing
Zephyr supports data-driven testing, which lets you define parameters within your test steps, such as username or password, and create one or more datasets that are dynamically applied to those parameters. You can then run the same test case across multiple input scenarios without duplicating steps.
For example, instead of creating five login test cases with different users, you create one test case with {{username}} and {{password}} parameters, then define a dataset with multiple user credentials. This reduces the number of tests you need to maintain while improving coverage.
Version control for test cases
Zephyr includes built-in test case versioning. You can create a new version of a test case when you need to update it, while preserving the execution history tied to the previous version. You can compare versions side by side, roll back to a previous version if needed, and maintain a complete history of changes to steps, test data, and metadata. Execution records remain tied to the version that was active at the time of the test run, ensuring auditability.
Note
Execution history is not migrated during the transition to Zephyr, and BDD data is also not supported by the migration engine. For details on what data is and is not migrated, see Migrate to Zephyr.
Common questions about test cases
Question | Answer |
|---|---|
"We liked having tests in our Jira board." | You can still link test cases to Jira issues such as stories or bugs, and view execution status in Jira. You can also create test cases, link existing ones, create or link test cycles, and trigger one-off test executions directly from any Jira work item. |
"It's more clicks." | The initial experience involves more steps, but over time you save time through test case sharing, Call to Test, bulk execution, and advanced reporting. |
"This isn't how we work." | Zephyr is flexible enough to support teams at every stage of their quality journey, regardless of methodology. You do not need to change your existing process to start using it. |
Test cycles in Zephyr
In Zephyr Squad, test cycles were tied to a single Jira project's releases. You created them within a Cycle Summary view tied to each Jira project, grouped them under a version or release, and could only add test cases manually from the Jira issue picker.
In Zephyr, test cycles are dedicated execution containers that are modular, reusable, and structured. They are managed from the Test Cycles module within your Jira space and can be organized using folders and subfolders. Test cycles are not required to be tied to a Jira release, though you can optionally associate them with Jira Release Versions when needed.
Test cycles in Zephyr also support the following:
Cross-project test management: include test cases from multiple Jira projects within a single cycle.
Flexible test execution: add the same test case multiple times within a cycle to execute it against different environments, releases, iterations, or testers, without duplicating the test case.
Execution history: view historical execution results for a test case across cycles and releases.
Retesting: re-run a test case when a defect is fixed or validation is required, while preserving execution history.
Advanced management: use filtering, grouping, sorting, and bulk actions to manage large test cycles efficiently.
For recurring testing efforts, you can create a test cycle directly from a folder in the Test Repository. For example, if your regression test cases are organized in a Regression folder, you can create a new cycle from that folder using the actions menu, which automatically populates the cycle with the relevant test cases.
Common questions about test cycles
Question | Answer |
|---|---|
"Where do I create my cycle release?" | In Zephyr, cycles do not need to be created under a Jira Version. You can create a cycle first and optionally associate it with a Jira Release Version later. |
"Do I need to create separate test cases for each environment?" | No. The same test case can be added multiple times within a cycle and executed against different environments, browsers, datasets, or testing scenarios, while tracking each execution independently. |
"How do I run my regression suite every release?" | Organize your regression, smoke, and UAT tests into dedicated folders in the Test Repository. When it is time to test, create a new test cycle directly from the folder. |
"What happens when a test fails and needs to be rerun?" | You can retest without creating a new test case. Zephyr lets you re-execute test cases while preserving execution history, so you can validate fixes and maintain an audit trail. |
"I can no longer search test executions using JQL." | Zephyr does not use JQL for test executions, but you can access execution data through built-in reports and dashboard gadgets, filtered by project, cycle, status, tester, and more. |
Executing tests
Test execution in Zephyr takes place within the Test Player, a dedicated workspace for executing, tracking, and managing testing activities. Whether you are running a single test case or an entire regression cycle, the Test Player provides a centralized view of test progress, execution results, defects, and execution history.
To begin execution, navigate to the Test Cycles module and select the cycle you want to run. This opens the Test Player, where all test execution activity is tracked.
Within the Test Player, you can do the following:
Execute test cases and individual test steps.
Mark steps as Pass, Fail, or Blocked, or any other custom status.
Add comments, actual results, and supporting evidence.
Attach screenshots and files at the execution or test step level.
Create or link defects directly from a failed test or test step.
Track testing time and execution progress throughout the cycle.
For larger cycles, the Test Player provides Group By functionality that lets you reorganize and filter test executions by status, environment, or tester.
Not every test execution requires a formal test cycle. Zephyr supports ad hoc test execution, which lets you execute a test case directly when validating a defect fix, performing exploratory testing, running a quick smoke test, or verifying a specific requirement. Ad hoc executions still create execution records, so you can capture results, link defects, add evidence, and maintain a complete testing history without first creating a dedicated test cycle.
When a test is executed, Zephyr creates an execution record. If the test needs to be run again, you can start a new execution without creating a duplicate test case. Previous execution results are automatically archived and remain available for review. Execution history includes previous execution results, tester information, execution timestamps, linked defects, comments and attachments, and historical records for comparison and auditing.
Common questions about test execution
Question | Answer |
|---|---|
"Do I need a test cycle to execute a test?" | No. While test cycles are recommended for planned testing efforts, Zephyr also supports ad hoc test execution directly without a cycle. |
"What happens if I stop testing before I'm finished?" | Your progress is saved. Test executions can be paused and resumed later without losing results, comments, attachments, or defect links. |
"Can multiple testers work in the same test cycle?" | Yes. Test cycles can be assigned across multiple testers. The Test Player provides filtering and grouping capabilities so each tester can focus on their assigned work. |
"How do I find failed or unexecuted tests?" | Use the Test Player's filtering and grouping capabilities to group executions by status and quickly identify failed, blocked, or unexecuted tests. |
"Can I link defects directly during execution?" | Yes. You can create or link defects directly from a failed test execution or test step within the Test Player. |
"Where can I see previous test results?" | Execution history is maintained automatically. Every test execution is recorded and available for review, including previous results, linked defects, comments, attachments, and tester activity. |
Reporting in Zephyr
Reporting in Zephyr is built specifically for test management. Unlike Zephyr Squad, where reporting relied on Jira dashboards and issue-based reporting, Zephyr includes a dedicated reporting module with 31 out-of-the-box reports designed around testing activities.
Zephyr reports are organized into two categories.
Test Execution Reports provide visibility into testing progress and execution results across your organization. Available reports include Test Execution Results (Summary), Test Execution Results (Detailed), Test Execution Results by Test Cycle, Test Execution Results by Tester, Test Execution Results by Project, Test Execution Results by Component, Test Execution Results by Iteration, Test Execution Burn Up, Test Execution Burn Down, and Test Execution Scorecard by Test Cycle.
Traceability and Coverage Reports help teams understand the relationships between Jira work items, test cases, and test executions. Available reports include Coverage Report, Traceability Report, Traceability Matrix, and Traceability Tree.
All reports support filtering by Jira projects, test cycles, test plans, Jira Release Versions, execution status, testers, components, labels, custom fields, and Jira issues through saved Jira filters (available on traceability reports). You can save commonly used report configurations as templates for quick access and consistent reporting across releases and sprints.
For teams that rely on Jira dashboards, Zephyr provides dashboard gadgets that can be added directly to Jira dashboards. Gadgets provide at-a-glance visibility into test execution progress, test execution results by status, requirement coverage, traceability metrics, release readiness, and tester workload and activity. Dashboard gadgets are particularly useful for stakeholders and leadership teams who need a high-level view of testing progress without navigating directly into Zephyr.
Common questions about reporting
Question | Answer |
|---|---|
"Can I report across multiple projects?" | Yes. Many reports support project-based filtering and include views such as Test Execution Results by Project. |
"Can I still report by release?" | Yes. Test cycles can be associated with Jira Release Versions, and many reports support filtering by release. |
"Do I need to build Jira dashboards and filters to get testing metrics?" | Not necessarily. Zephyr includes 31 out-of-the-box reports designed specifically for test management, reducing the need for complex Jira filters and custom dashboard configurations. |
"Can I show testing coverage for requirements?" | Yes. Traceability and Coverage Reports provide visibility into the relationships between Jira work items, test cases, and test executions. |
"When should I use a dashboard gadget versus a report?" | Dashboard gadgets are best for high-level visibility, such as release readiness or execution progress. Reports are best for detailed analysis, auditing, and investigating specific testing activities. |
"Can executives or stakeholders see testing progress without accessing Zephyr?" | Yes. Dashboard gadgets can be added to Jira dashboards, giving stakeholders visibility into testing progress, coverage, and execution status without navigating through Zephyr modules. |
See also
For steps to run the migration, track its progress, and complete the transition, see Migrate to Zephyr.