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