Using & Managing Fields

Use custom fields in forms, filters, and CSV operations, and manage field lifecycle.

Using Custom Fields

Once custom fields are created, they become part of the daily workflow for everyone on your team. Here is how custom fields integrate into different areas of TestKase.

Custom fields appear on both the Create Test Case and Edit Test Case forms. They are displayed below the built-in fields in the order configured on the Custom Fields settings page. Each field renders with the appropriate input control based on its type:

TEXT fields render as a standard text input.
SINGLE_LIST fields render as a searchable dropdown with the predefined options.
MULTI_LIST fields render as a multi-select dropdown where users can check multiple options.
CALENDAR fields render as a date picker with a calendar popup.
NUMBER fields render as a numeric input that accepts integers and decimals.

All custom fields are optional. Testers can leave them blank if the field does not apply to a particular test case.

Test Case Detail View

Custom field values are displayed on the test case detail page alongside the built-in fields. They appear in a dedicated "Custom Fields" section, making it easy to see all the metadata associated with a test case at a glance.

Filtering by Custom Fields

Custom fields can be used to filter test cases in the test cases list view. When you click the Filter button, custom fields appear as additional filter options below the built-in filters (Priority, Status, Type, Labels, Automation Status).

TEXT — Filter by exact or partial text match.
SINGLE_LIST — Select one or more options to filter by.
MULTI_LIST — Select one or more options; test cases matching any selected option are shown.
CALENDAR — Filter by a specific date or date range.
NUMBER — Filter by exact value or numeric range.

Combine custom field filters with built-in filters for powerful queries. For example, filter by Priority = Critical AND Browser = Safari to find all critical test cases targeting Safari.

CSV Export with Custom Fields

When you export test cases to CSV, all custom fields are included as additional columns in the exported file. The column headers use the custom field names, and the cell values contain the field values for each test case.

For list-type fields, exported values work as follows:

SINGLE_LIST — The selected option label is exported as a plain string.
MULTI_LIST — Multiple selected options are exported as a pipe-separated string (e.g., "Auth|API|UI").

CSV Import with Custom Fields

When importing test cases from a CSV file, you can include custom field values by adding columns with headers that match your custom field names exactly (case-sensitive). The importer will map the CSV columns to the corresponding custom fields.

Title,Priority,Status,Browser,Affected Modules,Story Points,Release Date
"Login with valid credentials",High,Active,Chrome,"Auth|API",5,2026-03-15
"Search product by name",Medium,Active,Firefox,UI,3,2026-03-20
"Checkout with discount code",Critical,Active,Safari,"API|UI|Database",8,2026-04-01

For MULTI_LIST fields in CSV imports, separate multiple values with the pipe character (|). For CALENDAR fields, use the YYYY-MM-DD date format. Values that do not match existing list options will be ignored during import.

Managing Fields

As your project evolves, you may need to edit, reorganize, or remove custom fields. This section covers the full lifecycle of custom field management.

Editing a Custom Field

To edit an existing custom field, navigate to Settings → Custom Fields and click the Edit icon on the field row. You can modify the following properties:

Field Name — Rename the field. The updated name is reflected on all test case forms, the detail view, filters, and CSV exports immediately. Existing test case values are not affected.
Default Value — Change or clear the default. This only affects new test cases created going forward.
List Options (SINGLE_LIST and MULTI_LIST only) — Add new options to expand the list, or remove options that are no longer relevant. You can also rename existing options.

You cannot change the field type after creation. If you need a different type (e.g., switching from TEXT to SINGLE_LIST), you must delete the field and create a new one.

Adding Options to an Existing List Field

If your team needs a new option in an existing SINGLE_LIST or MULTI_LIST field:

Open the field for editing from the Custom Fields settings page.
In the options section, type the new option value and click Add.
Click Save. The new option is immediately available in the dropdown.

Example: Your "Browser" field has Chrome, Firefox, Safari, and Edge. Your team starts testing on Arc Browser. Edit the field, add "Arc" to the options, and save. Testers can now select Arc from the dropdown.

Removing Options from a List Field

When removing an option from a SINGLE_LIST or MULTI_LIST field:

The option is removed from the dropdown and can no longer be selected on new or edited test cases.
Existing test cases that already have the removed option selected retain that value in their data. The value remains visible on the test case detail view.
If a tester edits a test case that has the removed option, they will need to select a different valid option.

Deleting a Custom Field

To delete a custom field entirely, click the Delete icon on the field row in the Custom Fields settings page. A confirmation dialog will appear because this action has significant consequences:

The field is permanently removed from the project.
All values for this field across every test case in the project are permanently deleted.
The field is removed from test case forms, the detail view, and filters.
Future CSV exports will no longer include the deleted field as a column.
This action cannot be undone.

Deleting a custom field permanently removes it and its values from all test cases in the project. This action cannot be undone. If you are unsure, consider disabling the field instead of deleting it. Disabled fields are hidden from forms but their data is preserved.

What Happens to Change History

When a custom field is deleted, the change history entries that reference that field remain in the test case change history. Historical records show the field name and the old/new values, providing an audit trail even after the field no longer exists.