product: maestro audience: test-developer authority: normative

YAML Schema Reference

Top-level structure

test:                          # REQUIRED root key
  name: "string"               # REQUIRED — display name, stored in every result record
  version: "1.0.0"             # REQUIRED — semantic version, bump before every deployment
  device: "string"             # optional — DUT identifier

Version format rule

test.version must be a quoted string in full three-part semantic version format: "MAJOR.MINOR.PATCH".

Always quote the value and always increment before deploying — the version is stored with every test result and is the only field that lets you correlate a result record to a specific revision of the test definition.

Tip: validate_yaml will reject a missing version but does not currently check the format. Use the three-part rule above to avoid ambiguous result records.

Top-level fields (continued)

test:
  name: "string"
  version: "1.0.0"
  device: "string"             # optional — DUT identifier

  tags:                        # optional — key-value metadata (JSONB in DB)
    ProductId: "PCB-100"
    ProductRevision: "Rev C"

  required_tags:               # optional — keys that must be non-empty before Start
    - ProductId

  variables:                   # optional — initial variable values
    var_name: value

  setup:                       # optional — steps run before main steps
    - { step }

  steps:                       # REQUIRED — main test body
    - { step }

  teardown:                    # optional — steps run after main steps
    - { step }

  policy:                      # optional — test-level defaults
    on_step_failure: "abort"   # "abort" | "continue" (default: "abort")
    timeout: 300               # overall test timeout in seconds

required_tags

required_tags: is an optional list of tag key strings. The Start Test button on the Test Monitor page stays disabled until every listed key has a non-empty value.

test:
  name: "Board Functional Test"
  version: "1.0.0"
  tags:
    ProductId: ""
    BatchId: ""
  required_tags:
    - ProductId
    - BatchId
  steps:
    - name: "Measure 3V3 Rail"
      ...

• Required keys render in an amber-highlighted section above optional tags.
• Well-known keys (ProductId, ProductRevision, BatchId, Notes) render as dedicated labelled inputs. Any other key gets a dynamic text input.
• When connected to MES, the MES system populates required_tags keys before the operator sees the Start button.
• All tags are accessible in steps as {{exec.tag.<Key>}}.

Default values for required tags

A required tag key may be given a non-empty default value in the tags: section. When the operator selects that test file the Start Test dialog pre-fills the corresponding input with the default. The operator can still edit the value before starting.

tags:
  ProductId: "ESH10000633"      # pre-filled — operator can edit
  ProductRevision: "R1"         # pre-filled — operator can edit
  AccordionA2_SN: ""            # blank — operator must scan/type
  NTop_SN: ""                   # blank — operator must scan/type
  FixtureLink_SN: ""
  FE_SN: ""

required_tags:
  - ProductId
  - ProductRevision
  - AccordionA2_SN
  - NTop_SN
  - FixtureLink_SN
  - FE_SN

Tip: Use defaults for values that are the same across most runs (e.g. product ID, board revision) and leave serial-number fields empty so the operator is forced to scan each barcode individually.

Step fields — complete reference

Identity and routing

.NET runner fields

Python runner fields

Sequence fields

Data flow

Timing

Runtime control

Post-execution

Prompt fields