Zephyr review: pricing, alternatives and setup

Zephyr stores test cases, test cycles, test plans and executions as its own objects, organised in folders, rather than as Jira work items. Each test case has a key in the form SHOP-T123 and links bidirectionally to any Jira work type, so a story shows its test cases and a bug shows the test that found it. The design keeps Jira spaces free of test volume and allows test-specific behaviour such as folder hierarchies and per-step results. The trade-off is reach: Jira’s own search, JQL and work item permissions do not apply to test cases in the way they do to stories, so reporting on tests goes through Zephyr’s reports, gadgets and API.

A test cycle groups the test cases to run for a purpose, such as a sprint’s regression or a release candidate, and each execution of a test case records its result against that cycle. Test plans group cycles to track progress across a whole release or version. This mirrors how test teams already talk about work, and it is why Zephyr maps neatly onto a release calendar. Automated uploads create a new cycle each time, which can be named and placed in a folder from the upload request, so manual and automated results sit in the same structure and feed the same coverage reports.

Version control for test cases is enabled by default: editing a test case changes only its current version, older versions stay available, and the History tab compares them. Call to Test lets one test case include another as a step, even across several levels, and changes to the called steps flow to every caller. Parameters make those called modules adaptable, and a test data table turns one test case into many executions, one group of steps per row. Together these support large manual and hybrid suites without copy-and-paste drift, which is where many teams’ spreadsheets and wiki pages fail.

Zephyr does not run your automated tests; your CI does, then uploads the report. The Cloud REST API at api.zephyrscale.smartbear.com/v2, with regional hosts for the EU, Germany and Australia, accepts JUnit XML, Cucumber JSON or a custom JSON format and creates a test cycle from the results. Results map to test cases by a key in the method name or a Cucumber tag, then by fully qualified name, and with autoCreateTestCases set to true unmatched tests are created. Authentication is a bearer token generated per user under Zephyr API Access Tokens. The legacy names in the host, zephyrscale, and the Jenkins plugin ID, tm4j-automation, are leftovers of earlier branding.

Set up the folder structure before importing or writing many test cases, because it is how testers will find anything later. Organise by product area or capability rather than by sprint, and use test cycles, not folders, to represent sprints and releases. Agree which fields carry meaning, such as component, priority and status, and keep custom fields few. Write common sequences once as callable test cases and use Call to Test with parameters rather than copying steps. Link every test case to the stories it covers from the start, since coverage and traceability reports depend on those links. Decide early how automated tests will be identified, by key in the method name, annotation or Cucumber tag, so uploads update the right cases.

Zephyr matches JUnit results by parsing a test case key from the method name, then by the fully qualified method name, and only then creates new cases if autoCreateTestCases is true. The simplest durable convention for JUnit 5 is to put the key in the method name, with an underscore in place of the hyphen, such as SHOP_T12_goldMemberDiscount. For JUnit 4 suites, SmartBear’s zephyrscale-junit-integration library adds a @TestCase annotation and a Surefire listener that writes a result file for the custom upload format. Without a key, auto-created cases are matched by fully qualified name, so renaming a class or method creates a new case.

SmartBear does not publish an official GitHub Action for Zephyr, so call the API from a workflow step. Store the access token as a secret, run the upload with if: always() so failing runs are recorded, and name the test cycle after the branch and run so it can be found later. Surefire writes one XML file per test class, and the JUnit endpoint accepts either a single file or a zip of many, up to 10 MB, so zip the reports folder. Associate the cycle with a Jira version through jiraProjectVersion in the testCycle part if you want release-level reporting.

Zephyr supports BDD test cases whose scripts are Gherkin. The integration works in both directions. Download the feature files for a space as a zip from the automations/testcases endpoint, run them with Cucumber and its JSON plugin, then upload the JSON, zipped and under 2 MB, to the Cucumber endpoint. Scenarios are tied to test cases with a tag such as @TestCaseKey=SHOP-T21, and scenarios without one can be auto-created. Keep one source of truth: if scenarios are edited in Zephyr, regenerate the features on each run rather than editing them in Git. On Cucumber-JVM 8, remember that the json plugin needs a Jackson dependency.

Three products now share the name, and choosing the wrong one is expensive. Zephyr, the former Scale, is the full Jira app with its own library, versioning, reusable steps and reports, in Standard and Advanced editions that differ mainly in automation and AI capacity. Zephyr Essential, the former Squad, is lighter and models tests differently; SmartBear provides a beta upgrade path to Zephyr that requires a new licence, and its guide expects BDD data and execution history to become available during the first quarter of 2027. Zephyr Enterprise is a standalone test management product with Jira integration, still sold and released, with version 8.8.0 in August 2026. For a new Jira-centred team, evaluate Zephyr Standard first.