Custom Fields
Extend test cases with custom fields for text, dropdowns, dates, and numbers.
Overview
Custom fields let you extend the built-in test case structure with additional data points tailored to your team's unique workflow. While TestKase provides a comprehensive set of standard fields (title, description, priority, status, type, labels, environment, and more), every team has domain-specific metadata they need to track alongside their test cases.
Custom fields bridge this gap by letting you define project-level fields that appear on every test case creation and editing form within that project. Whether you need to track which browser a test targets, which sprint it belongs to, a target release date, or an estimated effort score, custom fields give you the flexibility to capture it all without leaving TestKase.
Custom fields are fully integrated into the TestKase ecosystem. They appear in test case forms, are included in CSV exports and imports, can be used for filtering and searching, and their values are preserved in change history for full traceability.
Five field types
Text, number, date, single-select and multi-select fields for your test cases
Project-level scoping
Each project has its own set of up to 10 custom fields
Simple management
Create and delete fields from the project's Custom Fields settings page
CSV import & export
Custom fields are included as additional columns in CSV operations
Field Types
The Custom Fields settings page lets you create five field types:
| Type | Input Control | Description | Example Use Cases |
|---|---|---|---|
| TEXT | Free-text input | Any short free-form value, typed by the tester. | Ticket reference, test owner note, build tag |
| NUMBER | Numeric input | A numeric value. | Story points, effort estimate, retry count |
| CALENDAR | Date picker | A single date. Entered and imported as YYYY-MM-DD. | Target release date, review-by date |
| SINGLE_LIST | Single-select dropdown | A dropdown where users select exactly one option. Use this when the value must be one of a known set of choices. | Browser (Chrome / Firefox / Safari / Edge), Risk level (Low / Medium / High), Test environment (Dev / Staging / Prod) |
| MULTI_LIST | Multi-select dropdown | A dropdown where users can select one or more options. Use this when a test case may belong to multiple categories simultaneously. | Affected modules (Auth, API, UI, Database), Platforms (Windows, macOS, Linux), Tags (Smoke, Regression, E2E) |
The options offered by a SINGLE_LIST or MULTI_LIST custom field are managed on the Field Value settings page, not on the Custom Fields page. A newly created list field starts with no options — add them on Field Value before your team uses it. TEXT, NUMBER and CALENDAR fields have no option list.
Choosing the Right Field Type
The field type cannot be changed after creation, so pick the one that fits before you create the field:
- If users must pick from a fixed set of mutually exclusive options, use SINGLE_LIST. Example: a "Browser" field where each test targets one specific browser.
- If users may need to select multiple values from a set, use MULTI_LIST. Example: an "Affected Modules" field where a single test may touch Auth, API, and UI.
- If the value is free-form, numeric, or a date, use TEXT, NUMBER or CALENDAR. These cannot be constrained to a list of options, so they are less reliable for filtering and reporting.
Create a Custom Field
Creating a custom field adds a new field to the project. Custom fields are created from the project's Custom Fields settings page.
Steps to Create a Field
- Navigate to Settings → Custom Fields in your project. You must be an Owner or Project Admin to manage custom fields.
- Enter a Field Name. This is the label for the field. Choose a clear, concise name (e.g., "Browser", "Affected Modules"). Field names must be unique within the project. The input accepts up to 25 characters.
- Select the Field Type from the dropdown — TEXT, SINGLE_LIST, MULTI_LIST, CALENDAR or NUMBER. The type cannot be changed after creation.
- Click Add. The field is created immediately and added to the project's custom field list.
The create form captures a field name and type only. Everything else is configured elsewhere: the options a list field offers are set on Field Value, and whether the field is required or visible is set on Field Configuration.
Not available: default values, renaming an existing field, changing its type, and drag-and-drop reordering. To change a field's name or type, delete it and create a new one.
The field type cannot be changed after creation, and fields cannot be renamed. To change a field, delete it and create a new one. Deleting a field removes it from the project.
Next Steps
- Field Limits & Management -- Field limits and how custom field management works.
- Using & Managing Fields -- Use custom fields in CSV operations and manage the field lifecycle.
- Best Practices & FAQ -- Guidelines for custom field strategy and answers to common questions.