Browsing & Filtering

The TEST RUNS tab is a single-pane workspace with a borderless toolbar and a cycle-grouped run list. Search, filter, and layout preferences apply instantly on the client. The scope you pick (All, Active or Closed) is part of the page address, so a copied link opens on the same scope for whoever you send it to.

Toolbar

The toolbar starts with the scope tabs, then (right-aligned):

• Search — filters runs by title, cycle name or reference (TR-12).
• Filter — opens a Linear-style fly-out with multi-select fields (keyboard shortcut f). Active selections appear as removable chips below the toolbar.
• Layout toggle — switch between Rows (the table, default) and Cards. It is the same segmented control the Explorations list uses for its layouts: once it has focus, ← / → switch layout.
• New run — opens the create-run composer (requires Create test runs permission).

Scope tabs

A strip of pill tabs at the start of the toolbar partitions the list by whether a run is still open, before any search or filter is applied:

Every tab shows how many runs it holds, All included — so while you are looking at Active you can also see how many closed runs are hidden. A tab with nothing in it shows no number rather than a 0. The counts are of the whole project; search and filters narrow the list inside the scope you picked.

The scope is kept in the page address as ?scope=all or ?scope=closed (Active, the default, needs nothing). Reloading, pasting the link, or using the browser’s Back and Forward all land on the scope the address names, and each scope change is its own step in the browser history.

When the scope you picked holds nothing, the list says so and names what it is hiding — for example No active runs — 3 closed — with a Show all runs link. No runs yet only appears when the project has none at all.

From the keyboard: Tab onto the strip, then ← / → move between scopes (wrapping at the ends) and Home / End jump to All / Closed.

Cycle groups

Runs are grouped under their assigned cycle. Each group header shows the cycle name and run count. Runs with no cycle appear under No cycle. Click a run row or card to open its detail page.

Run row anatomy

Bulk selection

Hover a row (or a card) and a checkbox appears at its start; once anything is selected every checkbox stays visible. Closed runs can be selected too.

• Click a checkbox to select or deselect one run.
• Shift-click a second checkbox to apply that click to every run between the two. Shift-clicking an unticked run selects the span; shift-clicking a ticked one deselects it.
• The checkbox on a cycle group’s header selects every run in that group, and clears the group when all of them are already selected. It shows a dash when only some are.

A bar appears at the bottom of the screen with three things on it:

• N selected, with a × that clears the selection. Esc clears it too, once no menu or dialog is open.
• Move to cycle — the one action on the bar itself. The menu lists No cycle first, which detaches the runs from whatever cycle they were in, then the project’s open cycles. Completed cycles are not offered as a destination, though runs already in one can still be moved out. Once there are more than four choices, a Search… box at the top narrows the list by cycle name as you type; the arrow keys and Enter pick from what is left.
• Actions — opens a command palette with everything else. Press A to open it from the keyboard (not while you are typing in a field, and not with ⌘, Ctrl or Alt held, so ⌘A still selects all). Esc inside the palette steps back one level, then closes it.

The palette groups its actions into four sections:

Each action is one cache write plus one queued mutation — the same optimistic pattern as single-row edits. Eight selected runs are one request, not eight.

Closed runs in a selection

A closed run can’t be edited until it is reopened, so the Edit actions and Close leave closed runs alone rather than failing on them. When a selection mixes the two, a note above the bar says so — 2 closed runs — edits skip them. — with a Select only the N active link, and the toast afterwards adds 2 closed runs skipped. Reopen, Re-run failed & blocked, Copy IDs, Export CSV and Delete all include closed runs.

Selections the view is hiding

A selection survives switching scope tab, searching and filtering. If some selected runs are no longer on screen, the note above the bar says 3 selected runs are hidden by this view — still included. They are: every action applies to the whole selection. The selection ends when you clear it (× or Esc) or delete the runs.

Who sees which actions

Actions you can’t take are left out of the bar and the palette, not greyed out.

• Move to cycle, the Edit actions and the Lifecycle actions need Create test runs — the same permission that lets you edit a run.
• Delete needs Delete test runs as well as Create test runs.
• Without Create test runs the bar is just the count, Actions and ×, and the palette offers Copy IDs and Export CSV with a note that editing these runs needs run edit access.

Undo

The result of each action appears as a toast just above the bar, and most carry an Undo that puts each run back to its own earlier value — four runs moved out of three different cycles go back to those three cycles. Once the toast has gone, a N bulk changes · reversible pill in the same place lists the bulk changes you have made, each with a Revert button. It works the way it does on Test Cases. The Undo appears once the server has accepted the change, and a change the server refused is never listed. If an Undo itself is refused, a Couldn’t undo toast says so and stays until you press Retry or close it. The list shows what the server holds, and the change stays in the pill so you can also Revert it from there; the toast goes away once the change is reverted either way.

Large selections

There is no cap on how many runs you can act on. The server takes 200 runs per request, so a selection larger than that is split into batches of 200 behind the scenes and sent for you. You still get one toast at the end, and edits still show on the rows the moment you act.

The split is not something you have to watch. Batching is a detail of how a large selection reaches the server: the toast at the end reads as a single action whether it took one request or five. The only place the batches surface is a partial receipt, when one of them fails.

A batch that fails does not take the rest down with it. The partial receipt below reports the count that landed and reverts only the rows that did not — so a 250-run move whose second batch is refused reads Moved 200 of 250 runs to Sprint 4 — 50 failed, and the 200 keep their new cycle. A whole batch lost this way is reported as a count without a reason, because the server never got to name one.

A long action — closing a couple of hundred runs, say — can outlast a single request. That is not treated as a failure: the same request is re-sent for up to about two minutes until the server answers, and the server applies it only once. Close, Reopen and Re-run show a pending toast (Closing 40 runs…) until then.

What the receipt tells you

Every action ends in one toast, in the dock just above the bar. A batch is not all-or-nothing, and the toast says so rather than rounding up to “done”. When everything lands you get a plain line — Moved 5 runs to Sprint 4, Set Staging on 8 runs, Added smoke to 3 runs, Assigned every case in 4 runs to Dana, Closed 3 runs, Created 2 re-runs, Deleted 2 runs — with its Undo where the action has one.

When part of the batch is refused you get a partial receipt in the error tone, naming the count and — when every refusal agrees on one reason — the reason itself: Moved 3 of 4 runs to Sprint 4 — 1 failed (closed), or Couldn’t delete 2 runs (no longer available). Only the runs the server named revert on screen; the rest keep their new value, so you never have to redo the part that worked.

“Unchanged” is not a failure. Moving four runs into a cycle three of them are already in is a clean success, not a partial one — the server reports one updated and three unchanged, and the receipt reads accordingly.

Search

The search field matches a run's title, its cycle name, and its reference. The search term is stored in the URL so the filtered view persists across reloads.

Searching by reference

Every run carries a reference that is unique within its project — TR-12. Typing any of these forms finds that run:

A reference is scoped to one project: TR-12 means “run 12 in the project you are looking at”. A different project has its own TR-12.

The reference is not the number in the run's web address. /test-runs/63 can be TR-12 — the address uses an internal record id, while the reference is the number assigned within the project. Quote the reference (TR-12) in tickets and chat; both keep working as links.

Filters

Click the filter button to open the fly-out. Each field is multi-select; selections combine with AND across fields and OR within a field.

Filters combine with AND logic. A run must match every active filter to appear. Within a multi-select filter, values combine with OR logic.