Embedded software testing
Embedded software fails somewhere you cannot reach, on a device that cannot tell you why, in a house you will never visit. Nobody sends you a stack trace. What you get is a return, a one-line support ticket saying it stopped working, and a unit that behaves perfectly on the bench.
That is the problem this page is about. We are an independent testing company, based in Cluj-Napoca, in the EU, and we hold ISO 13485:2016, so medical device software is in scope. An embedded team can be working on your product in about two weeks, and those first two weeks are free if you are not happy with what we deliver.
The defect classes that matter, and are testable
Power loss during a write. This is the largest field defect class in connected products and one of the easiest to test deliberately. Cut power at a thousand different points in a non-volatile write cycle and see what comes back. Devices that pass every functional test brick themselves when a toddler pulls a plug at the wrong millisecond.
Slow resource exhaustion. A leak of forty bytes an hour is invisible in a one-day test run and fatal in week six. Soak testing with memory and heap instrumentation is the only thing that finds it. Fragmentation on a constrained heap behaves the same way and is harder to see, because free memory looks fine right up until an allocation of the wrong size fails.
Watchdog resets that hide the real bug. A device that recovers by resetting looks healthy in the field and is telling you something important, if anyone is counting resets. Most products do not count them.
Connectivity loss, and what happens after. Not the disconnect, the reconnect. A fleet of ten thousand devices whose network returns at the same second will attempt to reconnect at the same second. Backoff, jitter, queued telemetry and what the device does when it has been offline for three days are the tests that matter. BLE, Wi-Fi, Thread and Matter, LoRaWAN and cellular each fail differently.
Firmware update. Signed images, rollback, interrupted download, an update that succeeds on 99.4 percent of a fleet. The 0.6 percent is where the cost is.
Time. Real time clock drift, daylight saving, a device that has never reached an NTP server, and a device whose clock jumps backwards when it finally does. Schedules and logs both depend on this and both break silently.
Version skew across a fleet. A fleet is never on one firmware version. The app has to work with N, N-1 and whatever that batch from 2023 is still running. Almost nobody tests the matrix, and the app release is where it shows up.
The part most teams under-test
The firmware feels like the hard part, so it gets the attention. The companion app and the cloud service get a fraction of it, and that is where the user-visible defects are.
A device can be flawless while the app shows a stale reading with today's timestamp, and no user will ever describe that as an app bug. They will say the device is wrong. Testing the seam means testing staleness, not just parsing: what does the app display when the last successful sync was nine hours ago, and does it say so?
We test that layer the same way we test any other distributed system: API testing, mobile app testing on a real device matrix, and reliability testing for the long-running behaviour.
Medical devices, where we have the strongest claim
We hold ISO 13485:2016, the medical device quality management standard, alongside ISO 9001:2015, ISO/IEC 27001:2022 and ISO 14001:2015. ISO 13485 is the certificate manufacturers look for when they qualify a testing supplier, because their own quality system has to account for who tests their software.
For device software specifically, IEC 62304 governs the lifecycle and assigns a safety class that determines how much verification evidence is required. That evidence is exactly what a testing supplier produces, provided the traceability holds from requirement to test case to result. We run that traceability in BugBoard, which is included in the engagement, and we hand it over in a form your notified body can read.
Related: FDA compliance and certifications.
How we work without owning your hardware
Where you have a rig or a bench, we design the tests and your engineers run the hardware. Where you do not, we work against emulation and simulation for the firmware layer and directly against the app, the protocol and the cloud for everything above it. Protocol-level fuzzing needs no hardware at all and regularly finds the crash that six months of functional testing did not.
If units can be shipped to Cluj-Napoca, that is simplest, and it is what we would usually propose.
When we are the wrong choice
We would rather say this on the page than on the third call.
Hardware validation is not us. EMC, thermal, drop, ingress rating, vibration, battery certification. Nor is silicon or board bring-up, nor schematic review.
If your device has no way to get logs or telemetry off it, our first deliverable will be a recommendation to build one, and you may reasonably not want to pay a testing supplier to tell you that. Build the observability first and then call us.
If your product needs a certification sign-off under IEC 62304 or IEC 61508, that comes from a notified body or an accredited assessor. We produce the evidence. We do not issue the certificate.
If the work genuinely requires an engineer sitting next to the hardware every day and the hardware cannot be shipped or remoted, an on-site supplier is the right answer and we are not it.
Vehicle software sits under a different set of standards and a different procurement process. If that is what you build, say so when you get in touch and we will talk about it on its own terms rather than folding it in here.
How we start, and what it costs
Two weeks, no contract. We embed, learn the product, write tests and file real bugs against your actual software. If you are not happy with what we deliver in those two weeks, you do not pay for them. You decide whether to carry on, and we invoice from week three.
After that, $25 to $45 an hour depending on seniority, commitment length and the mix of manual, automation and specialist work. Longer commitments move down the range.
Included at no licence cost: BugBoard for test management and traceability, Flows for automation, Auditi for GDPR, WCAG and FDA auditing, BetterFlow for visibility into the hours, and our AI Security Toolkit.
Our engineers are in Cluj-Napoca, Romania, on GMT+2 and GMT+3 in summer. That covers the European working day and overlaps the start of the US East Coast day.
Talk to us
Tell us what the device does, how it gets updated, and what the last field failure was. We will tell you whether we can help with the whole of it or only part, and which part.