Best Practices & FAQ
Guidelines for custom field strategy and answers to common questions.
Best Practices
Custom fields are most effective when they are thoughtfully planned and consistently used across your team. Here are guidelines to help you get the most out of custom fields.
1. Use Clear, Concise Field Names
Field names appear on test case forms, in filters, and in CSV exports. Keep them short and descriptive so their purpose is immediately obvious. Avoid abbreviations that only some team members understand.
- Good: "Browser", "Sprint", "Story Points", "Release Date"
- Avoid: "Brwsr", "SP", "Field1", "Custom Data Tracking Field for Browser Info"
2. Prefer List Fields Over Free Text
Five field types are available — TEXT, NUMBER, CALENDAR, SINGLE_LIST and MULTI_LIST. Where the value comes from a known set, prefer a list field. List fields enforce consistency by constraining inputs to options, which makes filtering more reliable and prevents inconsistencies like "chrome" vs "Chrome" vs "Google Chrome".
- If a test case should have exactly one value from a known set, use SINGLE_LIST.
- If a test case may have several values at once, use MULTI_LIST.
- Reserve TEXT for genuinely free-form values, and use NUMBER or CALENDAR when the value is numeric or a date.
3. Avoid Redundant Fields
Before creating a custom field, check whether the data you want to capture is already covered by a built-in field. TestKase provides Priority, Status, Labels, Environment, and Automated out of the box. For example:
- Do not create a custom "Priority" field — use the built-in Priority field.
- Do not create a custom "Tags" field — use the built-in Labels feature, which supports multiple labels with search and filtering.
- Do not create a custom "Test Environment" field — use the built-in Environment field.
4. Name Fields for Clarity
Since a field's name cannot be changed after creation, pick a clear, stable name up front (up to 25 characters). Consistent naming makes fields easier to recognize on forms, in filters, and in CSV exports.
5. Plan Your Field Strategy Before Creating
With a maximum of 10 custom fields per project, plan carefully. Discuss with your team which metadata is truly valuable. Ask yourselves:
- Will this field be used by the majority of test cases, or only a handful?
- Will we use this field for filtering or reporting?
- Can this data be captured by labels or the built-in Environment field instead?
- Is this field stable? Its options can be changed later on the Field Value page, but its name and type cannot.
6. Reserve Fields for Categorical Data
List fields work best for categorical data with a manageable set of values — a browser, a risk level, an affected module. For large, free-form, or per-person data (like 30+ team member names), prefer the built-in Labels or assignee features instead of a custom field.
7. Review and Clean Up Periodically
As your project evolves, some custom fields may become obsolete. Review your custom fields quarterly or when your team's workflow changes significantly, and delete fields that will never be needed again to free up slots for new fields (there is a 10-field-per-project limit).
8. Document Your Custom Fields for the Team
When onboarding new team members, make sure they understand what each custom field is for and what values to use. A short internal guide explaining "Browser = the browser this test should be executed in" and "Story Points = effort estimate using Fibonacci scale" eliminates confusion and ensures consistent data entry across the team.
FAQ
▶Are custom fields included in CSV export?
Only if the custom field's column is currently visible in the test case table. The export writes
exactly the columns shown in the table, so make the custom field visible before exporting. When
included, the column header matches the field name; SINGLE_LIST values export as plain strings, and
MULTI_LIST values export as a comma-separated string in a quoted cell (e.g., "API, Auth, UI").
▶Can I import custom field values via CSV?
Yes. When importing a CSV file, add columns with headers that exactly match your custom
field names (case-sensitive). For SINGLE_LIST fields, the cell value must match one of the
configured options. For MULTI_LIST fields, separate multiple values with a comma and quote the
cell — for example "Auth, API". The pipe character is not a separator. For CALENDAR fields, use
YYYY-MM-DD format. A value that does not match the field's configured options produces a row
error on the Preview & Validate screen and that row is skipped.
▶Can I filter test cases by custom fields?
Yes. Custom fields appear as additional filter options in the test cases list view. Click the Filter button to see all available filters, including your custom fields. You can filter by text match, selected list options, date ranges, or numeric values depending on the field type. Custom field filters can be combined with built-in filters for precise queries.
▶Can I change a field's type after creation?
No, the field type cannot be changed after creation. This is because each type stores data differently (text vs. list references vs. dates vs. numbers), and converting between types could result in data loss. To change the type, delete the existing field and create a new one with the desired type. Note that deleting a field permanently removes all its values from every test case in the project.
▶What happens to existing data when I delete a custom field?
When you delete a custom field, it is removed from test case forms, the detail view, and filters, and its values are no longer associated with a field. Historical change records in the test case history tab are preserved for audit purposes. This action cannot be undone, and deleting and recreating is the only way to change a field's name or type.
▶Do custom fields appear when executing test cases in a test cycle?
Custom field values are visible on the test case detail view within a test cycle, giving testers context about the test case metadata. However, custom field values are set on the test case itself (not per-execution), so they are read-only during test cycle execution. To update a custom field value, edit the test case directly from the Test Cases section.
▶Are custom fields shared across projects?
No, custom fields are scoped to individual projects. Each project has its own independent set of up to 10 custom fields. This allows different projects to have different fields tailored to their specific needs. If you want the same fields across multiple projects, you must create them separately in each project.
▶Who can create and delete custom fields?
Custom field management (create and delete) is available to Owners and Project Admins. Regular team members can view and fill in custom field values on test cases but cannot create or delete the field definitions themselves. See the User Permissions guide for details on role-based access.
▶Can I make a custom field required?
Yes. Go to Settings → Field Configuration, find the custom field in the list and turn Mandatory on. Test cases can then not be saved until that field has a value. Note that a mandatory field is forced visible — you cannot hide a field while it is mandatory. See Field Configuration.
▶Can I add or change the options on a list field after creating it?
Yes. The options a SINGLE_LIST or MULTI_LIST custom field offers are managed on the
Field Value settings page — add a value by
typing it and pressing Enter, remove one with the × on its tag, then click Submit. The field's
name and type still cannot be changed after creation; for those, delete the field and create a
new one.