Test Steps

Test steps are the individual measurement steps within a calibration. They are managed via the TestStepController as a subresource of a calibration.

Concept

Each test step represents a single measurement or inspection within a calibration. It defines the target value, permissible tolerances, and measurement conditions. Results are documented per test step.

Structure of a Test Step

Field	Required	Description
Name	Yes	Description of the test step
Target Value	Yes	Expected measurement value
Unit	Yes	Unit of measure (e.g., mV, bar, °C)
Tolerance (+)	Yes	Upper tolerance limit
Tolerance (-)	Yes	Lower tolerance limit
Measurement Point	No	Position or range of the measurement
Order	Yes	Sort order within the calibration
Notes	No	Additional instructions for the inspector

Editing

In a calibration's test-steps tab the table only displays the steps. Changes go through "Edit steps" — the same editor as for procedure templates, with the switchable table/card view, the guided tolerance builder, the measurement point series and the limits preview. Field and syntax details are documented under Procedure Templates.

The whole list is saved in one request, not row by row:

PUT /api/v2/calibrations/{calibrationId}/test-steps
Body: { "steps": [ { "id": "…", "test_type": "Manual Test", … }, … ] }

• A step carrying its id keeps its identity and with it any measured value already captured for it.
• A step without an id is created.
• A step missing from the payload is deleted — together with its result row. The editor says so on opening when some steps already carry measurements.
• row_number and the hierarchical step number test_step follow from the submitted order and are never taken from the client. Existing result rows move along with their step when the order changes.

The single-step operations remain available for API clients:

POST   /api/v2/calibrations/{calibrationId}/test-steps      # one step
PUT    /api/v2/test-steps/{id}                              # one step
DELETE /api/v2/test-steps/{id}
POST   /api/v2/calibrations/{calibrationId}/test-steps/reorder

Pre-flight: what has to be settled before the first reading

When a test plan is actually started — via "Run" in the test steps tab, or directly on the full-screen route /procedure-run/{ctag} — calServer asks for three things first. Only then can readings be captured; until that point the run sits in the pre-flight state.

Item	Mandatory	Why beforehand
Environmental conditions (temperature, relative humidity, ambient pressure)	No	Not every test depends on them, and they can still be filled in later from a data logger. A mandatory field someone fills with a made-up 23 is worse than an empty one.
As-found verdict	Yes	Once the first adjustment is made, the incoming condition can no longer be established. It decides whether the customer needs an impact assessment.
Reference standards used	Yes, with an exit	Traceability entered after the fact is a claim, not a record.

As-found verdict

Three values, the same set as the final verdict at the end of the run:

Value	Meaning
Pass (Y)	The device arrived within tolerance.
Fail (N)	The device arrived out of tolerance.
No verdict (O)	No incoming judgement possible, e.g. for a new device.

The verdict applies to the whole run, not to an individual measurement point. It is stored on the calibration (as_found_result) and is therefore available to the certificate, alongside the final verdict describing the outgoing condition.

Choosing standards

The suggestion list comes from the inventory, in this order:

1. used before — standards this very device was calibrated against previously.
2. used as a standard in-house — any inventory item that has served as a standard anywhere.
3. search — free search across asset number, manufacturer, model, serial and type number, for a standard being used for the first time.

There is no "this is a standard" flag that would have to be maintained first: the existing data defines the pool.

Each row shows the standard's own calibration state: until when it is calibrated, whether it has expired, or whether no date is recorded at all.

Expired standards are flagged, not hidden

A standard without a valid calibration of its own can still be selected — the dialog says so. Hiding it would conceal the traceability gap instead of showing it, and there are legitimate cases (standard out for recalibration, substitute equipment) where a lab does this deliberately.

Starting without a standard

A purely visual or functional check needs no standard. If none is selected, the dialog requires a reason instead (at least five characters), recorded on the run. There is no checkbox without text — in an audit it would be worthless.

Runs already in progress are unaffected

The gate applies to runs opened from this version onwards. A test run that is already under way can be continued unchanged.

Previewing a reading (limits, expected evaluation) stays available during pre-flight — nothing is persisted by it. Entering results by hand outside a started test run is likewise untouched.

Result Recording

During the execution of a calibration, the actual value is entered for each test step:

Field	Description
Actual Value	Measured value
Result	Automatically calculated: pass / fail
Deviation	Difference between target and actual value
Notes	Optional comment from the inspector

Automatic Evaluation

The system automatically evaluates whether the measured actual value falls within the defined tolerances. The result (pass/fail) is color-coded: green for pass, red for fail.

What the capture table shows

Each measuring point has a limit bar (band, nominal, guard band, the reading as a marker; dashed while typing). Results show as icons (open circle, check, question mark, cross) next to the certificate symbol. The head of the run shows a progress bar, the overall result, counts per result, the run state and the unit under test. An outline on the left lists sections and steps with their state; a click jumps to the row. The dry run in the step editor shows the same.

Test Steps from Procedure Templates

When creating a new calibration, the test steps are copied from the associated procedure template. These can then be adjusted for the specific calibration without modifying the template.

Permissions

Managing test steps requires the calibration_edit permission. Viewing test steps requires calibration_view.