Best Practices & FAQ

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 the Most Specific Field Type

Always prefer a structured field type over TEXT when possible. SINGLE_LIST and MULTI_LIST fields enforce consistency by constraining inputs to predefined options. This makes filtering more reliable and prevents inconsistencies like "chrome" vs "Chrome" vs "Google Chrome".

• If users should pick from a known set, use SINGLE_LIST or MULTI_LIST instead of TEXT.
• If the value is always a date, use CALENDAR instead of TEXT.
• If the value is always a number, use NUMBER instead of TEXT.

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, Type, Labels, Environment, and Automation Status out of the box. For example:

• Do not create a custom "Priority" field — use the built-in Priority field (Critical, High, Medium, Low).
• 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. Set Defaults for High-Frequency Values

If most test cases share a common value for a field, set it as the default. This reduces data entry effort and ensures consistency. Testers only need to change the value when it differs from the norm.

Example: If 90% of your tests run on Chrome, set Chrome as the default for the Browser field. Testers creating Safari-specific tests will change it, but everyone else saves a click.

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. Keep List Options Manageable

For SINGLE_LIST and MULTI_LIST fields, keep the number of options practical. A dropdown with 3-15 options is easy to scan. A dropdown with 40+ options becomes difficult to navigate and may indicate that a TEXT field (with free-form input) would be more appropriate.

• Good: Browser with 5 options (Chrome, Firefox, Safari, Edge, Arc)
• Good: Risk Level with 3 options (Low, Medium, High)
• Consider TEXT instead: a field with 30+ team member names (use Labels or assignee features instead)

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. Disable fields that are no longer actively used, and delete fields that will never be needed again to free up slots for new fields.

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, all values for that field across every test case in the project are permanently and irreversibly deleted. The field is removed from test case forms, the detail view, and filters. Historical change records in the test case history tab are preserved for audit purposes, but the live field and its data are gone. If you want to preserve the data, consider disabling the field instead of deleting it.

▶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, edit, and delete custom fields?

Custom field management (create, edit, delete, reorder) is available to users with Admin or Manager roles on the project. Regular team members can view and fill in custom field values on test cases but cannot modify the field definitions themselves. See the User Permissions guide for details on role-based access.

▶Can I make a custom field required?

Currently, all custom fields are optional. Testers can leave them blank when creating or editing test cases. If a field is critical to your workflow, set a default value so that new test cases always have a value, and communicate to your team that the field should be filled in during test case creation.

▶What happens if I add a new option to a list field?

The new option becomes immediately available in the dropdown on test case forms. Existing test cases are not affected — they retain their current selected value. The new option is available for selection on both new and existing test cases going forward.