Latest / Hardware Startups with Fexingo: Devices, Robotics, and Manufacturing Tech Companies / How Hardware Startups Use Functional Testing to Catch Bad Boards
Transcript
- Lucas: So you've designed a board, you've had it assembled, and you're about to ship the first batch. You probably ran a flying probe test, maybe boundary scan if you had the budget. But there's a whole category of defects those miss. Luna: You're talking about functional testing — actually powering the board up and seeing if it does what it's supposed to do. Lucas: Exactly. Structural tests check for solder bridges, missing components, opens — they make sure the board is built correctly. But they don't tell you if the board works. I've seen startups skip functional testing because it adds time and cost to the BOM, and then they learn the hard way. Luna: What's a concrete example? Something that structural testing would absolutely miss. Lucas: A medical device startup I know of — let's call them MedSync — shipped about 500 units of a patient monitoring patch. Every board passed flying probe and boundary scan. But about 3 percent of them would intermittently lose Bluetooth connection when the device was worn for more than a few hours. Turned out to be a timing issue between the main MCU and the Bluetooth module that only appeared under a specific temperature and current draw. No structural test would catch that. Luna: So how did they find it? A customer complaint? Lucas: Eventually, yes. But by then they'd already had returns and a lot of angry clinicians. The fix was a functional test fixture that simulated the full device operation — power up, connect Bluetooth, stream data for 30 seconds, check for dropouts. The fixture cost about $3,500 to build and took 20 seconds per board. After that, zero field failures from that root cause. Luna: Three thousand five hundred dollars — that's less than the cost of one engineer's time for a week. And it probably saved them tens of thousands in returns and reputation. Lucas: Exactly. And the thing is, functional test fixtures don't have to be expensive. You can build a pretty good one with an Arduino, some relays, and a Pogo pin bed. The key is deciding what to test. You're not trying to re-verify every component — you're testing the behaviors that matter to the user. Luna: So how do you decide what goes into a functional test? Do you start from the datasheet or from customer use cases? Lucas: Definitely from customer use cases. The datasheet says the Bluetooth module should work from minus 40 to plus 85 degrees Celsius. That's nice, but your user cares about whether the patch stays connected while they walk around the hospital. So your test should include motion, temperature, and maybe interference from other devices. Prioritize the failure modes you've actually seen in prototypes. Luna: Right, so it's risk-based. You test the things you're most worried about. Lucas: And you iterate. The first version of a functional test might only check power-on and a few GPIOs. Then as you learn from early production, you add tests for the specific issues that pop up. Luna: I've heard some startups also use functional testing to calibrate sensors or program firmware — turning it into a combined test and programming station. Lucas: That's a smart move. If you're already going to power up every board, you might as well program the firmware, set calibration constants, and maybe even run a quick self-test. It reduces handling and saves time. Some fixtures even generate a serial number and log test results to a database for traceability. Luna: Traceability is huge for medical or automotive. If a field failure happens, you want to know exactly which boards passed which tests. Lucas: Absolutely. And it does something else — it forces you to define what 'working' means. Before you build a functional test, you have to write down: what are the pass-fail criteria for this product? That exercise alone often reveals gaps in the design or the test plan. Luna: It's like a dress rehearsal for manufacturing. You discover things you wouldn't find until much later. Lucas: Right. And if these types of conversations are useful for what you're building or running, I'll mention quickly — a couple of dollars a month is genuinely what keeps these going. Buy me a coffee dot com slash fexingo, if you've gotten something out of them. Luna: Yeah, it's a small thing that makes a real difference. Totally optional, but appreciated. Lucas: Anyway, back to test fixtures. There's a trade-off between coverage and test time. If you try to test everything, your test might take five minutes per board, and at scale that kills your throughput. So you have to be smart about it. Luna: What's a typical target? Like 30 seconds per board? Lucas: For most consumer or medical devices, 30 to 60 seconds is reasonable. If you're making a simple sensor, maybe 10 seconds. The trick is to parallelize — test multiple boards at once, or run tests concurrently. For example, while one board is warming up, you test the next one. Luna: And what about the fixture itself? How robust does it need to be? Lucas: It depends on volume. For a run of a few hundred, a 3D-printed fixture with spring-loaded pins can work fine. For tens of thousands, you want something machined from aluminum with hardened pogo pins. The pins wear out after maybe 10,000 cycles, so you need to plan for replacement. But the fixture design is usually pretty simple — a base plate, a cover, and some alignment guides. Luna: So you're saying a startup with a small batch of prototypes can build a functional test in a weekend for a few hundred bucks? Lucas: Easily. I've seen teams use a Raspberry Pi, a breadboard, and some jumper wires to test an IoT sensor. It's not pretty, but it catches the failures. The important thing is to start before you ship. Don't wait for the first return to build your test. Luna: That's the lesson of the MedSync story — they had a perfectly good structural test, but it didn't tell them the device would drop Bluetooth after two hours. Lucas: Right. And the fix was cheap. The field failure cost them customer trust, which is much harder to fix. So if you're a hardware startup about to go into production, ask yourself: when I power this board up for the first time, what am I testing? If the answer is 'just that it turns on,' you probably need a more thorough functional test. Luna: And maybe also think about how you'll test it in the field — like over-the-air updates or diagnostic modes. Lucas: Good point. Some products include a built-in self-test that runs at power-up and reports status via an LED or a serial console. That can be a cheap form of functional testing that happens every time the user turns it on. But you still want a manufacturing test to catch issues before the device ever reaches a customer. Luna: So to wrap up: don't just trust the structural tests. Build a functional test that mimics real use, start simple, and iterate as you learn. Lucas: And remember — the cost of a fixture is almost always less than the cost of one recall.