Docs · Guides

Test repository

The repository is the day-to-day surface for managing tests inside a project.

Suite tree

  • Suites can be nested.
  • + New suite opens a single dialog with a required Parent suite picker. The default is Project root; you can choose any suite in the tree before saving. A suite’s action menu opens the same dialog with that suite preselected as the parent.
  • Edit suite (suite actions menu or the path bar edit icon) lets you change the name, description, and parent suite. The picker starts at the current parent (or Project root for a root suite). You cannot pick the suite being edited or any of its descendants; the API still rejects cycles if the tree changed while the dialog was open.
  • Expand/collapse branches in the sidebar.
  • Create suites from the suite actions menu.

Collapsing navigation rails (desktop)

On desktop, each navigation column has its own collapse control. States are saved in your browser and restored on reload.

  • Project side rail (project name, Tests links, Settings) collapses to an icon-only mini-rail (~3.5rem). Hover or keyboard-focus an icon to see its label in a tooltip.
  • Suite tree (this column) has no per-suite icons, so it collapses to a thin strip with an expand control instead of a mini-rail. The column stays mounted so the layout does not jump.
  • Collapsing one bar does not affect the others—you can hide the project rail while keeping the suite tree open, or the reverse.

Use the chevron on each bar header to collapse; when collapsed, use the chevron (project/workspace/user rails) or the expand control (suite tree) to restore the full column.

Test cases

  • Create cases from the repository (quick add or full editor).
  • Open a case to view the detail panel with tabs for properties and steps.

Shareable URLs (display IDs)

The browser uses human-readable display IDs instead of internal ULIDs in repository links:

  • Suite in the path: /projects/{projectCode}/suites/{projectCode}-S{suiteNumber} (for example /projects/ACME/suites/ACME-S2).
  • Case in the query string: ?case={projectCode}-{caseNumber} (for example ?case=ACME-14).

When you open a case from the project root, the URL updates to include both the suite segment and the ?case= parameter so the link is copy-paste friendly and reloads back into the same suite + detail panel.

Cases without a suite use /projects/{projectCode}/unassigned?case={projectCode}-{caseNumber}.

Invalid or unknown display IDs fail gracefully: unknown suites show a not-found page; unknown ?case= values leave the detail panel closed without error toasts.

  • Edit title, suite, and steps in the editor; classification (priority, severity, status, type, layer, behavior, automation status, is flaky, plus any organization custom fields) is rendered dynamically based on the project’s enabled fields and persisted through the dedicated custom-field-values endpoint.

Editor sections

The full editor groups inputs into up to four sections rendered in order. Each visible section shows an NN · LABEL eyebrow where NN is the current 1-based index (01, 02, …) among sections that are actually rendered; numbers shift when an optional section is hidden.

  1. BASIC (01 · BASIC when it is the first section) — title, description, suite, milestone, and the system enum/checkbox fields (priority, severity, status, type, layer, behavior, automation status, is flaky) in product order.
  2. EXTRA — organization-defined custom fields for this project (heading Custom Fields). The section and its preceding rule are omitted when the project has no visible custom fields; later sections renumber.
  3. CONDITIONS — preconditions and postconditions, rendered as paragraph fields. The section collapses when both are out of scope. When only one is visible, the section title and description adapt (for example Preconditions / System state before the case. instead of the combined “Pre and post” copy). Later sections renumber.
  4. STEPS — the case’s manual steps (always shown; its number depends on how many optional sections precede it).

Submit performs a slim POST /api/v1/projects/:projectUlid/test-cases (or PATCH /api/v1/test-cases/:caseUlid in edit mode), followed by the steps PUT if any step changed, and finally a PUT /api/v1/test-cases/:caseUlid/custom-field-values for the dynamic classification block. If one stage fails the others stay applied and the editor surfaces a partial-success error so the user can retry just the failed step.

Detail panel General tab

The General tab shows description, preconditions, postconditions, and steps. Preconditions and postconditions sections render only when that system field is visible for the case’s project—the same project-scoped definition list that drives the editor. A field hidden per project scope shows no heading, no empty placeholder, and no stored value in read-only views (collapsed detail panel and expanded dialog). Values are not deleted on the server; linking the field to the project again restores display.

Detail panel Properties tab

The Properties tab renders the Classification block dynamically. The first row is Suite: a full-width hierarchy selector. Project root means the case is not in any suite (it appears under Cases without suite in the sidebar). Changing suite here sends a slim case PATCH, records workspace activity, and reverts the selector if the request fails.

Below that come system fields (priority, severity, status, type, layer, behavior, automation status, is flaky), then custom fields sorted by title in a two-column grid. Inline custom-field edits send the full PUT /custom-field-values and merge the server response; failures revert only the affected field.

Traceability keeps the milestone row only—the read-only Suite row was removed (suite now lives under Classification). The panel’s expanded dialog mirrors the same layout.

Status icon

Each case row shows a small icon at the far right when the case’s Status is not Active. The icon and its color match the status option configured for that case (for example, a dashed circle for Draft or a warning indicator for Deprecated). When the Status is Active or not set, the slot is empty and nothing is shown — only non-Active statuses need visual attention.

  • The icon appears for any status option whose system key is not status_active, including custom status options that have an icon assigned.
  • Custom status options without an icon assigned do not show anything even when they are not Active.
  • Hovering the icon shows a tooltip with the option name.

Steps

Each step has action text and optional data / expected fields. Save changes with Save when editing steps in the detail panel.

Step images

While editing steps (full editor or the detail panel Edit mode on the Steps block), use Add image on a step row to attach one or more screenshots (PNG, JPEG, or WebP). You can select multiple files at once. Thumbnails appear under ATTACHMENTS on that row; remove one with the × control before saving.

  • Edit existing case — staging works immediately because the case already has an ID.
  • Create new case — add images after the first save (the control stays disabled until the case exists), or save once and return to attach images.
  • Read mode — expand a step in the detail panel to see ATTACHMENTS with a thumbnail grid when images are present.

Images are stored as WebP (full + thumbnail) and shown through the same public asset URLs as project avatars.

Keyboard navigation in tab strips

Tab strips throughout the application (detail panels, run views, plan views, and other tabbed surfaces) follow the standard WAI-ARIA Tabs keyboard pattern.

Moving between tabs

KeyAction
ArrowRightMove to the next tab (wraps from the last tab to the first).
ArrowLeftMove to the previous tab (wraps from the first tab to the last).
HomeJump to the first tab.
EndJump to the last tab.

Selection follows focus automatically — pressing an arrow key both moves focus and activates the tab.

Tab order

Only the currently active tab is in the page tab order. Pressing Tab skips over the inactive tabs and moves focus to the next interactive element after the tab strip. To reach a different tab, first focus the active tab with Tab, then use ArrowRight or ArrowLeft to navigate.

Bulk selection

Hover any case row or suite band to reveal a checkbox. Selecting at least one case shows a bulk-action bar below the filter bar with the selection count, Edit and Duplicate (visible but not yet active), Run, Delete, and Clear selection.

  • Suite checkboxes are tri-state. A suite band shows checked when every case in its recursive subtree (including collapsed sub-suites) is selected, indeterminate when only some are, and unchecked otherwise. Toggling a suite band selects or deselects its entire subtree in one action.
  • The “Cases without suite” band offers its own checkbox for orphan cases; it is never treated as a deletable suite.
  • Selection survives filtering. Selecting cases, then narrowing the list with search or filters, keeps every selected case counted in the bulk bar even while it is hidden from view. Clearing the filter shows it selected again.
  • Empty suites show no checkbox — there is nothing to select.

Bulk delete

Activating Delete opens a confirmation summarizing how many suites will be deleted and how many cases will be archived, then:

  1. Loose selected cases (not covered by a fully-selected suite) are archived first.
  2. The topmost fully-selected suites are deleted — this reuses the existing suite-delete behavior, which archives every case in that suite’s subtree. A suite whose parent is also fully selected is not deleted separately; only the topmost one is.

If a step fails partway through, the process stops immediately, the error is shown, and your selection is not cleared — the repository refreshes so you can see what changed and retry. On full success, the selection clears and the listing refreshes. If the case you had open in the detail panel was part of the deleted selection, the panel closes.

Bulk run

Selecting cases and activating Run takes you to the project’s Runs screen with the new-run modal already open and those cases preselected — you can still add or remove cases before creating the run. See the Test runs guide’s “Creating a run from a repository selection” section for details.

Trash

Archived cases move to Trash. You can restore or permanently remove them depending on your role.