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 (the ··· beside the run’s name in the breadcrumb) and select Edit run…. It is the menu’s only edit item, and it is offered only while the run is open.

Edit run… leaves the run page for the test case repository and opens the Run Composer in edit mode. One band edits the whole run:

• Name — rename the run
• Cycle — reassign to a different sprint, release, or iteration
• Env — change the platform combination
• State — change the run’s workflow state; it is sent only if you change it
• Tags — pick any number of run tags; the pill opens on the run’s current tags
• Cases — tick and untick cases in the list below to change which cases the run contains

The band names the run you are editing, for example Editing TR-12 · Checkout Regression. Click Save changes to apply everything at once. You return to the run page with the changes already in place, including the run’s tags in the header. Cancel leaves without saving and discards your edits. Unticking cases that already have results keeps those results — see Creating a Run. Editing a run requires the Create test runs permission.

Quick edits stay on the run page. The title is editable inline in the header, and the workflow state, cycle, and environment have inline pickers on the Overview tab’s About card. Tags have no inline control there: change them with Edit run…, or for several runs at once with Add label… and Remove label… in the run list’s bulk bar. The state of several runs can be set at once with Set state… there too.

Notes are not part of the composer. They live on the Notes card on the Overview tab, which autosaves as you leave the field.

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. With Create test runs you assign anyone; with Execute tests alone you pick up any open case and hand back only your own; only people who can execute tests can be assigned. See Who can assign.

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 drops to the Closed scope on the runs list (the default Active scope hides it). If the When run is closed automation rule is on, the run also moves to that rule’s target workflow state; with the rule off, closing marks the run closed and leaves its state where it was. See Workflow Automation.
• 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 close event.

The State picker cannot close a run. A workflow state is a label saying where the run stands; closing is an act, and Close run is the only thing that performs it. Moving a run onto the state the When run is closed rule points at — even if that is the workflow’s default state — changes the label and nothing else: the run stays open, stays editable and still takes results. The same goes for the run composer’s State pill and for Set state… in the run list. Nothing else in the product closes a run either.

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. A value in a field the case’s template does not carry is frozen as empty, as the run’s rows showed it.
• 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 reopen event attributed to you.
• Reopening moves the run off the closed state, but not back to the one it had. If the close moved the run onto the When run is closed rule’s target state, reopening takes it off that state — it would otherwise sit in the state the product reads as finished. It lands on the When first result added to run target if the run has results, and on the workflow’s default if it has none. Whatever state the run was in before the close is not remembered; set it by hand if you want it back.
• 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 one run from the breadcrumb menu, or several from the list: select them, open Actions (A) and choose Delete N runs… (see Bulk selection). Either way a confirmation dialog appears first — the bulk one always does, whatever the count, and says how many recorded results go with the runs. There is no Undo.

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.