Test Case Fields

Two of the three tabs in Settings → Fields cover execution: Test case fields appear when a test case is written or updated, and Test run fields are filled in during execution to capture outcome data.

Test case fields and test run fields

They are separate tabs and separate families — a field defined on one is not offered on the other. The distinction is what the value describes:

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 panel 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 panel — 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.

Carrying a value forward

Carry forward is a switch inside the same Presentation panel, off by default: “Pre-fills with the value from the previous result in the run.” 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 a long-text result field. The switch is locked, reading “Not available for a long-text result — a written answer is not something to pre-fill”, and the runner refuses to seed one under any circumstances. A long-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

Each tab is one table. Test case fields and Test run fields are now separate tabs rather than two sub-lists on one, so a link to either opens the list you meant. Both show the same seven columns:

The search box filters by label or system name. Click the Label, System name, Type or Status header to sort by it, ascending and descending; the two count columns are not sortable.

Create a field

1. Open Settings → Fields, choose the Test case fields or Test run fields tab, and click New field. The editor opens as its own page, so the URL is linkable and Back works.
2. Under Identity, enter a Label — “What testers see next to the input.” The System name fills itself in from it and can be edited until the first save.
3. Pick a Type. See Field Types. It is locked after creation.
4. Leave Enabled on, or switch it off to define the field without exposing it yet.
5. For a dropdown or multi-select, author the options in the panel that appears below Identity. For a steps field, set the four step columns.
6. For a test run field, fill in Presentation if you want an icon, unit, placeholder, help text, or carry-forward.
7. Under Project assignment, say which projects offer the field and whether it is required there. See Project Overrides.
8. Click Create field on the bar at the foot of the page.

Options are authored here, not in a separate overrides dialog. A dropdown or multi-select gets its list from the Dropdown options / Multi-select options panel in this editor, and cannot be saved without at least one option. See Dropdown and multi-select options.

System name rules: lowercase letters, numbers and underscores, starting with a letter (e.g. browser_version, chrome_129) — 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: capitals are lowered, anything else becomes an underscore, and a name that would not start with a letter is prefixed f_ — “2FA verified” becomes f_2fa_verified. The system name is permanent.

Edit a field

Click the field’s label in the list, or Edit field… in the row menu, to open the same editor. The save bar appears at the foot of the page once something has changed, names the field, and offers Discard; leaving with unsaved changes asks first.

Everything is editable except the two identity values the rest of the workspace refers to:

• Type is locked — “Locked after creation. Create a new field if you need a different type.”
• System name is shown but locked — “Locked after creation — integrations reference it.” It stays on screen rather than disappearing, because a value the API uses is read far more often than it is changed.

The editor URL names the family as well as the field. A test case field lives at …/admin/fields/case/<id>, a test run field at …/admin/fields/result/<id> and an exploration field at …/admin/fields/session/<id>. A link that leaves the family out does not resolve, so a bookmarked editor cannot open the wrong kind of field. A link to a field that no longer exists says so and offers a way back.

Enable and disable a field

Use Enable field / Disable field in the row menu, or the Enabled switch in the editor — “Disabled fields keep their history but appear nowhere.” Disabling hides the field from new test cases and results but preserves every stored value; enabling restores it. The toast for the row-menu toggle carries an Undo.

Delete a field

Choose Delete field… from the row menu. The dialog names the field, says “The field definition is removed from the workspace”, and spells out the reach of the change — which projects and how many templates stop offering it, and that disabling is the safer route.

A field that any template uses asks you to type DELETE. The confirm button stays out of reach until you have typed the word. A field no template carries is confirmed with a single click. There is no undo either way.

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.

Values on cases whose template no longer carries the field count too — they are hidden, not gone. When some of the blocking values are hidden like that, the refusal adds how many, so a field nobody can see still explains itself: This field has values recorded on test cases. It can’t be deleted while those values reference it. 2 of these values are on cases whose template no longer shows the field. Disable the field instead to stop offering it. Disabling remains the route for a field you have finished with.

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 assignments, 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 switch 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 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. Groups are edited in place and committed by the same save as the rest of the field.

For full detail, see Project Overrides.