Test Case Structure, Steps, and Suites

Test Management is built from suites, test cases, and test steps. Version history records every change to a case, and project settings control which fields appear on it.

​

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).

• Test cases can live inside a suite or stay in Unassigned until you move them
• 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

​

Classification fields

​

Automation fields

A case can be Automated and flagged Flaky if the linked automated test fails intermittently.

​

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 Test Case Settings (text, number, textarea, dropdown, or checkbox)
• Attachments - Files attached to the test case

​

Test Steps

Each test case has ordered steps in 1 of 2 formats. A test case holds steps in only 1 format at a time: switching formats removes the steps written in the old one, after you confirm.

​

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 2 versions side-by-side
• The ability to restore a previous version

How many versions a test case keeps depends on your plan. Version 1 is always kept. When older versions have been removed, the History tab says so below the timeline, for example 30 older versions were pruned. Pro keeps the latest 100 per test case plus v1. Upgrading keeps more history from then on; it does not bring removed versions back.

​

Test Case Settings

Open Test Case Settings from the Test Cases header. The page has 4 tabs: Test Case Fields, Custom Fields, Reusable Steps, and Test Execution. Releases, Runs, and Sessions are sections inside the Test Execution tab.

​

Test Case Fields

Test Case Fields contains 2 sections: Classification and Automation. Each field shows its available values. Most fields have a visibility toggle; Status and Priority are always shown. Enabled fields appear in the test case Details panel, while disabled fields stay hidden. You can add or edit values for every field except Automation Status, whose values are fixed.

​

Classification

Use classification fields to organize and categorize test cases.

​

Automation

Use automation fields to track the automation state of a test case.

​

Custom Fields

Create project-specific fields that appear on every test case in the Details Sheet sidebar under Custom Fields. Click Add Custom Field to create a custom field. Set the field name, type, optional description, and whether it is required. For dropdown fields, define the list of selectable options. Deleting a custom field removes it and its values from all test cases.

​

Releases

You can also customize the release types used by your team, such as Sprint, Hotfix, and Patch. See Release Type Settings for details.

​

Runs

You can also customize result statuses, run states, environments, and tags. See Run Settings for details.

​

Sessions

You can also customize session states, session types, and finding result statuses for exploratory testing. See Session Settings for details.

​

Limits