Anatomy of a test case

A test case is a persistent scenario inside a project. Every test case has these fields.

Identifier

The detail panel header shows a human-readable id like PET-37 — the project key plus a per-project sequence number. Automated cases also carry a testId, the opaque key your reporter uses to link a run back to this case.

Required

• Name — short, descriptive, unique within a project (recommended).
• Project — set automatically based on context.

Authoring metadata

• Status — DRAFT (work in progress), ACTIVE (ready to run), REVIEW (waiting for QA review), OUTDATED (kept for history but not run).
• Priority — LOW, MEDIUM, HIGH, CRITICAL. Cosmetic — used in dashboards and filtering.
• Automation status — MANUAL or AUTOMATED. Drives the run-mode picker (auto runs require a CI Job; manual runs don't).
• Owner — the user who created the case (read from createdBy). Cannot be reassigned in v1.

Body

• Steps — ordered list of step rows. Each step has a name; optionally substeps (one level deep), an expected result, attachments. A case's steps can be authored by hand or kept in sync with automation — see scenario source.
• Tags — picked from the project's shared tag registry (colored, reusable labels).
• Custom fields — defined per-project; types include text, single select, multi select, date, user, URL.

Comments

Comments live at the bottom of the test-case detail panel — use them for context, review notes, or questions for your team.

• Rich text — bold, italic, ordered and bullet lists, links, and inline code, with a Preview toggle to check the rendered result before you post.
• Anyone with access to the test case can leave a comment; the button reads "Leave a comment", and an empty thread shows "No comments yet".
• Deleting a comment is restricted to administrators.

Comments are part of the test case — they save with the case, not as a separate live thread.

Linkage

An automated result links to a test case when the identity in the uploaded report — the full test name in allure-results, or classname.name in JUnit XML — matches the case's automation id (testId). See Identity across runs; whether an unmatched result creates a new case is controlled by the project's ingest case-creation mode (default: Match only).

Lifecycle

Test cases are soft-deleted (Trash). Roles with the Restore permission can bring them back; permanent delete is only available in Trash mode and needs the Purge permission (project Owners by default).

Each field change is recorded in an audit log accessible from the detail panel.