Test runs

A test run is an execution session: you pick a set of test cases, snapshot them into the run, and record the outcome of each one. Runs live under a project — open the Runs entry in the project sidebar.

Creating a run

On the Runs screen, click New test run.
Fill in the Details section:
- Title (required) — pre-filled with a default of Test run YYYY/MM/DD (today’s date, e.g. Test run 2026/07/29), fully editable before creating the run.
- Description (optional).
- Environment — pick from the history of environments already used in this project, or type a new free-form value (e.g. Staging, v2-preview).
- Default assignee — the member assigned to every case in the run that has no per-case assignee. If left empty, the first person to open a case is assigned automatically.
- Milestone — visible but not yet functional (coming soon).
In the Test cases section, choose From repository (the only active source; From test plan is a coming-soon stub) and click Add cases to open the case-selection modal.
In the case-selection modal:
- Browse the suite tree on the left to filter the case table by suite.
- Use the search box and filter bar (Status, Priority, Tag) to narrow the list.
- Check the cases to include. Use Select all to check every case currently visible after search and filters.
- Optionally set a per-case assignee using the dropdown in the Assigned column. A per-case assignee overrides the run default for that case only.
- Click Add N cases (disabled until at least one case is checked) to return the selection to the run creation modal.
The selected cases appear grouped by suite in the Test cases section. Click × on any row to remove a case before creating the run. At least one case must remain — the Create button is disabled at zero cases.
Click Create. The run opens ready to execute.

BREAKING change (API): POST /api/v1/projects/:projectId/runs now requires caseUlids to be a non-empty array (minItems: 1). Requests with caseUlids: [] or without caseUlids return 422 validation_failed. If you were creating empty runs via the API and adding cases later via POST /runs/:runUlid/cases, update your workflow: include at least one case in the initial POST /runs request.

Assignee resolution order (per case): per-case assignee set in the case-selection modal → run default assignee → unassigned (null).

When a case is added to a run, its title and steps are snapshotted into the run. Editing the original case in the repository afterwards does not change any existing run — historical runs stay exactly as they were executed.

Creating a run from a repository selection

You can skip the case-selection modal entirely by starting from an existing selection in the Test repository:

Check one or more cases (or a whole suite band) using the bulk-selection checkboxes.
In the bulk-action bar, click Run.
The Runs screen opens with the new-run modal already open and your selected cases preselected in the Test cases section.
Add or remove cases as needed, fill in the run details, and click Create.

The repository selection itself is unaffected by Run — it stays as-is so you can start another bulk action afterward.

The runs list view

The Runs screen presents every run in the project as a table with eight columns:

Title — the run name plus the date it was started.
Environment — free-text label captured at creation time (e.g. Staging, Production). Runs without an environment show an em-dash (—).
Configurations — the run’s tagged configuration values (e.g. Chrome / Windows), joined by /. A run with no configurations shows an em-dash. Since the default run name is now date-based rather than combination-based (see “Creating a run” below), this column is what tells apart several runs created the same day. The same column appears, unchanged, on a test plan’s runs section and on a milestone’s runs tab.
Author — who triggered the run. For runs created from the web app, this is the user’s name and avatar. For runs created from the API (CI/CD), it is the API token’s name displayed with the key icon used elsewhere in the Activity feed. Legacy runs whose original author cannot be recovered show an em-dash.
Total time — the cumulative sum of the individual durations of every case that has been executed in the run so far.
Elapsed — the wall-clock interval between the first and last result registered on the run. For runs still in progress this value ticks every second so you can watch it advance live.
Status — the projected label (In progress / Passed / Failed) — see below.
Results — a stacked horizontal bar showing how the cases break down across the five per-case statuses (passed / failed / blocked / skipped / untested), with the executed/total count and pass rate below.

The filter bar above the table combines search, a permanent Status chip, and additional filters from Add filter:

Search filters by run name or environment substring (case-insensitive).
Status is an always-present chip (no ×, never offered in Add filter). Open its popover editor to check In progress, Passed, and/or Failed — combine them to show multiple projected statuses, or leave it empty.
Environment uses the environments already seen in this project. You can select more than one value.
Author filters to user-authored runs. Runs created by API tokens stay visible in the table but are not matched by a user author filter.
Default assignee filters by the run’s default assignee, including (empty) for runs without one.
Run custom fields — Add filter also lists this project’s filterable test_run custom fields (options, checkbox, and member picker; free-text and numeric fields are not filterable and never appear here). Each editor offers an (empty) choice for runs with no stored value for that field. Custom filters are evaluated against stored value rows only; a default shown on the run’s detail page does not satisfy a filter until a value is actually saved.

Active filters appear as removable chips and are reflected in the URL so you can share a filtered view. A N of M counter on the right reflects the filtered state, and Clear filters removes search and chips together.

Run status labels

Each run shows a single badge that reflects both whether execution is still open and the overall outcome:

In progress — the run is still open; you can keep marking cases.
Passed — the run is closed and every case outcome is passing (including skipped cases; untested-only closes still count as passed when there are no failures).
Failed — the run is closed and at least one case failed or was blocked.

The same badge appears on the runs list and in the execution view header.

Executing a run

The execution screen is a board grouped by suite: each suite collapses into a band with its own progress bar, aggregate duration, case count, and the snapshotted suite name. Cases without a suite live under a “Cases without suite” band. A search box at the top filters cases by title or short ID across every band.

A right-side summary rail shows the run’s overall progress: a donut (executed vs. total), a status legend, and metadata fields including the Estimate — a forecast of how long the run should take, computed from the average elapsed time of the same cases in prior runs of the project. When no case has any history the estimate renders as an em-dash (—).

If the project has run custom fields configured, the rail also shows a Run custom fields block, positioned between Elapsed and the linked defects list. This block is read-only — to change a value, use the Custom fields section in the create or edit run modal (see “Run custom fields” below). A field with no stored value shows its configured default, or an em-dash when it has no default. The block is omitted entirely when the project has no run custom fields.

Open a case to switch the rail for a slide-over execution panel: case short-id, title, the snapshotted description / pre-conditions / post-conditions (only the conditions the project has enabled are shown), and the steps. Each step has its own per-step Pass / Fail / Skip / Block band and a collapsible Data / Expected result card — click the chevron to reveal Data and Expected result stacked inside the body. Marking a step reveals its Actual result text field without forcing that disclosure open or closed; there you can add image attachments (PNG / JPEG / WebP up to 2048px, automatically converted to WebP with a thumbnail). Actual-result text and attachments are saved automatically — there is no explicit Save button.

A Case result control is docked at the bottom of the Execution tab. Use it to mark the entire case Pass / Fail / Skip / Block. This is the case-level outcome that records an entry in the History tab (with a frozen per-step snapshot you can reopen later). Per-step marks update the live workspace immediately and appear in the project Activity feed, but they do not create a History entry on their own.

Cases that already have a terminal result (Passed, Failed, Skipped, or Blocked) open in a readonly consultative view: the Case result control is not present, step marks are read-only, and the panel shows a Defects tab (linked defects filed during the attempt) and a metadata rail with who executed the case, when it started, how long it took, and when it finished.

For a case with that terminal result, the panel header leads the case title with a compact result mark — a small status glyph in a tinted circle — in place of the result chip that used to sit beside the case short-id. This applies on every surface: the slide-over panel, the full-screen view, and the read-only attempt panel opened from History. The mark is icon-only; the retest count is not shown in the header. A case that is still untested, or was just reset via Retry, shows no header result indicator.

The panel header includes an expand control (⤢) that opens a full-screen view of the same case content. Press Escape or click the collapse control (⤡) in the top-right corner of the full-screen view to return to the slide-over panel.

Case navigator in the full-screen view

When the full-screen view opens, a case navigator appears as a left-side rail. The navigator lists every case in the run, grouped by suite; each suite group shows its own mini progress chart, and each case row shows the compact result mark described above (a dashed neutral ring for untested cases).

Search the navigator with its own search field — this filter applies only to the navigator list and never changes the board’s filters or the page URL.
Click any case row to switch the main panel to that case. The breadcrumb and content update; the timer for the previously open case is preserved.
The currently displayed case is highlighted with a pressed state in the list.
The navigator is view-only: selecting a case here does not automatically assign it to you.

Other things to know:

The board’s bulk-action toolbar adds Retry (reset the selected cases to untested) and Remove (delete them from the run); both are disabled only on an aborted run — a completed (closed, non-aborted) run keeps them available. The previous “Submit result” bulk action is not part of the new board.
A timer still starts when you open a case and stops when you mark it.
The case status is derived from its steps (any failed or blocked step makes the case fail).
Run metadata (state, started-by, environment, started-at, total time, elapsed) lives in the summary rail; the rail is hidden whenever a case panel is open.

Case status icon during execution

While executing a run, the board shows a small icon at the far right of each case row when the case’s Status is not Active. This is the same indicator shown in the test repository.

Key points:

The icon reflects the case’s current status in the repository — not the snapshotted state captured when the run was created. If the status changes after a case is added to the run, the icon updates accordingly.
Active status and unset status show nothing. Only non-Active options (Draft, Deprecated, or a custom non-active option with an icon) trigger the indicator.
This differs from other case data (title, steps) which are snapshotted at the time of adding the case and never change regardless of edits to the source case.

Closing a run

A run closes itself automatically the instant every case carries a result — there is nothing to click. Once the last untested (or retest) case is marked, Probara closes the run immediately and the runs list reflects it right away.

You can still click Complete to finish a run early, while untested cases remain — a manual complete for when you are done testing but some cases were never going to be run. If untested cases remain you are asked to confirm. Complete never disappears just because auto-close exists: the two work together, not as alternatives.

Closing — whether automatic or manual — is not the end of the run’s story. A closed, non-aborted run stays fully editable: you can still mark, retry, or remove cases, add new cases, attach screenshots, and edit results. The board loses only the Complete button and the read-only banner shown for aborted runs (see below); nothing else changes. Marking the last remaining case again later never “reopens” the run — closing is a one-way state. If you retest a case or add a fresh untested case inside a closed run, the run stays closed; it never flips back to open on its own.

Aborting a run

If a run needs to stop early — the scope changed, the build is unusable, or the run was started by mistake — use Abort run from the overflow (⋯) menu on the run detail page instead of Complete or Delete. Abort is only available while the run is open; a completed or already-aborted run has no Abort option.

Confirming abort in the destructive dialog (no reason field) freezes execution immediately: the run closes, any cases still untested stay untested — abort never records a result on your behalf — and existing results and attachments are kept exactly as they were. The run shows an Aborted chip on the runs list and can also be found with the Aborted Status filter option, alongside In progress / Passed / Failed.

Unlike a completed (closed, non-aborted) run, an aborted run is terminal-frozen: marking, retry, remove, adding cases, and attaching screenshots all stay disabled, and the board shows the read-only banner. If you need to try again, use Run again (below) to clone a fresh run from it.

An aborted run still counts as finished for milestones and test plans — it never blocks a milestone from auto-completing and never stalls a plan’s progress rollup — but its case counts (passed, failed, blocked, skipped, untested) are excluded from milestone and test-plan progress numbers, so an abandoned run does not skew what “done” looks like for the rest of the team.

Data retention

Every run you create is kept indefinitely by default — there is no automatic expiry unless your plan includes a retention window. If your organization’s plan includes one, runs (and everything they contain: cases, steps, results, and attachments) that have been closed or aborted longer than that window are removed automatically on a recurring schedule. A run that is still open is never removed, no matter how old it is.

This removal is permanent. There is no undo, no recycle bin, and no restore option — once a run’s retention window has passed, it and its results are gone. If you need to keep a run’s history longer than your plan’s window, export or archive what you need before it ages out.

The activity feed keeps every entry that referenced a removed run; only the link to the run itself is cleared, so the audit trail of what happened stays intact even after the run it describes is gone.

If you believe your organization’s retention window is set incorrectly, contact support — staff can grant, clear, or raise it on request.

Editing a run

Use Edit run from the overflow (⋯) menu to change a run’s descriptive details or reselect its cases after creation. Edit is only available while the run is open; a completed or aborted run has no Edit option.

The Edit run modal reuses the same fields as run creation — Title, Description, Environment, and Milestone — pre-filled from the run’s current values. Default assignee is not editable here: it is a one-time seed used only when the run is created, so the modal never shows it and never sends it when you save. Per-case assignees remain the way to control who works on a case after creation.

Clicking Add cases opens the same case-selection modal used at creation, seeded with the run’s current selection and per-case assignees — check or uncheck cases and adjust assignees exactly as you would when creating a run. Only the repository picker is available; sourcing cases from a test plan is a creation-only flow. Saving persists your changes to the case selection and the metadata fields together.

If your changes would remove one or more cases that already have a recorded result or tracked time, Probara shows a destructive confirmation before saving, naming how many cases are affected. Confirming proceeds with the save; cancelling (or pressing Escape) leaves the run completely untouched — no request is sent. Removing cases that are still untested with no tracked time never triggers this extra confirmation.

Results and tracked time are not recoverable. If you remove a case that was already executed and add it back later, it comes back as a fresh, untested case — its prior result and time are gone for good.

Run custom fields

If your organization has configured custom fields for the Run entity (see Custom fields), both the run creation modal and the Edit run modal show a Custom fields section, rendered with the same field controls used elsewhere (short text, number, select, checkbox, user picker, etc.).

In the create modal, the section appears on the From repository tab only, pre-filled with each field’s configured default value. From test plan never shows it and never sends any custom-field value with a generated run — plan-generated runs still receive each required field’s default automatically, the same as any other run.
In the Edit run modal, the section is pre-filled from the run’s currently stored values (not from the field defaults), so editing a run never silently resets a value you already set.
A required field left empty blocks the save and shows This field is required next to the control — no request is sent until every visible required field has a value.
If the project has no visible run fields, neither modal shows the section at all.
Closing either modal without saving discards any custom-field edits, the same as every other field on the form.

Run configurations

If your project has configuration groups (see Configurations) with live values, both the run creation modal and the Edit run modal show a Configurations section — one dropdown per group, offering at most one value.

A group’s dropdown includes a No value option, so a run can carry a value for some groups and none for others.
In the create modal, the section appears on every tab and the chosen values are sent together with the rest of the run in a single request.
In the Edit run modal, the section is pre-filled from the run’s current configurations. Saving sends the new selection only when it actually changed; clearing every value and saving removes the run’s configurations entirely.
Editing configurations follows the same rule as every other metadata field: it works on an open run and on a closed, non-aborted run. An aborted run has no Edit option at all, so its configurations stay fixed.
If the project has no configuration groups with live values, neither modal shows the section.
Closing either modal without saving discards any unsaved configuration changes.

Running a run again

There is no Reopen — once a run is closed (auto-closed, completed, or aborted), it stays closed. To re-execute, use Run again from the overflow (⋯) menu on any closed run (completed or aborted). It opens the Clone test run dialog, which spins up a brand-new open run from the finished one — the source run is never touched.

The dialog asks for:

Title (required) — pre-filled as “source run name (clone)”; edit it before confirming.
Clone with assignees — when checked, each carried-over case keeps its assignee from the source run; when unchecked (the default), every case in the new run starts unassigned.
Case statuses to include — a searchable multi-select of the six case outcomes (Untested, Retest, Passed, Failed, Skipped, Blocked). Leave it empty to carry over every case from the source run regardless of its last result; select one or more statuses to carry over only matching cases — the classic use is selecting Failed + Blocked to re-run just what broke.

Adding a result and reporting a defect

Marking a case Passed, Retest, or Skipped advances immediately with no modal — the mark and the silently-captured time are saved right away.

Marking a case Failed or Blocked opens the Add result modal before anything is saved — the case stays untested until you confirm. In the modal you can:

Change the Result if you picked the wrong outcome — the select offers all four markable outcomes (Pass / Fail / Skip / Block). Switching to Pass or Skip hides the defect toggle and, on confirm, saves that outcome instead, carrying over any comment, time, or attachments you already entered.
Add a result comment describing what happened.
Review and, if needed, adjust the recorded time for the attempt.
Attach files (any type, up to the project’s per-file and per-result limits) while the modal is still open — uploads happen in the background so Confirm stays fast.
Decide whether to create or attach a defect, using a toggle that defaults on for a Failed/Blocked selection.

Selecting Cancel or pressing Escape on the Add result modal discards everything: the case stays untested, nothing is saved, the stopwatch resumes exactly where it was when the modal opened, and focus does not advance — it is as if you never marked the case.

Confirm saves the selected result, comment, recorded time, and attachments together as one action. With the defect toggle off, the case advances to the next one. With the toggle on (only available for Fail/Block), Confirm opens the Report defect modal against the newly saved attempt, with two tabs:

Create new — file a fresh defect. The description field starts pre-filled from the case’s failed steps (expected vs. actual result for each), so you rarely need to type it from scratch; it stays fully editable. The composed headings (Case:, Precondition:, Failed steps:, Expected: / Actual:) are always in English by design, regardless of your interface language — this keeps defect descriptions consistent for teams that triage in a shared tracker. You can also set severity, priority, a milestone, and an assignee before creating it.
Attach existing — select a defect you already filed, either from the suggested list (previously linked to this case) or by searching the project’s defects, then press Attach defect to link it. Trying to attach with nothing selected shows an inline reminder instead of linking. Selecting a resolved or closed defect announces that confirming will reopen it; attaching links the attempt and reopens the defect together.

On either tab, check Create another defect to file or attach several defects from the same attempt without leaving the modal — each successful create or attach resets that tab and keeps the modal open.

Changed your mind after seeing the Report defect modal? Click the back arrow next to the title to return to the Add result modal with everything you entered intact — result, comment, time, and attachments. Re-confirming only re-saves whatever you actually changed.

Use the retry dock’s Add defect action on a locked case to open the Report defect modal directly for that attempt, skipping the Add result step.

See Defects for the project list and detail views.