A manual test step fails, and the team has already filed the matching Jira bug. The remaining task is to connect that existing issue to the observation that exposed it. Filing another bug creates a second record to reconcile; linking only at the whole-test level can leave the affected step unclear.
In Zephyr Data Center, the documented step-level route is the step's cog menu followed by Search issues. Completion requires more than finding the issue: verify the bug on the affected step, its indication in the test-case list, and the corresponding entry in the bug's Impacted Test Executions section. This procedure is based on current SmartBear documentation and its official illustrations, not a test performed in a Jira tenant.
Use the documentation for the installed application, rather than assuming every product called Zephyr has the same controls. SmartBear's Data Center release 11.0, dated April 2, 2025, renamed Zephyr Scale to Zephyr. The workflow here follows that Zephyr DC documentation. It is not a Zephyr Essential DC, Zephyr Cloud, Xray, or generic Jira issue-linking recipe.
Version also affects the screen. Release 12.6, dated May 13, 2026, introduced a redesigned test player and retained an option to use the legacy player. The current Test Player guide documents the cog and Search issues route, while its embedded illustrations show an older interface. If your controls differ, confirm the installed version and its player documentation before acting. Do not substitute an action from a different edition because its name looks similar.
Before opening the association dialog, establish three identities:
You need access to the relevant testing records and the existing issue. Zephyr supports project-level action permissions and global application-access restrictions. If access or an action is missing, ask the administrator to verify the applicable app permissions, Jira visibility, and installed configuration. The Test Player guide does not provide a universal permission combination for this operation, so copying a permission checklist from another Zephyr edition is unsafe.
Work within the execution that contains the failure. A reusable test case describes the procedure; an execution records a particular attempt. The Test Player also offers test-case-level issue controls, but those are not the starting point when the goal is attribution to one manual execution step.
The documented cycle entry points can begin or continue testing. Opening the player does not mean you should start another attempt. In particular, do not use Start a New Test Execution merely to add a defect association: SmartBear documents that action as archiving previous test data and starting testing from scratch.
Read the failed step's recorded observation before choosing the bug. If several attempts exist, the same case name alone is insufficient. Use the execution details your installation exposes and the team's retained build, environment, and attempt references to avoid attaching the issue to a different run.
SmartBear's current guide names Search issues and shows it on the step menu, but it does not document the existing-issue dialog's detailed field names or final confirmation-button label. Follow the dialog presented by your version rather than expecting a particular Search, Add, or Link button from an unrelated tutorial. If you cannot identify the existing-issue action confidently, stop and check the matching documentation or ask the administrator.
A matching summary is a prompt to investigate, not sufficient evidence of the same defect. Compare the behavior, affected context, and issue key before completing the association. Keep any observation or screenshot shared with colleagues within your team's access and data-handling rules.
Return to the execution step after completing the dialog. SmartBear documents linked defects in both the test-case list and the step, with a corresponding link on the defect in Impacted Test Executions. Check those locations against the same bug and execution context, rather than treating a success message or count badge as the entire verification.
Scope | Action | Verification |
|---|---|---|
Execution step | Associate the existing bug through the step menu | Exact bug key appears on the affected step |
Test-case list | Inspect the same case in the current cycle | Linked-defect indication matches the selected execution |
Jira bug | Inspect Impacted Test Executions | Linked entry leads to the intended test and execution context |
Start with the step: confirm the exact bug key appears against the intended step, not only elsewhere in the player. Then inspect the same case in the current cycle's list. A list indication helps locate linked defects, but it does not independently establish which step owns the association.
Next, open that same Jira bug and inspect Impacted Test Executions. SmartBear's official bug-side illustration places this section inside Traceability. Locate the relevant linked test/execution entry and follow the available link to compare its execution details with the cycle, case, and attempt you intended. Do not assume the panel displays every context field in a fixed set of columns.
The reverse check catches a different class of mistake: the right bug can be associated with the wrong execution. A recognizable test name on the bug is useful, but the intended failed attempt must still be recoverable. A link to another run does not satisfy this procedure.
Consider an illustrative, unexecuted example. The already-filed bug QAX-42 describes “Approval returns an error” and has status To Do. Cycle QAX-C7 contains case QAX-T12. The team calls the relevant execution “Attempt A,” on build 701 in QA-EU; that is a local explanatory reference, not a claimed Zephyr field or generated execution ID.
Step 2 expects “Order approval succeeds once.” Its recorded actual behavior is “Approval returns an error,” with result Fail. Before the proposed association, QAX-42 is absent from this step. The planned after-state is the same QAX-42 attached to step 2 of the same Attempt A, with consistent case-list and bug-side execution references. In this example, the step remains Fail and the bug remains To Do. These are declared scenario conditions, not observed Jira results.
The association identifies where an existing defect was encountered. It is scoped to that execution step; it should not be described as editing the reusable design step or establishing a permanent link across every future execution. The cited workflow also does not establish automatic Jira status transitions, automatic passing results, or retroactive backfilling of other attempts.
When a fix is ready, confirmation testing needs its own appropriate execution evidence. Preserve the original failed observation and distinguish it from any later result. A closed bug does not itself prove that the corrected build passed the step, and an old defect association should not be used alone to infer the outcome of a newer attempt. The broader Jira requirements traceability guide explains how case, run, result, and defect identities support that separation.
If the expected bug does not appear in search, first recheck its exact identity and whether you can open the intended issue. Ask the administrator to verify the relevant visibility, application access, action permission, and configuration. Absence from the dialog does not establish that the issue does not exist, and creating a replacement bug is not a visibility fix.
If the case list indicates a defect but the affected step does not show it, inspect the selected case, attempt, and step again. A whole-case association is not proof of step-level attribution. Do not add another whole-case link as a substitute for finding where the original association was saved.
If the bug lacks the expected Impacted Test Executions entry or you cannot find its panel, retain the exact bug key and execution context for investigation. Confirm the installed edition, interface, and access with the administrator. A Cloud-specific instruction to open an app panel is not evidence of the required control in Data Center.
Treat stale counts separately from missing saved links. SmartBear's 12.11 release notes, dated September 10, 2026, describe a fix for a Test Execution count badge that failed to update after a Jira issue was linked to a test step. That documented defect is a reason to check the installed version and the actual linked records; it does not diagnose every missing indication. Do not assume an indexing delay, prescribe a reindex, or repeat the association solely because a badge looks unchanged.
Finish when another authorized tester can recover the same existing bug from the affected step and recover the intended execution from the bug. If either direction remains uncertain, preserve what you observed and resolve that uncertainty before treating the association as verified.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
