Managing Runs

Day-to-day operations for active and completed test runs — editing metadata, assigning cases to team members, closing completed runs (which freezes a sign-off snapshot), reviewing or reopening a closed run, re-running or duplicating a run's case set, and deleting runs you no longer need.

Editing a run

To edit a run, open the terminal breadcrumb menu (TR-… ▾ ⋯) and select Edit run…, or edit fields inline on the Overview tab About card (lifecycle state, cycle, environment).

The Edit run modal handles a run’s metadata only. You can change:

• Title — rename the run
• Cycle — reassign to a different sprint, release, or iteration
• Environment — change the platform combination
• Tags — add or remove labels

Click Save to apply changes. Editing a run requires the Create test runs permission.

Tags can only be changed here. Unlike the lifecycle state, cycle, and environment, tags have no inline row on the About card, so the Edit run modal is the only place to set them.

Three things the modal deliberately does not cover, and where they live instead:

• Lifecycle state — the State picker on the Overview tab’s About card.
• Notes — the Notes card on the Overview tab, which autosaves as you leave the field.
• Which cases are in the run — Edit cases… in the breadcrumb ··· menu, which reopens the Run Composer against this run.

Assigning tests

Assign cases directly on the Cases tab — use the per-row assignee picker or multi-select rows and bulk-assign from the bulk bar. Assigned cases show the user’s avatar on the row. Assigning requires the Execute tests permission.

Closing a run

Closing marks a run as complete. There is a single Close run… action and it lives only in the crumb ··· menu (there is no title-row Close button and no separate “Mark completed”). Before the run closes, TestOrchestrator checks for potential issues.

1. Choose Close run… from the crumb ··· menu on the run detail page.
2. The close guard checks whether any cases have a failed result with no linked external issue (defect). If any are found, a warning dialog appears.
3. The dialog lists the affected cases and offers two options:
   • Review results — return to the run to link defects or re-test.
   • Close anyway — proceed with closing despite unlinked failures.
4. If no issues are found, or you choose Close anyway, the run is closed and a sign-off snapshot is frozen in the same step.

Closing requires the Create test runs permission — the crumb ··· menu’s run actions only appear for users who hold it.

Why the close guard exists. The guard ensures traceability — every failure should be linked to a defect so the team can track resolution. Closing a run with unlinked failures is allowed but flagged as a conscious decision.

What closing means

• The run moves to a closed lifecycle state and drops to the Closed scope on the runs list (the default Active scope hides it).
• A sign-off snapshot is frozen as part of the close — the run and every case exactly as they stood at that moment.
• Results can no longer be recorded — the Cases tab becomes read-only and the header shows a read-only banner. Rows lose their inline result strip, assignee picker, and selection checkbox; the panel and focus runner show the recorded result as a static row instead of an entry control; and the per-case runner replaces its Record-result composer with a closed-run banner, keeping the recorded per-step marks visible as labels. The rail’s Assignee row explains itself — Run is closed — reopen to reassign.
• All existing data (results, comments, attachments, issue links) remains fully accessible.
• The run continues to appear in summary statistics and activity timelines, and the close is written to the Activity feed as a lifecycle event.

Closing is reversible — but it is on the record. A closed run can be reopened, and the sign-off snapshot taken at close is kept forever regardless. If you would rather leave the closed run untouched, use Re-run failed & blocked or Duplicate run to carry the case set into a fresh run instead.

Sign-off snapshots

Closing a run freezes an immutable sign-off snapshot — the audit record of what was signed off. It is written as part of the close itself, so a run is never closed without one.

The snapshot is self-contained: every title, folder path, field label, option label, and executor name is copied into it rather than looked up later. Renaming a test case, deleting a folder, retiring a dropdown option, or deactivating a user afterwards cannot change what a past sign-off says.

Each snapshot holds:

• Run metadata as it stood at close — environment, cycle, owner, and tags.
• Outcome counts — passed, failed, blocked, and total, plus the exact per-status breakdown with each status’s frozen label and colour. The roll-up follows your admin-configured status semantics, so tenant-defined statuses land in the right bucket.
• Every case’s frozen definition — title, folder, template, custom-field values, and steps with their sub-field cells.
• Every case’s recorded outcome — the latest result with its note, linked defect keys, and per-step marks, plus the full result history when the case was retested.
• The result-field values recorded with each result — the build, the device, the trace id, whatever your result fields capture, frozen exactly as they were entered. They render in the viewer as chips beneath the result, with long-form TEXT values as read-only prose. Frozen values are shown verbatim: retiring a dropdown option or renaming a field afterwards cannot rewrite what the sign-off says.
• The case attachments as they stood at close — a Case attachments at close block naming each file the test case carried, with its size and upload time.

Case attachments are recorded, not re-openable. That block lists what was attached; the entries are deliberately inert. A snapshot never freezes a download link — links expire — and the file a name points at today may not be the file that was attached then, since a same-named re-upload would silently substitute itself. Naming what was there is an honest audit record; offering a link that might open something else is not. Evidence attached to a result is different: it is resolved live and does render as a thumbnail.

Older sign-offs are never back-filled. Result-field values and case attachments were added to the snapshot record after the earliest sign-offs were captured, and existing snapshots are deliberately left exactly as they were. So on a recent sign-off “no attachments listed” means the case genuinely had none, while on an older one it means that detail was never captured. Retro-fitting evidence into a past audit record is precisely what this record exists to prevent, so the gap is preserved rather than quietly filled in.

On a run that has ever been closed, a Sign-off snapshot card sits at the top of the Overview side rail with the closer, the time, and the headline counts. View details opens the read-only snapshot viewer, where each case expands to show its frozen field chips, defects, result timeline, and steps. The viewer has no edit affordance anywhere in it.

Every close is kept as a numbered revision. If a run is closed, reopened, and closed again, each sign-off is retained rather than replaced. The viewer then shows a revision bar (“#k of N”) with older/newer controls, and the Overview card reads View all N sign-offs.

Evidence is frozen by name and shown as a picture. A snapshot stores each attachment’s file name and identity, never a link — download links expire, and a dead link inside a years-old audit record is worse than none. When you open the viewer, those references are resolved to fresh, short-lived links on the spot, so evidence thumbnails render as real images and open full size in a lightbox (press Esc to close the preview without closing the snapshot). If a file has since been deleted, or its link cannot be resolved, that tile falls back to a hatched placeholder carrying the frozen file name — the audit record still tells you what was attached. Images embedded in a frozen result note or step note are resolved the same way.

Reopening a run

A closed run can be reopened when testing has to continue on the same run. Choose Reopen run from the crumb ··· menu, or click Reopen run on the closed-run banner in the header. Both need the Create test runs permission — without it, the closed banner explains the read-only state with no reopen button attached.

1. Choose Reopen run. A confirmation dialog appears, showing the preserved sign-off (who closed the run, when, and its passed/failed/blocked tally).
2. Confirm with Reopen run. Unlike most actions in the app, this one is not applied optimistically — the button shows Reopening… and waits for the server, because it is changing an audit record.
3. The run leaves its closed state, results become editable again, and the Cases tab comes out of read-only mode.

• The snapshot survives. Reopening never edits or deletes a sign-off. The Overview card stays, now labelled preserved · reopened since.
• The reopen is audited. It is appended to the run’s Activity feed as a lifecycle event attributed to you.
• Closing again adds a revision. The next close freezes a fresh snapshot alongside the earlier one rather than overwriting it.

If someone else reopened the run first, the action reports that the run is already open and nothing changes.

Re-run and duplicate

The crumb ··· menu offers two ways to carry a run's case set forward into a new run — both available whether the source run is open or closed:

• Re-run failed & blocked — creates a new run containing only cases whose latest result is Failed or Blocked.
• Duplicate run — creates a new run with the same case selection.

Deleting a run

Delete from the breadcrumb menu or bulk-delete multiple runs from the list. A confirmation dialog appears before permanent deletion.

Deletion is permanent. Deleting a run removes the run and all its recorded results, comments, attachments, and issue links. This action cannot be undone.

Permissions reference

For a complete permissions overview, see Test Runs Overview.