Exploration Fields
The Exploration fields tab in Settings → Fields manages fields for explorations. They capture structured metadata on an exploration — things like the testing environment, the session goal, or the device under test.
How exploration fields differ
| Test case / test run fields | Exploration fields | |
|---|---|---|
| Applies to | Test cases and recorded results | Explorations |
| Tab | Test case fields, Test run fields | Exploration fields |
| Steps type | Test case fields only | Not offered |
| Presentation panel | Test run fields only | Not offered |
| Template usage | Test case templates | Exploration templates |
Create an exploration field
- Go to Settings → Fields, choose the Exploration fields tab, and click New field. The editor opens as its own page.
- Enter a Label. The System name is derived from it — you can edit that before saving.
- Pick a Type. All types except Steps are offered. See Field Types.
- For a dropdown or multi-select, author the option list in the panel below Identity.
- Under Project assignment, say which projects offer the field and whether it is required there.
- Click Create field.
System name rules: lowercase letters, numbers and underscores, starting with a letter — the pattern is^[a-z][a-z0-9_]*$, and it must be unique in the workspace. The box auto-fills from the label and tidies itself as you type, prefixingf_where the result would not start with a letter. The system name is permanent.
Edit an exploration field
Click the field’s label in the list, or Edit field… in the row menu. Everything is editable except the Type and the System name, which are shown but locked with the reason. The save bar appears at the foot of the page once something has changed.
Exploration fields have no Presentation panel. The icon, unit, placeholder, help text and Carry forward controls described under test run fields are offered for result fields only — an exploration field’s editor does not show them.
Enable and disable an exploration field
Use Enable field / Disable field in the row menu, or the Enabled switch in the editor. Disabling hides the field from new explorations but preserves every previously stored value.
Delete an exploration field
Choose Delete field… from the row menu. The dialog names the projects and templates that stop offering the field, and suggests disabling it instead to keep the history. A field any template uses asks you to type DELETE before the confirm button becomes available.
A field with values recorded on explorations cannot be deleted. The server refuses the delete rather than removing that evidence, and says so: This field has values recorded on explorations. It can’t be deleted while those values reference it. The message arrives as an error toast and the confirmation closes. There is no force option and no administrator override — the delete is refused, not failed, so there is nothing to retry.
Explorations keep no frozen snapshot of their field values the way a closed run does, which is why the refusal here is unconditional.
Deleting a field that has no recorded values is still permanent. The definition, its project assignments, and its template links go immediately, with no undo. A value that was blanked out on an exploration may still count as recorded, because clearing the box does not always remove the underlying row.
Disable instead of deleting. The Enabled toggle hides the field from new explorations while preserving every stored value, and it works whether or not values exist.
Project assignment
The last panel of the editor decides which projects offer the field, whether it is required in each of them, and what it is pre-filled with.
For full detail, see Project Overrides.
"Can I use the same field for both cases and sessions?" No — the three tabs are separate families. If you need the same data captured in both contexts, create two fields: one on Test case fields and one on Exploration fields.