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. Choose Between Single-Select and Multi-Select
Custom fields are list fields — pick the selection mode that matches how the value is used. 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.
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 30 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, or will we want to change its type or options frequently?
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?
Yes, custom fields are included when you export test cases to CSV. Each custom field appears as an additional column in the exported file, with the column header matching the field name. SINGLE_LIST values export as plain strings, and MULTI_LIST values export as pipe-separated strings (e.g., "Auth|API|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
predefined options. For MULTI_LIST fields, separate multiple values with the pipe
character (|). For CALENDAR fields, use YYYY-MM-DD format. Values that do
not match valid options or formats will be ignored during import.
▶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 since fields cannot yet be edited, deleting and recreating is the only way to change a field.
▶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?
Not yet. All custom fields are currently optional — testers can leave them blank when creating or editing test cases. A mandatory-field toggle is on the roadmap (🚧 coming soon). For now, if a field is critical to your workflow, communicate to your team that it should be filled in during test case creation.
▶Can I add or change the options on a list field after creating it?
Not yet — editing a field (including changing its options) after creation is 🚧 coming soon. For now, if you need a different set of options, delete the existing field and create a new one with the options you want.