How to Write a Manufacturing Test Specification for IoT Hardware

You’ve spent months designing a board, debugging prototypes, and running bench tests with an oscilloscope and a coffee-stained notebook. The design works. You’re ready to hand it off to a contract manufacturer and start building real volume.

Then the CM asks for your manufacturing test spec, and you send over a bullet-point list: “check 3.3V rail, make sure BLE connects, verify sensor readings look right.” Two weeks later, you get an email with 40 questions. Yield from the first build is unknown because nobody logged anything. 6 units came back dead and no one can tell you why.

This happens constantly. The distance between “I tested it on my bench and it works” and “a stranger in a factory can test 5,000 of these repeatably” is massive. Your manufacturing test spec bridges that distance, and it’s probably 20 to 40 hours of work that pays back every single day the production line is running.

Here’s how to structure one that a CM can actually execute.

Manufacturing Test Spec vs. the Other Documents in Your Pile

Engineers often blur the lines between test documents, so let’s be precise.

Your DVT report proves the design meets its requirements across temperature, voltage, and stress conditions. The manufacturing test spec defines what gets checked on every single unit rolling off the line, and what “good” looks like in hard numbers.

The test spec defines what and why. The test procedure (SOP) defines how, step by step, with screenshots and photos. This article focuses on the spec.

The Anatomy of a Manufacturing Test Spec

Walk through each section below, adapt it to your product, and you’ll have a spec your CM can work with on day one.

Header and Revision Control

CMs take document control seriously. Every revision of your spec needs a document number, revision letter, date, author, and approval signatures. If the CM builds to Rev B but you verbally told them about a change in Rev C, you’ll ship bad product and it’ll be your fault.

Scope and Applicable Products

State exactly which product this spec covers: PCB assembly part number, hardware revision, BOM revision, and schematic revision. If you’ve got multiple SKUs (say, a US variant and an EU variant with different RF front ends), call that out. Note whether this spec covers board-level testing, system-level testing, or both.

Test Coverage Summary

Start with a high-level table so the CM’s test engineer can see the full picture at a glance. For a hypothetical IoT device:

Every row becomes a detailed test definition in the next section.

Individual Test Definitions: Where the Real Work Lives

For each test in your coverage table, the spec must define:

• Test ID and name (consistent with the summary table)
• Prerequisite conditions: power state, firmware version loaded, fixture connections made
• Stimulus: what input is applied (voltage, signal, command)
• Measurement: what is measured, with which instrument, at which test point
• Pass/fail limits: numerical, with units and tolerances
• Action on fail: retry logic, failure bin code, disposition path

Here’s what a single test definition looks like, done right:

T-001: 3V3 Rail Voltage Check

• Prerequisite: DUT powered via fixture, USB-C supply at 5.00V ± 0.05V
• Stimulus: None (passive measurement)
• Measurement: Measure voltage at TP12 (3V3_OUT) referenced to TP1 (GND) using DMM
• Pass limits: 3.30V ± 0.10V (3.20V to 3.40V)
• On fail: Bin code PWR_FAIL, halt test sequence, route to failure analysis

Notice the limits. “~3.3V” is useless on a production line. Your test operator doesn’t know what your design margins are. You must convert your engineering judgment into numbers with units and tolerances. This is the single most important thing in the entire spec.

If your BLE-enabled device needs its radio validated during production, the RF calibration step (T-003 above) becomes especially critical. For devices built on the Hubble Device SDK, you’ll want to verify TX power output and confirm the advertising packet structure matches what the network expects, with explicit dBm limits and a reference test receiver at a defined distance or cable loss.

Test Equipment and Fixturing Requirements

List every instrument the CM needs: DMM model or minimum specs (6.5-digit resolution? 4.5 is fine?), power supply current limit capability, RF test equipment, any custom test software.

For the test fixture: specify mechanical requirements, pogo pin locations referenced to your PCB Gerbers, connector types, and who designs it. If you’re designing the fixture, include a drawing. If the CM is designing it, your spec needs to define the interface: test point locations, keep-out zones, board alignment features.

Include calibration requirements. Most CMs follow their own cal schedule, but if your RF test needs a calibrated cable and attenuator, say so.

Test Sequence and Flow

Define the order of operations. Tests often have dependencies: you can’t calibrate the radio if the MCU won’t boot, and the MCU won’t boot if the power rails are wrong.

Power On → T-001 → T-002 → T-003 → T-004 → T-005 → T-006 → PASS/FAIL
              ↓ FAIL                    ↓ FAIL
          Bin: PWR_FAIL             Bin: RF_FAIL → Retry 1x

Specify whether a power rail failure halts everything (it probably should) or whether the sequence continues to gather more diagnostic data. Define retry policies: “T-003 may retry once on a marginal fail before assigning RF_FAIL bin.” Every bin code should map to a rework or scrap disposition.

Data Logging and Traceability Requirements

This is where first-time specs almost always fall short, and where the real long-term value lives.

Specify that every test measurement must be logged as a parametric value, not just pass/fail. Define the log format (CSV is simplest for CM adoption). Require a unique serial number or MAC address as the primary key. Define retention period (2 years minimum is typical). Specify where the data lives: local server at the CM, upload to your cloud, integration with the CM’s MES system.

Why bother? Parametric data lets you detect yield drift before hard failures start. If your 3.3V rail reads 3.29V across 1,000 units and 3.35V across the next 1,000, something changed: a component lot shifted, a reflow profile drifted. You want to see that signal early.

Data Logging Deep Dive: What to Capture and Why

The traceability chain you should specify: serial number → test date/time → test station ID → operator ID → firmware version → every measured value.

Here’s a concrete CSV structure to put in your spec:

serial_number, test_id, timestamp, measured_value, unit, lower_limit, upper_limit, result
SN00001, T-001_3V3, 2025-01-15T08:32:01Z, 3.29, V, 3.20, 3.40, PASS
SN00001, T-001_1V8, 2025-01-15T08:32:02Z, 1.81, V, 1.72, 1.88, PASS
SN00001, T-003_TXPWR, 2025-01-15T08:32:15Z, 4.2, dBm, 3.0, 5.0, PASS

Define column headers exactly. If you leave format decisions to the CM, you’ll get something different from every factory, and aggregating data across builds will be painful.

Define how often data gets transferred to you. Daily file uploads are a reasonable minimum for volume production. Weekly email summaries aren’t acceptable if you’re running more than a few hundred units. Real-time API pushes are ideal if your backend supports it. If you’re already pulling device data through webhook endpoints for your product’s cloud integration, your manufacturing data pipeline can follow a similar pattern.

Require a daily first-pass yield summary at minimum: total tested, total passed, total failed, broken out by failure bin. This is how you catch problems on day 1 instead of day 30.

Writing for the CM: Practical Tips That Save You Rework

Your audience is a test engineer who has never seen your product. They don’t know your design intent. They don’t know which rail is “the important one.”

Remove all ambiguity. “Approximately 3.3V” becomes “3.30V ± 0.10V.” “Should work similar to the prototype setup” becomes a fixture drawing with dimensions and pogo pin coordinates. Use numbered steps, explicit units, and reference designators (R42, not “the pull-up near the MCU”).

Version control everything. If you change a test limit, issue a new revision. CMs will build exactly what the current signed revision says.

Send the draft spec to the CM for review before you finalize. They’ll flag things you didn’t consider: “We don’t have an RF chamber on this line,” or “that 2-second cycle time target for T-003 is unrealistic with our current fixture.” Getting buy-in early saves you a painful back-and-forth after production starts.

Call out special handling. ESD-sensitive test points, moisture-sensitive components that need time limits outside dry storage, RF shielding requirements during test. If you don’t specify it, assume it won’t happen.

Mistakes That Will Cost You Units and Time

• Specifying tests that need lab equipment unavailable on a production line. Your $40K spectrum analyzer isn’t going to live at the CM.
• Setting pass/fail limits too tight, which kills yield and your CM’s patience. Or too loose, which ships bad units to customers.
• No defined failure disposition: rework path, scrap criteria, who makes the call.
• Forgetting to specify which firmware version gets loaded during test.
• Omitting cycle time targets. The CM needs these for line planning, staffing, and quoting your cost per unit.
• Assuming the CM will “figure out” the test fixture design without detailed interface requirements.
• No document revision control, leading to the CM running an obsolete test version for weeks.

Refining Your Spec After the First Build

The first version of your manufacturing test spec won’t be perfect. Plan for that. The pilot build exists partly to shake out problems in the spec itself.

Use the yield data and failure analysis from your first 100 to 500 units to adjust. Maybe T-003 limits are too tight and you’re failing 8% of units that are actually fine. Maybe T-004 isn’t catching a sensor failure mode you discovered in the field. Tighten some limits, loosen others, add a test you missed.

Re-release the spec with a new revision number for every significant change. Your CM expects this; they prefer it, because it means you’re paying attention.

If you’re provisioning devices during manufacturing (flashing keys, registering with a cloud backend, or programming unique identifiers), your test spec should reference the device provisioning process explicitly. Specify which step in the test flow provisioning occurs, and define what a successful provision looks like in the log data.

Expect to invest 20 to 40 hours for a moderately complex IoT product. Every unit that gets tested correctly, logged properly, and binned accurately traces back to this one document. Get it right.

Hubble Network enables direct satellite connectivity for IoT devices—no gateways, no terrestrial infrastructure. See how it works →