Test Cases
The complete guide to creating, organizing, and managing test cases in TestKase.
Overview
A test case is the foundational building block of your testing process. It represents a single, verifiable scenario that validates whether a specific piece of functionality works as expected. Each test case captures what to test, how to test it (via ordered steps), and what the expected outcome should be — giving your team a repeatable, auditable blueprint for quality assurance.
In TestKase, test cases live inside projects and can be organized into folders for logical grouping. They are referenced by test cycles during execution, linked to defects when issues are discovered, and included in test plans for broader release-level coverage. Every change to a test case is tracked in a full audit trail, and execution results are preserved across cycles so you can monitor quality trends over time.
Rich detail fields
Priority, status, labels, preconditions, automation info, and custom fields
Structured test steps
Ordered steps with expected results, drag-and-drop reordering
Folder organization
Nested folders (up to 3 levels) to mirror your product architecture
Full traceability
Execution history, change audit trail, defect links, and attachments
Create a Test Case
There are two ways to create a new test case in TestKase. Regardless of which method you use, you will be redirected to the test case detail view immediately after creation so you can fill in additional fields, add test steps, and upload attachments.
From the toolbar
- Navigate to the Test Cases section from the project sidebar.
- Click New Test Case () in the top toolbar above the test case table, then choose Create Test Case from its dropdown. (The other item in that dropdown, Create with AI, opens the AI assistant instead.)
- In the creation dialog, enter a title for your test case. The title is the only required field. Optionally, you can also set the priority and select a folder to place the test case in.
- Click Create. TestKase assigns an auto-generated Test Case ID (e.g.,
TEST-123) and redirects you to the detail view.
From within a folder
- In the folder sidebar on the left, navigate to (or create) the folder where you want the test case to live.
- Select the folder so it is highlighted, then click New Test Case in the toolbar and choose Create Test Case.
- The creation dialog will pre-select the current folder. Enter the title and any optional fields, then click Create.
Creating several in a row
The create dialog's Create button has a dropdown next to it with a second option, Create & Add Another. Choosing it saves the test case and keeps the dialog open with your folder and field selections intact, so you can enter the next title straight away instead of reopening the dialog.
The auto-generated Test Case ID (e.g., TEST-1, TEST-2, ...) is unique within the project and
cannot be changed. Use it as a stable reference when discussing test cases in pull requests, Jira tickets, or team conversations.
Every new test case is automatically linked to the project's Master Cycle (TCYCLE-1), the default
test cycle created with the project. That is why TCYCLE-1 always contains every test case in the
project — see Test Cycles.
The Status field is optional and has no default — a newly created test case has no status until you set one. Use it (for example, move a case to Approved) to signal to your team that the test case is ready for execution.
Test Case Detail Tabs
When you open a test case, the detail view presents five tabs that organize all information about that test case. Each tab focuses on a different aspect of the test case lifecycle.
| Tab | Purpose | Key actions |
|---|---|---|
| Details | View and edit all test case fields — title, summary, priority, status, preconditions, labels, environment, automation ID, automated flag, and any custom fields. | Click any field to edit inline. Changes are saved automatically or via a Save button depending on the field. |
| Test Steps | Manage the ordered list of test steps. Each step has a description of the action to perform and an expected result. | Add, edit, reorder (drag-and-drop), or delete individual steps. |
| Attachments | Upload and manage files associated with the test case — screenshots, design specs, test data files, and more. Images, common documents and video are accepted, up to 50 MB per file; archives such as .zip and data files such as .json are not — see the full allowlist. | Upload new files, download existing ones, or delete attachments you no longer need. |
| Execution Status | Shows the execution history of this test case across all test cycles it has been included in. Each row shows the cycle name, executor, result (Pass, Fail, Blocked, Not Executed), and timestamp. | Click a cycle name to navigate to the cycle detail view. Use this tab to spot flaky tests or regressions. |
| History | A complete audit trail of every change made to the test case — field updates, step additions/removals, folder moves, and more. Each entry shows what changed, who changed it, and when. | Review the timeline to understand how a test case evolved over time. |
The Execution Status tab is read-only on the test case detail view. To actually execute a test case, add it to a test cycle and run it from there.
Test Case Fields
Every test case has a set of built-in fields that capture its metadata. These fields help you categorize, search, filter, and report on your test cases. Below is a complete reference of all available fields.
| Field | Required | Options / Format | Description |
|---|---|---|---|
| Test Case ID | Auto | TEST-1, TEST-2, ... | Auto-generated sequential identifier unique within the project. Cannot be edited. |
| Title | Yes | Free text (max 300 characters) | A concise, descriptive name for the test case. Should clearly communicate what is being tested. Example: "Login - Valid credentials redirect to dashboard". |
| Summary | No | Rich text | A detailed explanation of the test scenario, its purpose, and any relevant context. Supports markdown formatting. |
| Priority | No | Blocker, Critical, Major, Minor, Trivial | Indicates how important this test case is. Higher-priority tests should be run in every cycle; lower-priority tests may be run less frequently. Helps with prioritizing test execution when time is limited. |
| Status | No | Created, In Review, Approved, Archive | Tracks where the test case is in its lifecycle. Created / In Review = still being written or reviewed. Approved = ready for execution. Archive = no longer relevant (kept for historical reference). Status is optional and has no default. |
| Preconditions | No | Rich text | Describes the state the system must be in before the test steps begin. Examples: "User must be logged in", "Feature flag X must be enabled", "Test data seeded via /api/seed". |
| Test Data | No | Rich text | Input data the test needs as a whole — an account, a dataset, a payload. Individual test steps have their own Test Data field for step-specific input. |
| Expected Result | No | Rich text | The overall outcome the test case verifies. Individual steps also carry their own expected results. |
| Labels | No | Comma-separated tags | Free-form tags for cross-cutting categorization. Examples: login, payments, mobile, sprint-42. Labels work across folders, making them ideal for grouping test cases that span multiple feature areas. |
| Features | No | Multi-select list | The product feature(s) this test covers, chosen from your project's configured Features values. |
| Platform | No | Single-select list | The target platform for this test (e.g., Web, Android, iOS), chosen from your project's configured Platform values. |
| Environment | No | Multi-select list | The target environment(s) for this test, chosen from your project's configured environment values (e.g., QA, DEV). |
| Owner | No | Project member | The team member who owns this test case. Distinct from the per-cycle assignee, which is set inside a test cycle. |
| Version | Auto | Integer, starts at 1 | The test case's current version number. Only increments when versioning is enabled for the project and a version-triggering field changes. |
| Automation ID | No | 5-digit identifier(s) | Links this test case to automated tests in your CI/CD pipeline. A test case can have multiple Automation IDs — one per script, CI pipeline, or browser — and each reports its own automation run. See the Automation guide for full details. |
| Automated | No | Yes, No | Indicates whether this test case has a corresponding automated test. |
| Folder | No | Folder path | The folder this test case belongs to. Test cases without a folder appear in the root "All Test Cases" view. You can move test cases between folders at any time. |
| Custom Fields | No | Varies (single-list, multi-list, text, number, date) | If your project has custom fields configured, they appear alongside the built-in fields on the Details tab. Custom fields let you capture domain-specific metadata unique to your organization. |
Fields like Priority and Status are used as filter criteria in the test case list view. Filling them in consistently makes it much easier to find and organize test cases as your suite grows.
The options each list field offers — Priority, Status, Automated, Environment, Features, Platform and Labels — are set per project on the Field Value settings page. Whether a field appears on the form at all, and whether it is required, is set on Field Configuration. A field hidden there disappears from the form, the detail view, the filter modal and the import template, but its stored values are kept.
Score Badges
Every test case detail view displays two score badges in the tab bar — Flakiness Score and Duplicate Score. Both are computed automatically from your project's execution history and test case titles, giving you instant quality signals without opening a report. They use no AI and no credits, so they are always available.
| Badge | What It Measures | Score Range | Color Coding |
|---|---|---|---|
| Flakiness Score | How often the recorded result changes across executions, counting pass, fail and blocked. Resetting a case to not-executed is ignored. A high score indicates unreliable, non-deterministic results. | 0.00 – 1.00 | Blue (< 0.25) · Yellow (0.25 – 0.49) · Red (≥ 0.50) |
| Duplicate Score | How closely this test case title matches other test case titles in the project. A high score suggests redundancy in your suite. | 0.00 – 1.00 | Green (< 0.60) · Yellow (0.60 – 0.84) · Red (≥ 0.85) |
Reading the Badges
- Hover over a badge to see a detailed tooltip with the full score breakdown.
- The Flakiness tooltip shows the number of status flips, total executions, and recent execution history (cycle name, result, and date).
- The Duplicate tooltip lists the most similar test cases found, including their IDs, titles, and similarity percentages.
- Badges are color-coded so you can spot issues at a glance — green/blue means healthy, yellow means worth reviewing, and red means action is recommended.
The score badges do not consume AI credits — they are calculated from your own data when the page loads, and are always visible on the test case detail view.
For a deeper analysis of flaky tests and duplicate test cases across your entire project, run the Flaky Tests and Suite Optimization insight reports from the Reports tab.
Next Steps
- Test Steps — Define step-by-step execution procedures
- Folders & Organization — Organize test cases with folders, search, and filters
- Import & Export — CSV import and export
- Bulk Operations — Clone and bulk update test cases
- History & Attachments — Execution history, change tracking, and file attachments
- Versioning — Automatic version tracking and execution version recording
- Best Practices — Guidelines and FAQ