Test Case Fields

The TEST CASES tab in Admin → Fields manages fields for test cases and test results. Test Case Fields appear when creating or editing a test case. Test Run Fields are filled in during test execution to capture outcome data.

Test Case Fields and Test Run Fields

Both types live on the TEST CASES tab and are managed the same way. The distinction is in how they are used:

How Test Run Fields behave during execution

A Test Run Field is not a second set of case properties — it describes one execution. Three consequences are worth knowing before you define one:

• They are template-scoped. A result field reaches a tester through the template of the case being executed, so two cases in the same run can present different result forms — or none.
• Values attach to the result, not the case. Each recorded result carries its own set of values, and the form starts empty for the next one — unless you switch on Carry forward. Ten results on one case mean ten independent sets, each readable in that case’s result history.
• All types except STEPS. Nine of the ten field types are available; STEPS is not offered for results, because steps are recorded first-class against the case.

See Result fields for what a tester sees, and Making a field required for the rules around requiring one.

Presentation — how a result field looks to a tester

A Test Run Field’s editor carries a Presentation section that a Test Case Field does not. It decides how the field is dressed in the result form; every part is optional, and leaving it empty gives you the plain default.

Presentation is offered on Test Run Fields only. Test Case Fields and Exploration Fields have no Presentation section — the result form is the only surface that renders these.

All four are checked on the server as well as in the browser, so an over-long unit or help text is rejected outright rather than quietly trimmed.

Behaviour — carrying a value forward

Below Presentation sits a Behaviour section with a single Carry forward toggle, off by default. Switch it on and the field starts from the value on the same case’s previous result in the same run — useful for something that rarely changes between executions, like a build number or a device. The tester can always overwrite the seeded value before saving.

The seed is scoped tightly. It comes from the previous result recorded against that case in that run — never from a different case, never from an earlier run, and never from whatever the tester last typed somewhere else. A case being executed for the first time in a run starts empty as usual.

Carry forward is not available for TEXT result fields. The toggle is disabled on a TEXT field and the runner refuses to seed one under any circumstances. A TEXT result field is where a tester writes what actually happened this time; pre-filling it with the previous execution’s findings is the one thing that would make a result form actively dangerous.

The fields list

Test Case Fields and Test Run Fields are displayed in separate sub-lists on the TEST CASES tab. Each list shows the same columns:

Use the search box to filter by label, system name, or type. Click any column header to sort — ascending and descending.

Create a field

1. Go to Admin → Fields → TEST CASES and click New Field.
2. Enter a Name. The System Name is auto-generated from it — you can edit that before saving.
3. Select a Type. See Field Types for all options. Type cannot be changed after saving.
4. Choose whether this is a Test Case Field or a Test Run Field.
5. For a Test Run Field, optionally fill in Presentation and Behaviour.
6. Set whether the field applies to All Projects or Selected Projects.
7. Click Save.

Options are not defined here. A DROPDOWN or MULTI_SELECT field gets its option list from a project override, not from this modal — there is no global option list. Save the field first, then open Overrides on its row to author the options. See DROPDOWN and MULTI_SELECT options.

System Name rules: Must start with a lowercase letter, and after that may contain lowercase letters, digits, and underscores (e.g. browser_version, chrome_129) — the pattern is ^[a-z][a-z0-9_]*$, up to 255 characters, and it must be unique in the workspace. The box auto-fills from the Label and tidies itself as you type: capitals are lowered, anything else becomes an underscore, repeats and leading or trailing underscores are trimmed, and a name that would not start with a letter is prefixed f_. System Name is permanent — it cannot be changed after the field is created.

Edit a field

Click the Edit button on any field row to open the edit modal. You can change:

• Name (the display name)
• Enabled state
• Project assignment scope (All Projects or Selected Projects)
• For a Test Run Field only: icon and colour, unit, placeholder, help text, and the Carry forward toggle — all saved together with the rest

Field type and System Name cannot be changed after creation; the Type control is disabled in edit mode and the System Name box is not shown at all. Option lists are edited under Overrides, not here.

Enable and disable a field

Toggle the Enabled switch on the list directly — you do not need to open the edit modal. Disabling a field hides it from new test cases or results but preserves all previously stored values. Enabling it again restores visibility immediately.

Delete a field

Click the Delete button on the field row and confirm the dialog. The dialog warns that the action cannot be undone and suggests disabling the field instead to keep historical information.

A field carrying recorded values cannot be deleted at all. The server refuses the delete rather than cascading those values away, so the dialog’s warning only ever applies to a field nothing has been recorded against. The refusal names the evidence it is protecting:

• Values on test cases — This field has values recorded on test cases. It can’t be deleted while those values reference it.
• Recorded test results — This field has recorded test results. It can’t be deleted while results reference it.
• Both — This field has values recorded on test cases and recorded test results. 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, no administrator override, and nothing to retry — this is a deliberate refusal, not a failure.

Deleting a field that has no recorded values is still permanent. The field definition, its project overrides, and its template links go immediately, and there is no undo. A field is only considered clear when no value row exists for it anywhere in the workspace — a value that was blanked out on a result or an exploration may still count, because clearing the box does not always remove the underlying row.

Disable instead of deleting. The Enabled toggle hides the field from new test cases and results while preserving every stored value, and it works whether or not values exist. That is the route to take for a field you have finished with but whose history you still want.

Project Overrides

Click the Overrides button on a field row to configure how that field behaves in specific projects — making it required, changing its default value, restricting its options, or customising STEPS subfield slots.

For full detail, see Project Overrides.