The Hardware Team's Pre-Production Test Checklist

Most production test problems are decided long before anyone builds a fixture: in the test spec, in the PCB layout, and in what the team chooses to log. Go through these with your hardware lead, your firmware lead and whoever owns the CM relationship. Every "we don't know yet" is a risk you can still fix cheaply.

1. Does every test have a numeric limit, units, and a measurement method?

   "Verify 3.3V rail" isn't a test. "3.3V_MAIN at TP12, 3.20–3.40 V, measured at 200 mA load after 500 ms settle" is. Without the load condition, the measurement point and the settle time, two stations will disagree and neither will be wrong.

   Red flag if… any line in your spec uses "check," "verify," or "confirm" with no number next to it.

2. Which failure modes is each test meant to catch, and which are already covered upstream?

   Map every step to the defects it detects: opens and shorts, part missing, wrong part placed, polarity, firmware not loaded, calibration not stored. Then compare against what your CM's AOI and ICT already cover. Keep the steps that close gaps and cut the ones that duplicate coverage.

   Red flag if… nobody can name the failure mode a given test exists to catch.

3. What's your target cycle time, and which step sets it?

   Work back from the build plan: units per shift ÷ stations gives you a time budget per DUT. Add up every step, including fixture load/unload and boot time, and find the slowest. That step decides your UPH and how many stations you'll need.

   Red flag if… the only cycle time estimate is "a few minutes."

4. Can a fixture actually reach your test points?

   Testability is a layout decision. Check that test pads are on the fab drawing, sized and spaced for pogo pins (and not hidden under components or the enclosure), ideally on one side, and that you have access to power rails, the programming header, and key signals.

   Red flag if… the plan relies on probing component pads or vias by hand.

5. How does firmware get onto the DUT, and how do you prove it's the right one?

   Decide the programming path (SWD/JTAG, ROM bootloader over USB/UART, DFU) and how long it takes at volume. After programming, read back the version string and a checksum or hash. "Flash succeeded" doesn't tell you the right image is on the board.

   Red flag if… the production image is "whatever's on the engineer's laptop."

6. Which steps depend on operator judgment, and how will you take it out?

   "LED looks green," "buzzer sounds OK," and "button feels right" vary by person, by shift and by how tired people are. Replace them with measurements: a color/light sensor, a microphone with a frequency check, a current signature. Prompt the operator only where a physical action is unavoidable.

   Red flag if… the operator decides pass/fail by looking or listening.

7. Are your instruments accurate enough for your limits?

   Compare instrument accuracy (at the range you'll actually use) against your tolerance band, and aim for a test accuracy ratio of roughly 4:1 or better. Sleep current in the µA range, for example, needs an SMU or a dedicated low-current meter, not a general-purpose DMM on auto-range.

   Red flag if… your tolerance band is tighter than your meter's spec at that range.

8. How will you set and confirm your limits?

   Datasheet values are a starting point. Measure golden units and deliberately marginal limit samples, then tighten from real distributions once you have production data. Process capability (Cpk) tells you whether a limit is realistic or will throw away good units.

   Red flag if… limits were copied from the datasheet and never checked against real units.

9. What gets logged for each serial number?

   Log measured values, not just pass/fail, along with limits, serial number, station ID, fixture ID, firmware version, test software version, operator and timestamp. Store it somewhere you can query, not in CSVs on the station PC. This is the data that tells you yield is drifting before it turns into escapes.

   Red flag if… the only record of a unit is a sticker that says PASS.

10. What happens when a unit fails?

    Define the retest policy (how many retries, and whether retests count toward first-pass yield), failure bins, the rework loop, and when a run of failures stops the line. Without a policy, operators retest until it passes, which hides real defects and inflates your FPY.

    Red flag if… "retest it" is the whole failure procedure.

11. How will you know the station itself is working?

    Add a station self-test or a known-good/known-bad unit check at the start of each shift, a calibration schedule for instruments, and a GR&R study before release so you know how much of your measured variation is the station rather than the DUT. Track pogo pin cycle counts, because worn pins cause false failures.

    Red flag if… two stations disagree on the same unit and nobody can say which one is right.

12. What changes between EVT, DVT and PVT, and can the station keep up?

    Expect board spins, BOM substitutions and new firmware. Build the station from modules (swappable fixture plate, instrument abstraction in software, limits in a config file instead of in code) so a revision change takes a day, not a rebuild.

    Red flag if… changing a test limit means editing and redeploying the test software.

From the Engineering Notebook at alfredatwork.com. Free spec review: alfredatwork.com/test-stations.html

Want to see these questions applied? Read Your Test Spec Already Tells You Where to Automate.