How to Test IoT Hardware Before Mass Production

Engineers conducting durability tests on IoT circuit boards in a hardware validation lab

A hardware startup we know shipped 10,000 units of a connected sensor to a logistics customer. Six weeks later, the devices started browning out in warehouse environments that hit 40°C, well within the spec they’d claimed. The root cause was a voltage regulator that performed fine on the bench at room temperature but derated under sustained thermal load with the radio transmitting at full power. The fix required a board respin, a new mold for the revised thermal venting, and a full product recall. Total cost: north of $400,000, roughly 12x what rigorous pre-production hardware testing would have run them.

Here’s the thing about hardware: you can’t push a patch. Every shortcut in testing becomes a physical liability that ships in a box, sits in a customer’s hands, and multiplies across every unit you’ve built.

The framework that prevents this is well-established: EVT, DVT, and PVT, three structured validation phases that systematically reduce risk before you commit to volume manufacturing. Most founders have heard these acronyms. Few understand what actually happens inside each phase, what the exit criteria look like, or why compressing them is the most expensive “time savings” you’ll ever regret.

This article walks through each phase in detail: what you test, how many units you need, what “pass” looks like, and the specific mistakes that catch IoT teams off guard.

The Real Cost of Finding Problems Late

There’s a rule of thumb in hardware engineering that’s held up for decades: the cost of finding and fixing a defect multiplies roughly 10x at each stage of the product lifecycle. A problem caught during schematic design might cost you a few hours of an engineer’s time. The same problem caught during prototyping costs a board respin. During tooling, it costs mold modifications. In mass production, it’s a line stoppage. In the field, it’s a recall.

For a $50 IoT device, a field defect affecting even 5% of a 10,000-unit run can easily cost hundreds of thousands of dollars in logistics, replacement units, customer support, and brand damage. And unlike software, there’s no OTA update that fixes a cracked enclosure, an antenna that doesn’t meet FCC Part 15 limits, or a battery that swells in high humidity.

Regulatory implications compound this further. You can’t certify a product under FCC, CE, or UL standards that you haven’t thoroughly validated. Failing certification after you’ve committed to tooling and inventory is one of the most common, and most preventable, disasters in IoT product development.

EVT, DVT, and PVT exist specifically to catch these problems in the order that’s cheapest to fix them.

Phase 1: Engineering Validation Testing (EVT) — “Does It Work?”

EVT is your first real gut-check. The goal is simple: prove the design functions as intended. Not reliably. Not beautifully. Functionally.

Typical sample size: 20–50 units, often hand-assembled or built from soft tooling and prototype PCBs.

Here’s what you’re testing during EVT:

  • Core functional verification. Do the sensors read correctly? Does the microcontroller boot and execute firmware? Does the power management circuit deliver stable rails under load?
  • Firmware/hardware integration. This is the first time your firmware team and electrical team find out if their assumptions about each other’s work actually hold. Expect surprises.
  • Initial thermal profiling. Stick thermocouples on your voltage regulators, radio module, and battery. Run the device under realistic duty cycles. You’re not looking for full thermal qualification yet. You’re looking for red flags.
  • RF and antenna performance (first pass). For IoT devices, this is critical. Test radiated power, receiver sensitivity, and antenna matching. A first-pass antenna that’s 3 dB off will bite you later.
  • Basic mechanical fit checks. Does the PCB fit in the enclosure? Do the buttons line up? Does the display sit flush?

The most common EVT pitfall is testing only the happy path. Your device connects to Wi-Fi in your office with a strong signal and a stable power supply. But what happens when the battery is at 10%? When the Wi-Fi signal is marginal? When three sensors are polling simultaneously? Edge cases found in EVT cost hours to fix. The same edge cases found in production cost months.

Exit criteria for EVT: All critical functions have been demonstrated. Known issues are documented in a formal tracker (not in someone’s head or a Slack thread) with clear remediation plans. Design changes are locked enough to commit to production-intent tooling for DVT.

Practical tip: Start a formal issue tracker from day one of EVT. Assign severity levels. Every unit should be serialized. Tribal knowledge kills hardware programs.

Phase 2: Design Verification Testing (DVT) — “Does It Work Reliably Enough to Sell?”

DVT is where you go from “it works on my desk” to “it works in the real world, every time, within spec.” The goal is to validate that the design is reliable, safe, and meets every specification you’ll claim on the datasheet or product page.

Typical sample size: 50–200 units, built from production-intent tooling and processes. These should look and function like the final product.

DVT testing is broad and rigorous. For IoT hardware, this is what it typically includes:

  • Environmental testing. Temperature cycling (per IEC 60068), humidity exposure, drop testing (typically 1-meter drops onto concrete for consumer devices), vibration, and ingress protection validation (IP ratings, if claimed). If your device will live in a truck, a warehouse, or outdoors, test in those conditions, not just at 25°C in a lab.
  • Battery life and charge cycle validation. Run full discharge curves under realistic workloads. Validate charge cycle count against your claimed battery lifespan. Test charging at temperature extremes.
  • EMC/EMI pre-compliance testing. Before you spend $15,000–$30,000 on formal certification testing, run pre-compliance scans to identify radiated and conducted emissions issues. Fix them now, not during certification.
  • RF certification pre-scans. For Wi-Fi, BLE, LoRa, cellular: verify your device meets the relevant FCC Part 15 / CE RED limits with the actual production antenna in the actual enclosure. Antenna performance changes when you move from a 3D-printed prototype to an injection-molded housing.
  • Reliability and accelerated life testing. Simulate months or years of use in compressed timeframes. Thermal cycling, button actuation endurance, connector insertion cycles.
  • Full firmware stress testing. OTA update failure and recovery, memory leak detection over extended operation, reconnection behavior after connectivity drops, watchdog timer verification.
  • Cosmetic and fit/finish evaluation. Check against your industrial design specifications. Surface finishes, parting lines, color matching, label adhesion.
  • User experience validation. Button feel, LED visibility in direct sunlight, onboarding flow tested on the actual hardware (not a prototype that “looks close enough”). This is where you discover the BLE pairing flow that worked fine on your dev kit fails 30% of the time with the production antenna.

The key distinction from EVT: EVT asks “does it work?” DVT asks “does it work reliably, safely, and to spec across all conditions a customer will encounter?”

Common DVT pitfalls: Insufficient sample sizes. Testing 10 units and declaring victory when manufacturing variation across 10,000 will be far wider. Testing only at room temperature. Ignoring wear and aging effects. Assuming that because your BOM is frozen mechanically, nothing else can go wrong.

Exit criteria for DVT: All product specifications met across the full sample set. Regulatory pre-compliance passed with margin. BOM and mechanical design frozen, no further changes. No open critical or major issues. You should feel confident enough to submit units for formal regulatory certification.

Phase 3: Production Validation Testing (PVT) — “Can We Build It Consistently?”

Here’s where the focus shifts fundamentally. In PVT, the product design is frozen. You’re not testing the design. You’re testing the manufacturing process.

The goal: prove that your contract manufacturer can produce consistent, quality units at your target volume and yield.

Typical sample size: 200–500+ units, built on the actual production line, with final tooling, final BOM, and final assembly processes.

What gets tested during PVT:

  • Manufacturing yield rates. What percentage of units pass functional test on the first attempt? If your first-pass yield is 85%, you have a process problem that will eat your margins at scale. Target: 95%+ for most IoT products.
  • Production line test fixture validation. Your functional test (FCT) and in-circuit test (ICT) fixtures must reliably catch defective units without falsely failing good ones. Validate them against known-good and known-bad units.
  • Unit-to-unit consistency. Measure dimensional tolerances across 50+ units. Compare electrical performance (current draw, RF output power, sensor accuracy) across the batch. Look for variance, not just averages.
  • Packaging validation. Drop test the packaged product. Verify the unboxing experience. Check shelf-life considerations for battery-powered devices (will the battery self-discharge below a bootable voltage if the product sits in a warehouse for six months?).
  • Final regulatory certification samples. Submit PVT units for formal FCC, CE, UL, or other required certifications.
  • Golden sample approval. Seal reference units that define the quality standard. Your CM will use these for ongoing comparison during mass production QC.

Common PVT pitfalls: Treating PVT as a formality or a “pilot run you sell to early customers.” Failing to define acceptable yield thresholds before the run starts. Not having a clear rework/reject protocol. And the biggest one: changing the design during PVT. Any design change during PVT resets you to DVT. Full stop.

Exit criteria for PVT: Target yield achieved consistently. All regulatory certifications obtained. QC procedures documented, validated, and agreed upon with your CM. A clear go/no-go decision for mass production, with data to back it up.

How to Build a Hardware Test Plan That Actually Works

Don’t wait until EVT to start writing your test plan. Start during design. A hardware test plan is a living document that grows with your product through all three phases.

Every test entry should include:

  • Test ID — unique identifier for traceability
  • Phase — EVT, DVT, or PVT
  • Test description — what you’re testing and how
  • Pass/fail criteria — quantitative wherever possible (“current draw < 15mA in sleep mode,” not “battery life is acceptable”)
  • Sample size — how many units, and whether destructive
  • Equipment required — specific instruments, chambers, fixtures
  • Owner — named person, not a team
  • Status — not started, in progress, pass, fail, blocked

Traceability is non-negotiable. Every unit tested should be serialized. When you find a failure in DVT, you need to trace it back to the specific PCB lot, assembly date, and component reel.

Useful standards to reference without getting buried in them: IEC 60068 for environmental testing protocols, IPC-A-610 for PCB assembly quality criteria, and your relevant wireless standards (FCC Part 15, CE RED, ISED) for RF testing.

For IoT products specifically, your test plan should cover at minimum these categories: electrical, mechanical, thermal, RF/wireless, firmware, environmental, safety, and regulatory.

Six Mistakes That Send You Backward

  1. Compressing EVT and DVT into one phase. Teams do this to “save time.” What actually happens: you find functional bugs and reliability bugs simultaneously, can’t tell which is which, and end up running both phases anyway, just without the structure.

  2. Testing with prototype components not on the final BOM. That $3 prototype sensor behaves differently than the $1.50 production part. Test what you’re going to ship.

  3. Not involving your CM until PVT. Your contract manufacturer should review your design for manufacturability during DVT at the latest. Discovering a component can’t be placed by their pick-and-place machines during PVT is an expensive surprise.

  4. Assuming regulatory pre-scans guarantee certification. Pre-compliance testing identifies likely problems. Formal certification testing is conducted by accredited labs under controlled conditions. Margin matters. If you’re passing pre-scans by 1 dB, budget for rework.

  5. Ignoring real-world user conditions. Your outdoor asset tracker will be left on a truck dashboard in Phoenix in August. Your wearable will be worn in the shower despite your IP rating. Test for how users will actually treat the product, not how you wish they would.

  6. Making design changes during PVT. This isn’t a PVT anymore. You’ve reset to DVT. Accept it, revalidate, and move forward with data, not hope.

Making EVT, DVT, and PVT Your Competitive Advantage

The EVT → DVT → PVT framework isn’t bureaucracy. It’s the mechanism that protects your timeline, your budget, and your customers from the physics of shipping atoms instead of bits. Every phase has a purpose. Every gate has criteria. Every shortcut has a price, and that price gets paid with interest at scale.

The teams that treat structured hardware testing as a competitive advantage, not overhead, are the ones that hit mass production on schedule, with yields that support their margins, and products that don’t come back.

Start your test plan now. Serialize every unit. Define your pass/fail criteria before you power on the first prototype. And if you’re building toward production, explore our Prototype to Production guide for the complete framework, or download our IoT Hardware Test Plan Template to put this into practice today.

Hubble Network enables direct satellite connectivity from low-cost Bluetooth chips — so your IoT hardware design doesn’t need to compromise on connectivity range to hit production margins. See how it works →