Zephyr organizes testing alongside Jira, connecting requirements, checks, executions, and discovered defects. This is useful when the team already discusses delivery in Jira and wants quality evidence in the same working context. The key question is "which release risks were tested, on which build, and with what result?" rather than simply how many tests exist. Accurate answers start with understanding the installed product and its data model.
Identify the edition and hosting model first
Zephyr encompasses different products and historical names, including Squad, Scale, and Enterprise; the current lineup also uses Essential, Standard, and Advanced. Storage models, interfaces, integrations, and migration paths have changed between them. Cloud versus Data Center also matters. An instruction to "create a Jira issue of type Test" is therefore not universal: one configuration stores tests that way, while another uses a separate Zephyr repository. Begin with the documentation for your installation.
Cases, cycles, and executions
A case describes a scenario and its expected result. A cycle groups checks around a shared objective: build smoke testing, release regression, or configuration certification. An execution records an observation for a case in a specific context. Avoid writing "passed" directly into the case title: the same scenario may fail on another build tomorrow. Planning, instructions, and result history serve different purposes even when they appear side by side.
Linking a check to a user story
Link the case to a requirement or Jira issue so readers understand the behavior being verified. A story such as "The customer applies a promo code" needs more than one positive case: expiration, applicability, and reuse restrictions also matter. A link establishes a relationship, rather than coverage quality. During review, examine the acceptance criteria and ask which observation would confirm each important point. Separately identify risks currently covered by exploratory sessions rather than formal cases.
A minimal repository structure
Start with understandable product areas, an agreed naming convention, and a few selection attributes. Avoid creating a folder for every sprint when the same scenarios will still be needed a year later. Describe preconditions, data, actions, and expected changes. Reuse common steps when updating them will not conceal differences between scenarios. If permissions and case versioning differ across editions, agree on an available review process rather than promising a nonexistent approval button.
Exercise: checking promo codes before release
The team is releasing a discount change. A Jira story specifies that SAVE10 provides 10% off eligible products, cannot be applied after expiration, and cannot reduce the total below the permitted value. A test catalog, controlled validity dates, and orders without real charges are available. The cycle aims to confirm these rules and the resilience of related cart operations.
- 1.Create or update cases for a valid, expired, and inapplicable promo code. Link them to the story to produce a visible map of the key rules.
- 2.Create a cycle for the required build and configuration. Record the environment, test codes, and cart preparation method so the tester can reproduce the initial state.
- 3.Execute the positive case: compare the original amount, discount, and total. Expect a calculation that follows rounding rules, beyond merely displaying a green message.
- 4.If the total is wrong, save the execution result and link the Jira defect to the specific observation. Include the data, expected amount, and actual calculation in the defect.
- 5.After the fix, retest on the new build and check related product combinations. The cycle outcome should make clear which results correspond to each change.
Retesting and historical context
Establish how your edition stores reruns and case versions. Before cloning a test after every failure simply to preserve the past, examine the built-in history. If a new cycle is needed, explicitly distinguish it from the previous one. When instructions change, identify the version used for earlier testing. Otherwise, today's corrected wording may imply that yesterday's result was obtained under the updated rules when different behavior was actually tested.
Coverage reports without false confidence
A requirements report is useful when links are complete and the correct context is selected: project, version, cycle, and environment. Clarify which results count as latest and how unexecuted checks are handled. With an incorrect filter, a green requirement may represent just one linked test passing or a result from a previous cycle. Manually verify several rows from story to case, execution, build, and actual attachments. This quickly exposes reporting errors.
Automation and CI integration
When uploading results, use the API and adapter for your particular Zephyr product. A Jira issue identifier and a repository case key may refer to different entities. Before integrating at scale, submit results for two tests, including one deliberate failure. Check matching, cycle, environment, and the defect link. Resubmitting after a network failure must not silently double the statistics. Keep integration secrets in CI and remove credentials and user data from reports.
Migrating between products
Case counts alone cannot verify a migration. Compare steps, versions, requirement links, attachments, cycles, results, and permissions. Official documentation for specific upgrade paths explicitly lists transfer limitations, including execution history and BDD data. A CSV of test descriptions is not a backup of the entire process. Select several complex examples for verification: a reusable scenario, a failed test with a defect, and a completed cycle. Retain access to original evidence until the migration is confirmed.
Common mistakes and useful outcomes
Problems arise when teams combine instructions for different Zephyr products, create cases without expected results, or read an overall percentage without a release filter. Another mistake is copying a Jira issue status into a test execution status without actually testing. Good QA work produces a clear cycle, meaningful relationships, and an auditable observation history. Zephyr then supports release decisions rather than adding another layer of manually updated reports.