TestOrchestrator

Field Types

When creating a field you choose a type. The type determines the input control shown to users and the kind of data it stores. Field type cannot be changed after the field is created.

Field type is permanent. Once a field is saved, its type cannot be changed. Choose carefully — changing a field type would corrupt existing stored values.

Available types

The type picker names each type in words. The stored value the API and imports use is given here alongside it, because that is what appears in an export or a payload.

Type Stored as Input shown to users Offered on
Long text TEXT Rich-text editor — long-form prose with formatting and inline images Test case, Test run, Exploration
Short text STRING Single-line text input Test case, Test run, Exploration
Whole number INTEGER Whole number input Test case, Test run, Exploration
Decimal number FLOAT Decimal number input Test case, Test run, Exploration
Date DATE Date picker Test case, Test run, Exploration
Checkbox CHECKBOX Boolean toggle (on/off) Test case, Test run, Exploration
Link LINK URL / hyperlink input. A value typed without a scheme is saved with https:// — see Link fields. Test case, Test run, Exploration
Dropdown DROPDOWN Single-select from a list of options Test case, Test run, Exploration
Multi-select MULTI_SELECT Multiple selections from a list of options Test case, Test run, Exploration
Steps STEPS Step-by-step structured input with four columns Test case only

TEXT versus STRING

Both hold words, but they behave differently everywhere they are shown. Choosing the right one matters more than it looks.

  • TEXT is unbounded prose — a rich-text editor with formatting and pasted images. Because a paragraph cannot be truncated into a 130 px cell without becoming useless, a TEXT case field is never offered as a display-property chip, a table column, a grouping key, a filter facet, or a side-rail row inside a test run. It renders instead as its own prose block in the main column of the case, in reading order beside Description, Preconditions, and Steps — read-only there, because the value belongs to the repository case.
  • STRING is a single-line, bounded value. It fits a column and reads fine as a rail row, so it stays available as a display property and a table column.

As a result field the roles differ again: a TEXT result field is an editable rich-text box the tester fills in per execution, not inherited content. It is also the only result-field type that accepts images — a tester can paste a screenshot straight into it and it uploads with the result. STRING and the other single-line types carry a plain value.

Why CHECKBOX cannot be required

A checkbox has no empty state — unchecked is a real answer, not a missing one — so marking one required would be a constraint that can never actually gate anything. The admin screen blocks it and the server rejects it.

When you need a tester to consciously answer, use a Yes/No DROPDOWN and mark that required instead: a dropdown has a genuine unset state, so it gates consistently on every way of recording a result. See Required result fields.

A dropdown or multi-select field needs a list of options before anyone can pick from it. That list is authored in the field editor itself: a Dropdown options (or Multi-select options) panel sits directly under Identity, with the running count in its heading and an Add option button.

A field with no options cannot be saved. The panel says so — “A dropdown with no options cannot be filled in” — and the save button stays out of reach with “Add at least one option — a field with none cannot be filled in.” on hover.

Each option row carries:

  • An optional icon and colour — the compact picker at the head of the row, from the same set used for field icons. Leave it and the option renders as plain text.
  • The label — one input, and the only text you author. This is what users see.
  • Reorder and remove — arrows to move the option up or down, and a bin to take it out. The number at the left is its position.

The stored value is minted once and then left alone. An option’s stored value is derived from its label when the option is created and does not change when you rename it — every case and result already recorded against that option keeps pointing at it. Hover an option to see the value it is stored as. Renaming an option is therefore safe; removing one is not, because nothing then resolves the recorded value to a label.

Option icons follow the value everywhere it is rendered — including the compact chips in a run’s result history. An option with a colour but no icon shows a small colour dot; an option with neither shows plain text. The icon comes from your configuration, so the same option looks the same on every surface.

A project may still hold an option list of its own. Lists authored per project before this editor existed are preserved, and the override group that holds one says so in place: “This project keeps its own option list (n options)”. Editing the options above replaces it on save, and the note changes to say that while you are editing. See Project Overrides.

Steps field

The Steps type creates a structured, multi-column input — typically the step, its data, the expected result, and notes. It is offered on the Test case fields tab only; a run result and an exploration record against a case rather than re-describing its structure, so the type is not in their pickers at all.

A steps field has four fixed slots. The field editor gives them a Step columns panel — headed Four fixed slots — where you can:

  • Rename a column
  • Tick or untick it, to show or hide that column on every step
  • Move it up or down

The tick states its effect rather than its state: “Shown — testers see a Data column on every step. Untick to hide it.”, or “Hidden — tick to give every step a Data column.”

A project may still hold its own step columns. As with option lists, per-project column sets authored earlier are preserved, and the override group holding one says “This project keeps its own step columns (n columns)”. Editing the panel above replaces them on save.