Create a new Test Run when you repeat a test after a fix. This keeps the original failure and the retest as separate execution records. Use the existing run when you are continuing or correcting the same execution.
Choose how to record the retest
What you are doing | Recommended action |
Finish an execution you already started | Open that Test Run and continue recording its steps. |
Repeat a case after a fix | Create a New Test Run in the intended work item, Test Folder, or Test Plan context. |
Run another testing round in a plan | Create a New Iteration, then execute the cases needed for that round. |
Record only an overall outcome using Quick Test | Clear Update Last Test Run, when shown, to create a separate execution. |
A separate run preserves a distinct execution record. It is still a record users with the appropriate permissions can update; it is not an immutable archive.
1. Find the failure in the correct context
Open the Test Case list for the Jira work item, Test Folder, or Test Plan you are retesting. In a plan, confirm the iteration and, for an Advanced Test Plan, the requirement.
Use Filters + → More + → Result to show the failed outcomes you want to investigate. Include the relevant in-progress result if you also need unfinished failures.
Open the case’s Test Runs control and inspect the relevant execution. Review its version, step results, Actual Result, evidence, and linked work items.
Confirm the fix or changed condition you intend to test, and prepare the required test data.
The Result filter reflects the applicable result in the current view. It does not list every historical run that has ever failed. See Filter Test Cases by Result.
2. Create a separate execution
Return to the case list in the intended work item, folder, or plan. Start here rather than from an execution embedded in a defect when you want a new record.
Confirm the linked Test Case version and the Environment, Version, or Sprint values required for this retest. Complete any mandatory Run Setup values.
Select the case’s Execute control, then choose New Test Run. Perform the test again and record the observed results.
Enter a useful Actual Result and attach fresh evidence where needed. Link the relevant Jira work item so reviewers can follow the problem and the retest.
Confirm that the new run has its own Test Run key. Keep the original failed run available for comparison.
If the test instructions changed, review the linked version before executing. Avoid changing the earlier run’s script or results merely to make it match the new execution.
Using Quick Test for the retest
Quick Test can record an overall outcome without stepping through the script. Where the menu shows Update Last Test Run, review it before selecting a result.
Open the case’s execution menu.
Clear Update Last Test Run to create a new execution instead of updating the displayed run.
Select the outcome you actually observed, then verify the new record in Test Runs.
Vansah remembers this Quick Test preference in the browser. Check it whenever you switch between correcting an existing run and recording a separate retest. For step-by-step evidence, use New Test Run and record the individual logs.
Retesting in a Test Plan
Use a New Iteration when you want the next testing round to have separate execution results within the same plan. Use a new run in the current iteration when the retest belongs to that existing round.
Review the failures in the earlier iteration and note the cases you need to retest.
If starting another round, select New Iteration, then review its dates, assignments, properties, and case scope.
Execute the intended cases and record the new results. Do not assume a new iteration automatically contains only failed cases.
Switch between iterations to compare the earlier and later evidence.
An iteration’s Result filter shows results for that selected round. A new round may initially show Untested cases, so use the earlier iteration to identify the failures you are following up. Some plan configuration and Run Setup changes apply across iterations; review warnings before changing them.
3. Compare the original run and the retest
Check | What to confirm |
Execution context | Both records refer to the intended case, requirement, and plan iteration. |
Test content | The case version and instructions explain what was tested in each run. |
Test conditions | The environment, application build or release context, and test data explain relevant differences. |
Evidence | Actual results, step outcomes, attachments, and linked work items support each conclusion. |
Completion | All required steps have been recorded; a result that is still In Progress needs further work. |
For example, the first checkout run records a failed payment confirmation and an error screenshot. A new run after the fix records successful confirmation with fresh evidence. Review both records to understand what changed.
A case can disappear from a Failed-filtered list after its current result changes. Clear the filter or open its Test Runs to find the earlier failure. See Understand and View Test Runs and Understand Test Logs.