Skip to content
Shalaka
Engineering notes

Micro-apps and AI agents · 14 November 2026 · Shalaka engineering team

What a production test station app should record for every unit

A test station that only shows a green PASS lamp throws away most of what it learns. Six months later a customer returns a unit, and nobody can say what that unit measured on the day it left the line. The fix is cheap if the record is designed before the first unit is tested.

The record for one unit

A test station app should write one record per test run, tied to the serial number. That record needs:

  • Serial number, board revision and batch or work order.
  • Firmware version flashed, and the bootloader version if it is separate.
  • Station ID, fixture ID, and the operator who logged in.
  • Start and end timestamps, in UTC with a fixed format such as ISO 8601.
  • The overall result, and the first step that failed.

The firmware version is the one people forget. When a fault shows up in one firmware build, you want to list every unit that carries it in one query.

Every step, with value and limits

For each test step, store the step name, the measured value, the unit, the lower and upper limit, and the result. A 3.3 V rail that reads 3.31 V and one that reads 3.46 V against a 3.5 V limit are both a pass, but they are not the same unit. Storing only pass or fail hides the one drifting towards the limit.

Store the limits with the result, as well as in the test program. Limits change between releases, and a record that points to “limits version 4” is useless if nobody kept version 4.

Keep the raw value too. A current of 12.4 mA stored as “OK” cannot go into a histogram.

Retests and history

A unit that fails, gets reworked and passes should show all its runs in order. Never overwrite a failed run. Give each run a number and link it to the rework note. The first pass yield, meaning units that pass on their first run, is a more honest figure than the final yield, and you can only compute it if the failed runs are still there.

Where the data should live

Write to a local database on the station first, then sync to the server when the network is there. A test run should never wait for Wi-Fi. If the same serial arrives twice from a retried sync, the server should treat it as one run by its run ID.

What this does not fix

A good record shows what happened at the station. It cannot tell you whether the test itself covers the right faults. A unit can pass every step and still fail in the field if no step checks the thing that breaks. Review the test list against your returns data now and then.


If your test station records little more than pass or fail, our micro-apps for electronics and manufacturing include test stations, so book a discovery call.

Tell us what you are building.

Book a discovery call