Defects are project-scoped bug records numbered sequentially (D-1, D-2, …).
Open Defects in the project sidebar to browse the list, or file defects while
executing a test run.
The defects list
The list table shows each defect’s number, title, status, severity and priority (from your org’s system-field options), assignee, how many run attempts it was linked to, when it was last seen in a run, and how long ago it was created.
The search box and a permanent Status chip are always present in the filter
bar; the search matches titles or defect numbers (D-12 or 12). The Status chip
is always shown (it has no × and is never offered in Add filter) — click it
to open its popover editor and check one or more statuses, or leave it empty.
Severity, priority, and assignee are reached through Add filter and appear as
removable chips — click a chip to open its popover editor and check values. Each of
these is multi-select: pick several severities, priorities, or assignees and the
list shows defects matching any of the checked values (the chip then reads
“2 selected”). Different filters still combine with and — severity ∈ {Critical,
Major} and assignee ∈ {Ana, Bruno}. Active filters are reflected in the URL so you
can share a filtered view; a link that carries a single value keeps working.
Custom columns
Use Columns in the toolbar to show additional defect custom fields after the built-in columns. Option fields render colored option names; checkboxes, dates, and members use the same read-only display as the defect detail page. Text values show on one line (hover for the full value when truncated). Defects with no stored value for a column show an em-dash.
Your column choices are saved per project in this browser. If a field is later hidden from the project, its column is dropped silently on the next visit.
Custom filters
Add filter lists filterable custom fields (options, checkbox, and member picker) alongside the built-in severity, priority, and assignee filters. Selecting one adds a chip whose editor opens immediately — no filtering is applied until you pick a value. Each editor offers an (empty) choice for defects that have no stored value for that field — including defects that only show a default on the detail page. Custom filters are evaluated against stored value rows only; a default you see on detail does not satisfy an option filter until the value is saved.
Custom filters appear in the URL as cf parameters and compose with built-in
filters. Use a chip’s × to remove it (clearing its cf entry). An age bucket
chosen from the metrics strip appears as a removable chip too.
Metrics strip
Above the filter bar, a compact strip summarizes open defects for the project: open-by-severity cards (one per org option, including zero counts), aging buckets (0–7, 7–14, 14–30, and 30+ days since creation), reopen rate, mean time to resolve (MTTR), and milestone breakdown. Click a severity or aging card to apply the matching list filters (open and in-progress defects only). When metrics cannot be loaded, the strip is hidden and the list still works.
Saved filters
Name the current filter combination and click Save filters to store it in this browser for the project. Saved sets appear as chips below the filter bar — click one to re-apply it, or use × to delete it. Saved filters are per device and are not shared with teammates.
The Defects item in the project sidebar shows a badge with the open-defect count when it is greater than zero.
Click a row to open the defect detail. Use Load more when the project has more defects than one page.
Members and above can click New defect to create a record from the list. The dialog includes a Custom fields section when the project has visible defect-scoped definitions; required fields must be filled before submit. Omitted empty values are not sent — the API materializes defaults on read. Viewers can browse but cannot create or edit.
Filing from a run
When you mark a case Failed or Blocked, the Add result modal opens first so you can review the outcome, add a comment, and adjust the recorded time — nothing is saved until you confirm. If you turn on the defect toggle before confirming, the Report defect modal opens next, against the attempt that was just saved. You can attach an existing defect or create one quickly. Suggestions include previously linked defects; selecting a Resolved or Closed suggestion announces that attaching it will reopen the defect, and confirming links the new attempt and moves the defect back to Open in the same step. Linked defects appear as chips in the case panel — click a chip to jump to that defect’s detail page. A back arrow next to the Report defect title returns to the Add result modal without creating or linking anything, in case you need to correct the result first.
Quick-create (Enter or Create and link) stays one keystroke when every required defect custom field visible in the project has a non-empty default (or when no required defect fields exist). If a required field has no default, the full New defect dialog opens prefilled with the capture title; submitting there creates the defect, links the marked attempt, and closes both dialogs. If the server rejects a quick-create because a required field was added mid-session, the same prefilled dialog opens instead of a raw error.
While executing a run, the summary rail on the right lists every distinct defect
linked to that run as D-<n> chips. When you Complete the run, the
confirmation mentions how many defects are linked if any remain untested cases or
when closing with linked defects.
Defect detail
The detail page uses a full-width main column plus a right sidebar (stacked below the main content on narrow viewports).
The header shows a breadcrumb (<project> › defects › D-<n>), the title,
severity and priority chips, how many run attempts are linked (and when the defect
was last seen), and a workflow status control with short descriptions for each
legal transition.
The main column contains, top to bottom:
- A whitespace-preserving description
- An Evidence section (a unified card grid of image thumbnails and non-image file cards, with an Add evidence upload control for members)
- An Affected cases card — manually linked cases and cases surfaced by failing runs, with occurrence counts, latest result chips, and (for Resolved defects) verification badges with close/reopen suggestions in a banner above the table
- Occurrences and Activity tabs
Section headings (Description, Evidence, Affected cases) use your organization’s localized defaults unless an admin renamed them under Workspace → Custom fields (core rows with the Core badge). Renamed titles appear verbatim in every locale; the affected-cases heading still appends the linked-case count when present.
Occurrences is a table of every linked run attempt, newest first (run, case, result, executed time, who linked it). Select a row to open the frozen attempt snapshot (read-only steps and results). Activity shows the defect’s audit history (created, updated, status changes, links).
The sidebar has two tabs:
- Properties — severity and priority system fields first, then assignee, reporter, tags, milestone, duplicate-of link, created/updated timestamps, and other visible custom fields (editable inline for members; read-only for viewers) (default tab)
- Discussion — the comment thread and composer, with a badge showing the comment count
Members can edit title, description, status, assignee, tags, and milestone from the header and Properties tab. Severity and priority are edited as system custom fields in Properties (not via defect PATCH). Status changes follow a guided lifecycle:
| From | Allowed next statuses |
|---|---|
| Open | In progress, Resolved, Closed |
| In progress | Open, Resolved, Closed |
| Resolved | Closed, Open (reopen) |
| Closed | Open (reopen) |
Choosing Resolved or Closed requires picking a resolution in a dialog.
Duplicate resolutions must point at a canonical defect (D-<n>); chains are
flattened to the root automatically. Reopening clears the resolution, duplicate
pointer, and lifecycle timestamps.
Affected cases
The Affected cases card shows every test case associated with a defect, regardless of how the association was created. A case can appear because a failing run linked it automatically, because a member added it manually, or both at once.
Linking a case manually
Members (owner, admin, or member role) see a + Link case button in the card
header. Click it to open a search dialog, type part of the case title or C-<n>
number, and select a result. Archived cases and cases already in the list are
excluded from the picker. The case appears immediately with a Linked badge
indicating it was added manually. Viewers do not see the link button.
Reading the list
Each row shows the case number, title, occurrence count (how many run attempts linked this defect to that case), and latest result chip. A Linked badge marks cases that were added via + Link case. A case that was both manually linked and surfaced by runs shows the badge alongside its occurrence count — the two origins are merged into one row.
When there are no affected cases yet, the card shows an empty state with a Link a case shortcut (visible to members only).
Removing a case
Open the three-dot menu on any row to remove it. The available action depends on how the case was added:
- Unlink — available for manually linked cases (those with the Linked badge). Removes the manual link. If the case still has run occurrences it stays in the list as a run-derived case (without the badge); if it had no occurrences it disappears entirely.
- Dismiss — available for run-derived cases (those without the Linked badge). Hides the case from this defect without changing any run result. A dismissed case reappears automatically if the case fails again in a new run after the dismissal.
Both actions open a confirmation dialog before taking effect. Viewers do not see the three-dot menu.
Verification loop
When a defect is Resolved, the Affected cases table adds a verification column. Each case shows a badge:
- Verified — the case passed after resolution (close suggestion available).
- Failed after resolve — the case failed or was blocked again (reopen suggestion).
- Pending — nothing has run since resolution; re-run those cases to verify the fix.
The banner above the table never changes status on its own — use the status control or the suggested CTAs, which route through the same flows as the header.
Evidence gallery
The Evidence section accepts any file type — screenshots, logs, HAR files, PDFs, videos, spreadsheets, crash dumps — up to 32 MiB per file and 20 attachments per defect. Members use the dashed Add evidence card to upload files or delete attachments they added. Viewers see the section but cannot upload or remove anything.
Evidence renders as a single card grid. Images (PNG, JPEG, WebP) show as thumbnail
cards; click one to open a lightbox with the full image, filename, and position
counter. Every other file type shows as a card alongside them — a file icon and the
human-readable size in the card body, the original filename in the footer — and
clicking it downloads the file rather than previewing it. Executable files
(.exe, .msi, .sh, .bat, and similar) are rejected outright and never stored.
Every evidence upload counts toward your organization’s storage quota. If an upload would push the organization over its storage cap, it is rejected with a distinct quota-exceeded message and nothing is attached.
Discussion thread
Open the sidebar Discussion tab for a chronological comment thread with a composer for members. Post a comment to append it without reloading the page. You can edit or delete your own comments; organization admins can delete any comment. Edited comments show an (edited) marker. When an author leaves the organization, their comments remain with a removed-author placeholder. Viewers can read the thread but cannot post, edit, or delete.