Custom Fields

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.

Field Types

TestKase supports five custom field types. Each type is designed for a specific category of data input. Choosing the right type ensures your team gets the correct input control and validation when filling in the field on test case forms.

Choosing the Right Field Type

Selecting the correct field type upfront is important because the type cannot be changed after creation. Here are some guidelines:

• If the value is open-ended and varies widely across test cases, use TEXT. Example: a "Component" field where each team names components differently.
• 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 a calendar date, use CALENDAR. Example: a "Release Date" field tracking when a feature is expected to ship.
• If the value is a number you might want to sum, average, or compare, use NUMBER. Example: a "Story Points" field capturing effort estimates.

Create a Custom Field

Creating a custom field adds a new input to the test case creation and editing forms for every test case in the project. Follow these steps to create each type of custom field.

General Steps (All Field Types)

1. Navigate to Settings → Custom Fields in your project. You must have Admin or Manager permissions to access this page.
2. Click the Create Custom Field button. A modal dialog will open.
3. Enter a Field Name. This is the label that will appear on test case forms. Choose a clear, concise name (e.g., "Browser", "Sprint", "Release Date", "Story Points"). Field names must be unique within the project.
4. Select the Field Type from the dropdown. The available types are TEXT, SINGLE_LIST, MULTI_LIST, CALENDAR, and NUMBER. The type cannot be changed after creation.
5. For list types (SINGLE_LIST and MULTI_LIST), add the options that users can select from. See the detailed instructions below for list-type fields.
6. Optionally set a Default Value. When set, this value will be pre-filled on new test cases. Users can override it during creation or editing.
7. Click Save. The field is created immediately and will appear on all test case forms within the project.

Creating a TEXT Field

A TEXT field is the simplest type. After entering the field name and selecting TEXT as the type, you can optionally provide a default value (any text string). Click Save and the field is ready.

Example: Create a field named "Sprint" with type TEXT and a default value of "Sprint 1". Every new test case will have "Sprint 1" pre-filled in the Sprint field, and testers can change it to the current sprint when creating or editing.

Creating a SINGLE_LIST Field

After selecting SINGLE_LIST as the type, the modal expands to show an options editor. You must add at least one option before saving.

1. Type an option value in the input field (e.g., "Chrome").
2. Click the Add button or press Enter to add it to the list.
3. Repeat for each option (e.g., "Firefox", "Safari", "Edge").
4. To remove an option, click the X icon next to it.
5. Optionally select one of the options as the default value from the dropdown.
6. Click Save.

Example: Create a field named "Browser" with type SINGLE_LIST and options: Chrome, Firefox, Safari, Edge. Set "Chrome" as the default. When testers create a test case, they see a dropdown with these four options, pre-selected to Chrome.

Creating a MULTI_LIST Field

MULTI_LIST works identically to SINGLE_LIST for setup, but users can select multiple options when filling in the field on test case forms. The default value can also include multiple selected options.

Example: Create a field named "Affected Modules" with type MULTI_LIST and options: Authentication, API, UI, Database, Notifications. A tester working on a login integration test might select both "Authentication" and "API".

Creating a CALENDAR Field

After selecting CALENDAR as the type, no additional options are needed. The field will render as a date picker on test case forms. You can optionally set a default date.

Example: Create a field named "Release Date" with type CALENDAR. When testers create a test case, they can click the date picker to select the target release date for the feature being tested.

Creating a NUMBER Field

After selecting NUMBER as the type, no additional options are needed. The field will render as a numeric input on test case forms. You can optionally set a default number.

Example: Create a field named "Story Points" with type NUMBER and a default value of 3. New test cases will have Story Points pre-set to 3, and testers can adjust the value based on the actual complexity of the test case.

Next Steps

• Field Configuration -- Configure field limits, defaults, ordering, and enable/disable fields.
• Using & Managing Fields -- Use custom fields in forms, filters, CSV operations, and manage field lifecycle.
• Best Practices & FAQ -- Guidelines for custom field strategy and answers to common questions.