Zephyr Scale
Lightweight test management inside Jira. Perfect for agile teams that want test cases linked to stories without leaving Jira.
Overview
Zephyr Scale (formerly TM4J) is a test management app for Jira created by SmartBear. Unlike standalone tools like TestRail, Zephyr Scale lives entirely inside Jira, providing test case management, test execution, and reporting within the Jira interface. This eliminates context switching and ensures test activities are fully integrated with agile workflows.
Zephyr Scale is the lightweight alternative to Xray for teams that want test management in Jira without the complexity of a full ALM integration.
What it's used for
Zephyr Scale is ideal when:
- Jira is already the hub: No separate tool to learn or maintain.
- Agile test management: Link test cases to stories, epics, and sprints natively.
- Lightweight approach: Simpler than Xray or qTest for small-to-medium teams.
- BDD support: Import and manage Cucumber/Gherkin feature files.
Pros & Cons
Pros
- Native Jira integration — no context switching
- Simple and intuitive for Jira users
- Good BDD support with Cucumber integration
- Affordable pricing for small teams
- Strong automation integration with CI tools
Cons
- Jira-only — cannot be used without Jira
- Less powerful than TestRail for large test suites
- Reporting is basic compared to dedicated tools
- Can slow down Jira instance with large test data
- SmartBear support can be slow
Platforms & Integrations
Zephyr Scale is a Jira app available for Jira Cloud and Jira Data Centre. It requires an active Jira subscription.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Jira Cloud | From $3.50/user/mo | Full features, cloud hosting, SmartBear support |
| Jira Data Centre | Custom | Self-hosted, perpetual licence, annual maintenance |
NZ Context
Zephyr Scale is popular among NZ agile teams that want lightweight test management without leaving Jira. It is a common starting point for teams transitioning from spreadsheets to structured test management. For NZ Jira users, Zephyr Scale is often the first test management plugin they try.
Alternatives
- Xray (Jira) — More powerful Jira test management with better reporting.
- TestRail — Standalone tool with richer test management features.
- QMetry — Another Jira test management app with automation focus.
See the full test management tool comparison for a side-by-side breakdown of pricing, integrations, and NZ fit.
When to choose Zephyr
A quick decision guide for NZ teams evaluating test management options.
| Choose Zephyr when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team already lives in Jira and switching context is genuinely painful | You need rich cross-project reporting or a test plan hierarchy deeper than three levels — use TestRail instead | Playwright or Cypress for automated execution; results publish back via the Zephyr Scale REST API |
| You have fewer than ~50 testers and test management is not the bottleneck | Your organisation is leaving Jira or running multiple ALM tools — standalone TestRail or qTest travels better | Confluence for test strategy documents and retrospective write-ups; links stay live inside Jira |
| Your BDD workflow uses Cucumber or Gherkin and you want feature files versioned alongside Jira stories | You need deep requirement traceability with sign-off workflows for regulated industries — Xray handles this more completely | GitHub Actions or Bamboo for CI gating; the Zephyr Scale JUnit XML publisher integrates in minutes |
| You are migrating off spreadsheets and want the lowest-friction first step for an agile team | Jira is already sluggish — adding Zephyr Scale with thousands of test cases will make performance worse, not better | Allure Report for richer HTML test dashboards when stakeholders want something beyond Zephyr's built-in charts |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were joining a mid-size Jira-native agile team at CloudBooks — say, a squad running two-week sprints on the payroll platform — where testers are writing test cases in Google Sheets and then copy-pasting pass/fail results back into Jira tickets
I would…
Propose Zephyr Scale as the migration path, not TestRail. The squad is already in Jira all day; adding a separate SaaS tool creates a login problem and a synchronisation problem simultaneously. I would spend the first week importing the existing spreadsheet test cases via CSV, link each to the relevant story, and run one sprint using Zephyr test cycles to build muscle memory before pushing for CI integration. One tool, one login, one source of truth.
If…
I were a lead QA at TechServNZ managing test assurance across multiple client programmes — each with its own Jira project, different stakeholder reporting requirements, and a mix of manual and automated test coverage — and the account director asked for a single test management platform recommendation
I would…
Recommend against Zephyr Scale here and push for TestRail instead. The multi-project, cross-client reporting requirement is exactly where Zephyr Scale shows its limits — you end up exporting CSVs and stitching together dashboards manually. TestRail's shared test case repository and custom cross-project reports are worth the context-switch cost at TechServNZ's scale. Zephyr Scale is a great tool for one team; TestRail is a better tool for an organisation managing many teams.
If…
I were a tester at CityTransit on a squad that had been using Zephyr Scale for 18 months, and the team was complaining that Jira was noticeably slower and that test cycle searches were timing out on large test runs
I would…
Treat this as a data hygiene problem first, not a tool problem. Archive completed test cycles older than six months, remove stale test cases that were never linked to a story, and check whether SmartBear's recommended Jira instance sizing applies to your Data Centre plan. If performance is still degraded after a cleanup sprint, that is the honest moment to raise a migration conversation to Xray — which has a better internal data model for large test volumes — rather than tolerating slow tooling indefinitely.
The bottom line: Zephyr Scale earns its place when Jira is genuinely the centre of gravity for your team. The moment your reporting requirements or team size outgrow what one Jira app can deliver, the tool is working against you — and the honest call is to name that early rather than accumulate workarounds.
Interview questions
Questions you are likely to get if you list Zephyr Scale on your CV — with what interviewers are really testing for.
What is the difference between a test case, a test cycle, and a test plan in Zephyr Scale?
What they’re really testing: Whether you understand Zephyr Scale’s data model or have just clicked through the UI without knowing how the layers relate.
Strong answer covers: A test case is the reusable specification; a test cycle is a time-boxed execution run (e.g., Sprint 12 regression); a test plan groups related cycles for release reporting. Mention that NZ agile teams often skip test plans for smaller releases and run cycles directly against a version.
When would you choose Zephyr Scale over Xray for a Jira-based team?
What they’re really testing: Whether you can articulate real trade-offs rather than just saying “both are good.”
Strong answer covers: Zephyr Scale wins on simplicity and onboarding speed for teams under ~50 testers where test management is not the bottleneck. Xray wins when you need deep requirement traceability, formal sign-off workflows, or regulated-industry audit trails — common in NZ financial services (e.g., Harbour Bank, Pacific Bank). Name the decision point: if stakeholders ask for a test coverage matrix mapped to requirements, Xray handles that natively; Zephyr Scale requires manual CSV exports.
You’re joining a squad at TeleNZ that has been using Zephyr Scale for two years. The team says Jira is getting noticeably slower and test cycle searches are timing out. How do you approach this?
What they’re really testing: Whether you jump straight to “replace the tool” or diagnose before recommending.
Strong answer covers: Start with data hygiene — archive test cycles older than six months, remove test cases never linked to a story, and review SmartBear’s Jira Data Centre sizing recommendations. Measure Jira performance before and after the cleanup sprint. Only if performance remains degraded after cleanup do you open a migration conversation (likely to Xray, which has a better internal data model for large volumes). Frame it as a diagnosis problem, not a tool problem.
Your automated Playwright tests publish results to Zephyr Scale via the REST API in your CI pipeline. Tests pass locally but the CI run shows them as “Not Executed” in Zephyr Scale. How do you debug this?
What they’re really testing: Whether you understand the Zephyr Scale REST API integration end-to-end, not just that it exists.
Strong answer covers: Check the CI step output for HTTP response codes from the Zephyr Scale API — a 401 means the API token is not passed correctly in CI environment variables; a 400 often means the test case key or cycle ID in the payload doesn’t match what exists in Jira. Verify the JUnit XML format matches SmartBear’s expected schema. Confirm the test cycle was created before the publish step runs, not after. Run the API call manually with curl in the CI environment to isolate whether the issue is auth, payload, or timing.
How would you structure Zephyr Scale for a team that runs both manual regression and automated smoke tests across three environments — dev, staging, and production?
What they’re really testing: Whether you can design a Zephyr Scale structure that scales without becoming a maintenance burden.
Strong answer covers: Maintain one canonical test case library and create separate test cycles per environment per release (e.g., “Sprint 15 — Staging Smoke” vs “Sprint 15 — Prod Regression”). Use Zephyr Scale’s custom fields to tag test cases as Manual or Automated so filters stay clean. For automated results, push via the REST API into environment-specific cycles rather than a single shared cycle — this way the staging failure rate doesn’t pollute your production sign-off dashboard. Name this as a pattern used by NZ teams at CloudBooks or ListRight where environment isolation in reporting is non-negotiable before a release sign-off.