> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testdino.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Test Case Structure, Steps, and Suites
> Field definitions, step formats, version history, and the project settings that decide which fields appear on a test case.
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-management/suites)
## 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 20,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 |
| Priority | Critical, High, Medium, Low, Not Set |
| Severity | Blocker, Critical, Major, Normal, Minor, Trivial, Not Set |
| Type | Smoke, Regression, Functional, Integration, E2E, API, Unit, Performance, Security, Accessibility, Usability, Compatibility, Acceptance, Exploratory, Other |
| Layer | E2E, API, Unit, Not Set |
| Behavior | Positive, Negative, Destructive, Not Set |
**Note**
All classification dropdown values can be customized per project. See [Test Case Settings](#test-case-settings) below.
### Automation fields
| Field | Description |
| :- | :- |
| Automation Status | `Manual` or `Automated` (fixed values) |
| To Be Automated | Flag a manual case for automation. Shown only for `Manual` cases and cleared when a case becomes `Automated` |
| Flaky | Mark the case as producing inconsistent results |
| Muted | Mark the case as muted. You can filter by it |
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](/test-management/test-cases/list-view#details-sheet) and can be used in [Bulk Actions](/test-management/bulk-actions) to add or remove tags across multiple test cases.
* **Custom Fields** - Project-specific fields configured in [Test Case Settings](#custom-fields) (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.
| Format | Structure | Best For |
| :- | :- | :- |
| **Classic** | Each step has an **Action**, optional **Test Data**, and an **Expected Result**. | Step-by-step test procedures |
| **Gherkin** | Each step uses a keyword (`Given`, `When`, `Then`, `And`, `But`) followed by text. | BDD-style scenarios |
## Version History
Every change to a test case is tracked as a new version. The **History** tab on the [Details Sheet](/test-management/test-cases/list-view#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.
| Plan | Versions kept per test case |
| :- | :- |
| Pro | Latest 100, plus version 1 |
| Team | Latest 250, plus version 1 |
| Enterprise | Unlimited |
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.
| Field | Type | Example Values |
| :- | :- | :- |
| `Priority` | Dropdown | `Critical`, `High`, `Medium`, `Low`, `Not Set` |
| `Severity` | Dropdown | `Blocker`, `Critical`, `Major`, `Normal`, `Minor`, `Trivial`, `Not Set` |
| `Type` | Dropdown | `Smoke`, `Regression`, `Functional`, `Integration`, `E2E`, and more |
| `Behavior` | Dropdown | `Positive`, `Negative`, `Destructive`, `Not Set` |
| `Layer` | Dropdown | `E2E`, `API`, `Unit`, `Not Set` |
| `Status` | Dropdown | `Active`, `Draft`, `Deprecated` |
#### Automation
Use automation fields to track the automation state of a test case.
| Field | Type | Description |
| :- | :- | :- |
| `Automation Status` | Dropdown | `Manual`, `Automated` (fixed) |
### Custom Fields
Create project-specific fields that appear on every test case in the [Details Sheet](/test-management/test-cases/list-view#details-sheet) sidebar under **Custom Fields**.
| Type | Description |
| :- | :- |
| Text | Single-line text input |
| Textarea | Multi-line text input |
| Number | Numeric values |
| Dropdown | Select from predefined options (define the option list) |
| Checkbox | True/False toggle |
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](/test-management/manual-testing/releases#release-type-settings) for details.
### Runs
You can also customize result statuses, run states, environments, and tags. See [Run Settings](/test-management/manual-testing/manual-runs#run-settings) for details.
### Sessions
You can also customize session states, session types, and finding result statuses for exploratory testing. See [Session Settings](/test-management/manual-testing/sessions#session-settings) for details.
Organize tests in a tree structure
Search, sort, filter, and view full test case details
Releases, manual runs, and exploratory sessions
Edit, delete, or print multiple test cases
Definitions of TestDino and Playwright testing terms
## Limits
| Item | Limit |
| :- | :- |
| Suite nesting depth | 6 levels |
| Attachments per test case | 10 files, 10 MB each |
| Attachments per step | 2 files |
| Comments per test case | 20 |
| Options per dropdown field | 20 |
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.