A developer marks a bug fixed, but the test environment may still contain the old build, different feature flags, or data that no longer triggers the failure. Moving the Jira issue to Closed at that point records a decision without establishing what was verified.
Bug fix verification starts with a narrower question: does the original failure still occur on the delivered correction under the conditions that exposed it? Answer that question with a new, traceable test result. Then assess nearby regression risk and choose the Jira transition that matches the evidence. Keep the original failure available throughout.
The workflow below uses Jira Cloud as its starting point. Your project may use different status names, permissions, or workflow editors. Treat labels such as Ready for Retest, Reopened, Resolved, and Closed as local workflow choices, not a mandatory sequence built into every Jira project.
A useful fix handoff identifies the correction and the conditions in which it should work. A comment saying “fixed in the next release” is insufficient when several builds, services, or configuration changes could affect the reproducer. Before execution, establish a testable comparison:
If the corrected build is unavailable or a dependency prevents execution, record the retest as blocked and assign the prerequisite an owner. Do not begin a supposedly valid verification run on an unknown artifact to keep the queue moving.
For an intermittent defect, also recover the triggering conditions: timing, concurrency, input sequence, load, or external-service response. Agree on a meaningful observation window or repetition plan based on the failure and its risk. A single attempt that does not encounter the trigger provides weak evidence about whether the correction works.
Preserve the original failed execution and create a separate retest attempt. The reusable test case describes how to check behavior; an execution records what happened on a particular occasion. Changing the case's latest status from Fail to Pass can erase the comparison if that field is the only result record.
Use the execution-history mechanism in your installed test management app, or an agreed Jira comment and attachment convention when no such mechanism is available. Keep the original failure linked to the defect and connect the new attempt to both. Record the case version actually used, especially if the steps or acceptance criteria changed after the defect was reported.
The new result should let another person reconstruct the test without guessing:
Record observations separately from explanations. “The second submission returned the existing order identifier” is an observation. “The idempotency change caused that response” is an inference unless additional evidence establishes the mechanism. A screenshot of a success message may be inadequate if the reported defect concerns a duplicate database record or a second payment downstream.
For teams using Sherlock Test Management, its documented baseline and run model can help preserve the case version behind a result: a finished run remains attached to the baseline version it executed, while proposed case changes require human approval. Testers record outcomes in the app's Runner or supported Jira panels. These are app-provided capabilities, not evidence that native Jira executes the application test or automatically reopens the bug. The Sherlock product workflow describes this separation between approved coverage and release-specific results.
Keep sensitive data out of broadly visible attachments. Retain useful identifiers and sanitized evidence in locations the intended reviewers can access. An inaccessible log link cannot support a handoff, even when the person who ran the test remembers what it showed.
A retest outcome and a Jira status answer different questions. The outcome describes the execution; the status routes the work. Use the following decision model without assuming that every label exists as a native Jira field or an app result option.
Retest Outcome | What the Evidence Supports | Next Action |
|---|---|---|
Pass | The expected behavior was observed on the identified corrected build under the recorded conditions. | Record the passing attempt, assess required regression checks, and request or perform the authorized completion transition. |
Fail | The original defect remains observable, or the correction does not meet the agreed expectation. | Preserve the new failure and return the bug to the appropriate investigation or rework state. |
Blocked | A missing prerequisite prevented a meaningful verification. | Name the blocker and owner, retain any partial observations, and schedule another attempt after the prerequisite is restored. |
Cannot reproduce | The reported failure was not observed, but the available conditions or evidence do not establish a verified fix. | Investigate missing triggers or information and make an explicit triage decision rather than claiming a passing fix verification. |
Cannot reproduce requires judgment. If the original reproducer is complete, the corrected artifact is verified, and the expected result is observed, the attempt can support a pass within that scope. If the account, data, timing, or original failure conditions are unknown, absence of the symptom is inconclusive. Write down which situation applies.
Jira can also have a configured resolution named Cannot reproduce. That is a defect disposition, not a substitute for a passing execution. If the team chooses it, retain the attempted conditions and the reason for the triage decision. Do not report that the delivered correction passed a test that could not meaningfully be performed.
Even a valid pass has limits. If the build, configuration, and data all changed between attempts, the result shows behavior under the new conditions; it does not isolate the cause of improvement. Record those differences so a reviewer can decide whether a controlled comparison or further investigation is warranted.
ISTQB distinguishes confirmation testing, which checks that the original defect was fixed, from regression testing, which checks for adverse consequences of a change. Rerunning the original failure addresses confirmation. It does not establish that neighboring behavior remains correct.
Select regression scope through impact analysis with the developer or relevant technical owner. For a duplicate-order correction, nearby risks could include retry handling, repeated requests with the same identifier, genuinely separate orders, and payment or inventory side effects. A fix that prevents duplicates by rejecting every second request could pass one narrow reproducer while breaking a legitimate purchase.
Choose checks at the layers that expose those risks. Existing component tests may cover identifier handling; integration checks may cover persistence and downstream messages; a user-facing check may cover the final checkout result. These are test-design choices, not claims that Jira or a particular app supplies an execution integration.
Record which checks ran against which artifact, what failed or remained blocked, and what was excluded with a reason. Escalate wider impact when the correction changes shared behavior or a critical dependency. A small, justified regression scope can support a narrow fix decision, but it should not be presented as full release certification.
Jira status describes a position in the workflow. Resolution describes why work is considered resolved. In Jira Cloud, a populated Resolution can cause Jira to treat an issue as resolved even when its status looks active. Conversely, moving to a terminal-looking status without the appropriate Resolution can produce reporting inconsistencies.
The displayed value Unresolved represents an empty Resolution field. Do not create or select a literal resolution named Unresolved or None as a substitute for clearing it: that is still a populated value. This distinction becomes especially important when a failed fix returns to active work.
Add the new attempt and explain how it relates to the original failure before using the locally approved return transition. If the same defect persists, keep its history together. If testing reveals independent behavior, discuss whether a separate linked defect is appropriate rather than expanding the original report until its acceptance criteria become unclear.
After the transition and any related automation settle, verify the resulting status, assignment, and Resolution. A reopened active bug should have an empty Resolution under the team's lifecycle policy. Do not assume that selecting a transition called Reopen clears it. If the value remains set, provide the evidence to the workflow administrator instead of repeatedly toggling statuses.
In company-managed projects, administrators can configure Resolution setting on completion and clearing on reopening through the applicable workflow actions or post functions. Atlassian's current documentation includes different editor terminology, so confirm the controls available in the actual workflow rather than applying one screenshot's click path everywhere.
Close or complete the bug when the agreed confirmation and required regression checks support that decision, and outstanding risk has an explicit disposition. Use the configured transition and a resolution appropriate to the outcome. Duplicate, Won't Do, and Cannot reproduce decisions should not be described as verified corrections.
Check access before the handoff. In company-managed Jira Cloud, transition, resolve, and close permissions are distinct concepts, and the workflow may impose additional restrictions. Team-managed projects use their own role and access model, with transition rules that can restrict movement. Being able to comment on a bug does not establish permission to close it or edit workflow configuration.
Do not transfer company-managed Resolution-screen instructions directly to team-managed projects. Atlassian documents different Resolution handling and a team-managed scenario without manual field controls. Ask the administrator to inspect the actual configuration, existing automation, and completion/reopen behavior on a safe representative item. Do not add a second rule on the assumption that no visible field means nothing is managing Resolution.
Review side effects before choosing a transition: assignment changes, required fields, notifications, and related automation may be intentional parts of the workflow. Jira Service Management Cloud has specific notification behavior tied to Resolution and transition ordering. A workflow repair therefore needs administrator review, not an improvised status change to make a report look correct.
The following identifiers and results are invented to demonstrate the record structure. They are not an observed customer case or an actual Jira, test runner, CI, or release action.
Original failure: Bug PAY-417 links to case CHECKOUT-12 revision 3 and execution RUN-81. On build checkout-rc17, retrying the same checkout request with the same idempotency identifier creates a second order. The original request trace and both order identifiers remain attached to that failed execution.
The developer's handoff identifies checkout-rc18 and the affected request-handling path. The tester verifies the deployed build, restores the relevant flag and account conditions, and prepares equivalent clean data. The first retest, RUN-84, is blocked because the payment sandbox is unavailable. Its record names the environment owner; no passing result or completion decision is recorded.
After the sandbox is restored, RUN-85 repeats the original steps against checkout-rc18. The retry returns the existing order identifier, and the retained request trace and downstream checks show no additional order or payment for that attempt. The result is Pass for the recorded reproducer. RUN-81 stays failed, and RUN-84 stays blocked; neither is overwritten.
The team also records targeted checks for a genuinely new order, retry behavior, and the relevant downstream side effects. The authorized owner reviews those results and any exclusions before selecting the configured completion transition. The final record identifies RUN-85, the regression evidence, the resulting status and Resolution, and the scope of the decision. It does not claim that every checkout risk or the entire release was tested.
Before moving your next bug, ask whether another reviewer can identify the corrected artifact, compare the preserved failure with the new result, and understand the remaining uncertainty. If any of those answers depends on someone's memory, strengthen the evidence or assign the missing prerequisite before changing the workflow state.
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.
