What you’ll learn
- How test suites and test cases are structured
- Core, classification, and automation fields on every test case
- Classic vs Gherkin test step formats
- How version history tracks and restores changes
- How to customize dropdown values, feature toggles, and custom fields per project
Test Suites
A test suite is a folder that groups related test cases together. Suites can be nested to create a hierarchy (e.g.,API → Users → GET Endpoints).
- Every test case belongs to exactly one suite
- Suites have a name, description, and optional parent suite
- Drag-and-drop suites to reorder them in the Suites view
Test Cases
A test case is a single test scenario with a unique Case ID (e.g.,TC-6838). Each test case contains core fields, classification fields, automation fields, and metadata.
Core fields
| Field | Description |
|---|---|
| Title | Short name describing the test (required) |
| Description | Detailed explanation of what the test does (up to 5,000 characters) |
| Pre-conditions | What must be true before the test runs |
| Post-conditions | Expected system state after the test completes |
| Test Steps | Ordered list of actions with expected results (Classic or Gherkin format) |
Classification fields
| Field | Values |
|---|---|
| Status | Active, Draft, Deprecated |
| Severity | Blocker, Critical, Major, Normal, Minor, Trivial |
| Priority | Critical, High, Medium, Low |
| Type | Smoke, Regression, Functional, Integration, E2E, API, Unit, Performance, Security, Accessibility, Other |
| Layer | E2E, API, Unit |
| Behavior | Positive, Negative, Destructive |
NoteAll classification dropdown values can be customized per project. See Project Settings below.
Automation fields
| Field | Description |
|---|---|
| Automation Status | Manual, Automated, or To Be Automated |
| To be automated | Flag indicating this case should be automated in the future |
| Is Flaky | Marks the test as having inconsistent results |
| Is Muted | Marks the test as temporarily silenced |
Additional metadata
- Tags — Free-form labels (e.g.,
api,smoke,regression) for categorization and filtering. Tags appear as badges on the test case Details Sheet and can be used in Bulk Actions to add or remove tags across multiple test cases. - Custom Fields — Project-specific fields configured in Project Settings (text, number, textarea, dropdown, or checkbox)
- Attachments — Files attached to the test case (when enabled in Feature Toggles)
Test Steps
Each test case can have ordered steps. Two formats are supported:| Format | Structure | Best For |
|---|---|---|
| Classic | Each step has an Action (what to do), optional Test Data (input), and an Expected Result (what should happen). Steps can have sub-steps. | Detailed step-by-step test procedures |
| Gherkin | Write steps in Given / When / Then syntax | BDD-style test scenarios |
Version History
Every change to a test case is tracked as a new version. The History tab on the Details Sheet shows:- A timeline of all versions with who made each change and when
- A diff of what changed in each version (additions in green, removals in red)
- The ability to compare any two versions side-by-side
- The ability to restore a previous version
TipVersion History can be toggled on or off per project in Feature Toggles below.
Project Settings
Each project can customize how test cases work. Access settings from the ⋮ menu → Settings in Test Management.
Feature Toggles
Toggle optional features on or off for the project:| Feature | What It Controls |
|---|---|
| Version History | Track every change to test cases as versioned snapshots. When enabled, the History tab appears on the Details Sheet. |
| Attachments | Allow file uploads on test cases. When enabled, the Attachments tab appears on the Details Sheet. |
Customize Dropdown Values
Dropdown fields like Severity, Priority, Type, Layer, Behavior, and Automation Status can be customized per project.- Click any dropdown field in the Settings panel to edit its available values
- Add new values, remove existing ones, or reorder them
- Changes apply immediately to all test cases in the project
Custom Fields
Create project-specific fields that appear on every test case in the Details Sheet sidebar under Custom Fields.Supported field types
| Type | Description |
|---|---|
| Text | Single-line text input |
| Textarea | Multi-line text input |
| Number | Numeric values |
| Dropdown | Select from predefined options (you define the option list) |
| Checkbox | True/False toggle |
Manage custom fields
- Click + Add Field to create a new custom field
- Set the field name, type, optional description, and whether it is required
- For dropdown fields, define the list of selectable options
- Drag to reorder custom fields
- Delete a custom field to remove it from all test cases
WarningDeleting a custom field removes it and its values from all test cases in the project. This cannot be undone.
Settings Sections Reference
The Settings page organizes fields into these sections:| Section | Description |
|---|---|
| Features | Toggle Version History and Attachments |
| Core Fields | Built-in fields (Title, Description, Pre/Post-conditions) — read-only |
| Test Steps | Built-in step fields — read-only |
| Classification | Editable dropdown fields (Status, Severity, Priority, Type, Layer, Behavior) |
| Automation | Editable automation status field |
| Organization | Built-in fields (Suite, Tags) — read-only |
| Custom Fields | Your project-specific custom fields |
Suites
Organize tests in a tree structure
Test Cases
Search, sort, filter, and view full test case details
Import & Export
Custom field values are preserved in JSON export
Bulk Actions
Edit, delete, or print multiple test cases