# Test Sequences

## What is it?

A test sequence bundles the test cases that a test object runs through, one
after another or in parallel — including schedule, station assignment, and
dependencies between test cases. Every sequence belongs to one project and
optionally to one test object.

A sequence's **start time** must either be fixed manually or derived from at
least one dependency on another sequence — one of the two is required, or the
sequence cannot be created. The **end time** is always determined by the
sequence itself — it results from the duration and scheduling of its planned
test cases and can no longer be overridden manually.

Reusable sequence templates (`isTemplate: true`) are managed under "Test
cases & sequences" in the "Templates sequences" tab — next to it,
"Templates test cases" holds the individual test case definitions. Both tabs
intentionally show only templates; search and pagination run server-side via
the URL (`?q=&page=&tab=`). An actual running sequence of a project always
lives on that project's page.

## How to use it

- **Creating a new sequence:** On the project page, "New sequence" button. If
  sequence templates already exist, the button opens a dropdown with two
  options: "Create empty sequence" (name only, then add test cases one by
  one) or "Create from template" (choose a template and the test object it's
  for — the sequence is created immediately with the full set of test cases
  defined in the template). Without any templates, the dropdown is skipped
  and the button creates an empty sequence directly.
- **Set it at creation time, not only afterward:** Both "Create empty
  sequence" and "Create from template" ask, in the same dialog, for a start
  time (or a dependency on another sequence), dependencies on sequences
  already in the project, and — in the template dialog — the station
  assignment per test case. The station assignment there is pre-filled from
  the template and can be overridden per test case right while cloning,
  instead of touching every row afterward on the sequence page.
- **Creating a sequence template:** Under "Test cases & sequences" → the
  "Templates sequences" tab, "New template" button. A template can then be
  filled with test cases like a regular sequence and later applied to any
  number of projects via "Create from template".
- **Scheduling test cases:** On the sequence page, a table shows all of the
  sequence's test cases with status, station, start, end, duration, and
  dependencies — station, start, and dependencies can be changed directly in
  the row. "Add test case" opens a side panel form (usable independently of
  other open dialogs, e.g., to create a new station right there).
- **Overriding working-hours mode per test case:** Every test case has an
  "Runs unattended" checkbox when created/edited. If checked, the duration
  counts continuously by the calendar — weekends and end of workday don't
  matter (climate chamber, vibration, or other soak tests). If unchecked, the
  test case is only scheduled within the lab working hours set under Settings
  → Calendar, and stretched over evenings/weekends (e.g., a 6-hour manual
  measurement). This only applies **if** the organization is set to "Working
  hours only" there — with "Continuous (24/7)" (default), every test case
  counts by the calendar anyway, and the checkbox has no visible effect. See
  `kalender` for details on the org-wide mode.
- **Bulk-editing multiple test cases:** Select rows in the table (header
  selects all) — a bar at the bottom of the screen then lets you set a status
  or assign a responsible person to all selected test cases at once.
- **Editing a test case from a template:** The pencil on a test case inside a
  template (the "<template> — test cases" dialog or the template detail page) opens
  the same full form as under "Templates test cases" — with all fields,
  expected measurements, qualifications and allowed stations, pre-filled with
  the current state. You can also change the test case's dependency within the
  template there. The complete test case is always saved; measurements and
  assignments you did not change are kept. The change creates a new version of
  the test case and applies to every template and sequence in which it is not
  yet completed.
- **A project's test sequences:** On the project page, a table lists all
  sequences with status, number of test cases, start, end, duration, and
  assigned test object; edit, delete, and dependencies sit as actions at the
  end of the row.
- **Double bookings on a station:** If the schedules of multiple sequences
  overlap on a station, this can be resolved directly on the station detail
  page — by moving to a different station or rescheduling. Details under
  `pruefstaende`.
- **Schedule columns:** The schedule shows fixed columns to the left of the
  chart for start, end, duration, and status — both per sequence and,
  expanded, per test case. On narrow screens, duration and status collapse
  first; name/start/end stay visible.
- **Draft test cases show up immediately in the schedule:** A test case just
  added in the editor but not yet saved appears immediately as a dashed,
  yellow-highlighted row in the schedule ("unsaved") — even before saving.
  This lets you assess the impact on the schedule before saving.
- **Unsaved changes warning:** While the test case editor has unsaved
  changes, the app asks for confirmation before leaving the page — whether
  via a link inside the app or by closing/reloading the tab. Changes are
  only lost after confirming "Leave".
- **Revision history:** Every save of a sequence — whether via the sequence
  form or the test cases themselves — automatically creates a new revision.
  The revision history only appears once at least one revision exists. Every
  revision shows **who** created it and **when**; for revisions from before
  this feature existed, it shows "—". A note can be attached to a revision
  when saving; it can't be changed afterwards — notes are an immutable
  record.
- **Restoring a revision:** Via "Restore" on a revision in the history, you
  can bring back that point in time — name, schedule, test cases, station
  assignment, and dependencies. **Already recorded results and statuses are
  never reset**: test cases that were added after the chosen revision and
  already have an execution, a result, or measurements are kept — the
  restoration reports this as a note. Test cases missing from the revision are
  re-created. Older revisions without a full snapshot only restore name and
  description; the confirmation dialog shows this beforehand.
- **CSV/Excel import and export of test case templates:** On the "Test case
  templates" tab, "Export" delivers every test case definition as CSV or
  Excel (.xlsx). "Import" reads the same layout back in — unlike test
  objects, stations, and equipment, an import here **always creates new**
  test case definitions, even when the ID column is filled in: test case
  definitions are versioned, and an update via import would either delete
  existing measurements or create a new revision on every re-import. Manage
  existing test cases via "Edit" instead. Rows without a name are skipped.
  After selecting a file, a preview opens first — nothing is saved yet. It
  shows, per row, whether a new test case will be created or the row
  skipped. Only clicking "Import entries" writes the data; "Cancel" discards
  the file without any changes.
- **Images for the test case description:** You can attach one or more
  images, e.g. wiring diagrams or explanatory sketches — either right in the
  "New test case" form (images upload only after the test case is created)
  or afterwards on the test case detail page ("Test case templates" tab →
  click a test case) under "Images". PNG or JPG, up to 5 MB per image, up to
  10 images per test case; a title is required, a description is optional.
  The images belong to the library definition itself, not to a single run —
  they show up on every sequence that uses this test case.

## A test case's status flow

A test case's status follows a fixed sequence. You can't choose every status
from every other — the status is your quality record and is meant to
document the process, not replace it.

```
Pending ──▶ In progress ──▶ (execution) ──▶ Passed / Failed
   │               │                                  │
   └──▶ Skipped / Aborted                              │
                │                                       │
                └──▶ Pending                In progress ◀┘  (re-check)
```

- **Via the status menu** (badge on the detail page, board, Gantt, list) you
  only set *process steps*: start, skip, abort, resume. The menu only ever
  shows what's possible from here.
- **"Passed" and "Failed" aren't in the status menu.** A test result is only
  created via "Test case executed", because that's where examiner, time
  range, actual result, and measurements belong. A result without that
  evidence wouldn't be proof.
- **Re-checking:** An assessed test case goes back to "In progress", not
  "Pending" — the already documented execution is kept.
- **Skipped/Aborted** means "not tested". If you want to test such a test
  case after all, resume it first ("Pending"); only then can it be executed.
  This keeps the reversal visible in the history.
- **There's no "Paused" anymore.** The state had no consequence: it blocked
  nothing and required no justification. A test case that's currently stuck
  stays "In progress" — write a note explaining why. This also eliminates
  pausing projects and sequences.
- **Bulk changes:** Selecting multiple test cases only allows setting process
  steps. If the selection includes test cases for which the chosen change
  isn't possible, the rest are changed and the number of unchanged ones is
  reported.

## Recording execution and nonconformances

- **Recording execution:** Via "Test case executed" on the test case detail
  page, the test result (passed/failed), actual outcome, actual time range,
  who performed it, and all actual values of the measurements defined for the
  test case are recorded in one step. All these fields are required — an
  execution without complete evidence can't be saved. The test result is
  never pre-selected: it must be consciously clicked on every initial record,
  so "Passed" can never slip through as a leftover default. The actual end
  must also be on or after the actual start — otherwise a note appears and
  the dialog can't be saved.
- **The assignee switches to whoever performed it:** On the initial record,
  the person selected in the dialog automatically becomes the test case's
  assignee — the section that reads "Assigned to" before execution shows
  "Executed by" from then on, and can still be changed manually afterwards.
- **Recording a nonconformance at the same time:** In the same dialog,
  "Record nonconformance" can be checked regardless of the test result — even
  for "Passed", e.g. for an observation that doesn't change the outcome. This
  creates a nonconformance note tied to exactly this test step — it appears
  on the test case detail page and later in the test report right next to
  this test case. Afterwards, this can also be done via the "Nonconformances"
  section on the test case detail page, where multiple notes for the same
  test case can also be recorded.
- **A failed test case without a nonconformance is flagged.** The
  "Nonconformances" section points this out as long as none has been
  recorded.
- **Adjusting after the initial record:** Once an execution has been
  recorded, the same button ("Adjust results") instead opens "Adjust recorded
  results". Whoever originally performed it stays visible unchanged; it also
  records who made the correction and when.
- **Test conditions and external provider (optional):** The same dialog has
  two optional fields for the ISO/IEC 17025 test report: "Test conditions
  (e.g. temperature, humidity)" — such as "23 °C, 45 % RH" — and "Performed
  externally by (provider)" if the result doesn't come from your own
  laboratory. Both appear on the test case detail page below the actual
  result and are prefilled with the previous value in "Adjust results";
  clearing a field there removes it.
- **Execution photos:** The "Photos" section on the test case detail page
  lets you upload any number of photos (PNG or JPG, up to 5 MB each).
  "Choose photo" opens a dialog with a title (required), an optional
  description, and the file picker — the upload happens once you confirm in
  the dialog, not as soon as you pick a file. This works regardless of the
  test case's status and can be done at any time after execution, too.
  Depending on the setting, these photos appear in the report either
  directly on the test case page or collected in an appendix (see
  `berichte`).

## Expected measurements and automatic evaluation

- **Defining expected measurements:** In the test case form (test case
  library, or "Add test case" within a sequence) you define any number of
  expected measurements per test case: channel name, unit, nominal value, and
  optional limits (min/max). The channel name is the key — it must match the
  name under which the station delivers its readings, and may only occur once
  per test case. Leaving limits empty means "open on that side"; an inverted
  band (min > max) can't be saved. Limits deliberately live on the test case,
  not the station — the same station can deliver the same physical channel
  with different target bands for different test cases.
- **Measurement uncertainty U (k=2):** For each quantity you can optionally
  enter the expanded measurement uncertainty in the quantity's unit (column
  "U (k=2)", not negative). It is stated in the test report next to the
  result and affects the evaluation when the project uses the "Guard band
  w = U" decision rule: a reading then only passes if it lies at least U
  inside the limits (see `projekte`, "Test report details"). The instant
  "in range/out of range" hint in the execution dialog already applies that
  rule. Like the limits, U is frozen when the test case is completed.
- **Test method / standard:** The "Test method / standard (incl. edition)"
  field in the test case form holds the applied standard or in-house method,
  e.g. "DIN EN 60068-2-14:2010-04" or "PV-012 Rev. 3" (at most 200
  characters). It appears on the test case page, in each test step's
  definition, and in the test report; like all fields it is frozen in the
  revision and on completion.
- **Path 1 — a single value by hand:** In the "Test case executed" dialog you
  enter an actual value for each expected measurement (e.g. a reading taken
  at a specific point in time). This is the right path when there's no
  continuous measurement.
- **Path 2 — automatically against stored measurement data:** The "Evaluate
  from measurements" button on the test case detail page checks the
  measurements stored for the test case, per channel (min/max/average),
  against the expected measurements and derives passed/failed from that
  automatically. Those measurements either arrive automatically via stream
  (REST push or MQTT, see `messdaten` and `mqtt-anbindung`) or are
  uploaded manually as a CSV file — "Measurement data" section in the "Test
  case executed" dialog, columns `timestamp,channelName,value,unit` and
  optionally `quality`. Both paths land in the same store; evaluation doesn't
  distinguish between them.
- **When automatic evaluation doesn't work:** Measurements must already exist
  for the test case; if a channel contains readings with a quality score
  below 80 or inconsistent units, evaluation aborts with a matching message
  instead of producing an unreliable result. If a measured channel has no
  matching expected measurement with limits on the test case, that's reported
  too, instead of silently ignoring the channel.

## Common issues

- **"A reading is within the limits but shows 'out of range'."** The project
  uses the "Guard band w = U" decision rule and the quantity has a
  measurement uncertainty: only readings at least U away from both limits
  pass. The rule that applied is shown above the test step's measurement
  results table. If U exceeds half the tolerance band, no reading can pass —
  check U or the limits.
- **"The measurement uncertainty can't be saved."** It must not be negative;
  leave it empty for "not specified".

- **"'Create sequence' stays disabled even though I picked a template and a
  test object."** It still needs either a start time or a dependency on
  another sequence — one of the two is required. Either check "Set manually"
  and pick a time, or check at least one dependency.
- **"I can no longer set the end time manually."** That's intentional: a
  sequence's end results from its scheduled test cases, so the schedule and
  actual test scope don't drift apart. Only the start time can be fixed.
- **"After restoring, a test case I expected is missing."** The corresponding
  test case probably no longer exists in the library (deleted). Such test
  cases are skipped during restoration and reported as a note.
- **"A test case the revision no longer contains is still there after
  restoring."** The item already has execution data (status, result, or
  measurements) — such items are never deleted automatically, so no test
  history is lost. You can remove it manually if needed.
- **"I want to change a revision note afterwards."** Notes are immutable once
  the revision is saved — they're a record, not a free-text field. A new note
  is created on the next save.
- **"The save button stays disabled while recording execution."** At least
  one required field is still missing: the test result (passed/failed —
  never pre-selected, must be clicked), "performed by", actual result,
  start, end, or an actual value for one of the defined measurements. If the
  end is before the start, a note appears as well and the button stays
  disabled.
- **"'Passed' and 'Failed' are missing from the status menu."** That's
  intentional. You record a test result via "Test case executed"; only there
  do examiner, time range, and actual values come together.
- **"The status I want to set is missing from the status menu."** The menu
  only shows what's possible from the current status (see "A test case's
  status flow"). Example: from "Passed", the path goes through "In progress",
  not directly to "Pending".
- **"On the board, the card can't be dragged into every column."** Columns
  the status flow doesn't allow are dimmed while dragging.
- **"'Test case executed' isn't clickable."** The test case is skipped or
  aborted. Resume it first, then you can record an execution.
- **"The execution was saved, but the nonconformance wasn't."** This shows up
  as an error message and means exactly that: the execution stands, and you
  need to add the nonconformance afterwards via the "Nonconformances" section
  on the test case detail page.
- **"My attended test case still ends overnight or on the weekend."** Two
  possible causes: (1) The organization is set to "Continuous (24/7)" under
  Settings → Calendar — that applies to all test cases regardless of the
  checkbox. (2) The test case itself has "Runs unattended" checked even though
  it should be attended — fix this in the test case edit form.
- **"Only valid PNG and JPEG files are supported." when uploading a photo.**
  A different file format (e.g. PDF, HEIC) was selected — export it as PNG
  or JPG and upload again.

---

Source: https://www.testlabiq.com/en/help/test-sequences