Internet of Things application testing
Your app is only half the product. The other half is a device on someone's shelf, behind their router, running last year's firmware.
IoT products fail in the gap between app and device. The app assumes the device answered; the device assumes the app is still listening. In the office, on the same desk and the same Wi-Fi, that gap barely exists. In a customer's house with thick walls, a congested 2.4GHz band and a phone that aggressively kills background tasks, it is where most of your one-star reviews come from.
Pairing is the flow we test hardest, because it is the first thing a customer does and the least forgiving. BLE pairing that works on a Pixel and stalls on a Samsung. Wi-Fi provisioning that fails silently when the SSID has an emoji in it. A setup wizard with no way back after a mistyped password. If onboarding fails, nothing else about the product gets a chance.
Firmware updates deserve their own test plan. We interrupt them on purpose: power cut at 60%, Wi-Fi drop mid-transfer, app backgrounded during install. A device that recovers cleanly earns trust. A device that bricks becomes a support ticket, a return, and a review.
You cannot test every router, every mesh setup and every phone. Nobody can, and any vendor who claims full coverage is selling you a spreadsheet. What you can do is cover the ten or so failure modes behind most support tickets: weak signal, a changed Wi-Fi password, a dead battery mid-operation, two phones claiming the same device, and a factory reset that doesn't.
So we test with real hardware on deliberately bad networks: throttled, lossy, NAT-ed. It is slower than testing against a simulator, and it finds different bugs.
Pairing & provisioning
BLE and Wi-Fi setup flows tested across phone makes, OS versions and network conditions.
Firmware updates
OTA updates interrupted on purpose to prove devices recover instead of bricking.
Network conditions
Weak signal, packet loss, captive portals and changed passwords, reproduced deliberately.
Fleet behaviour
Multiple devices, multiple users and shared-home scenarios, including changes of ownership.
Frequently asked questions
What's different about testing an IoT product versus a normal app?
The unhappy paths multiply. A normal app has a user and a server; an IoT product adds a device with its own firmware, a radio link that drops, a home network you don't control and a cloud in the middle. The bugs that reach support queues are rarely in any one layer — they live in the handoffs: a device that reconnects but doesn't resync, an app showing yesterday's sensor state as if it were live.
How do you test connectivity loss and reconnection?
Deliberately and repeatedly, because this is where IoT products earn their one-star reviews. We script the scenarios real homes produce: Wi-Fi dropping mid-command, the router rebooting overnight, the phone switching to mobile data, the device coming back with a stale state. What matters is what the user sees during the gap — a spinner that resolves honestly beats a dashboard confidently displaying wrong data.
Can you test firmware updates over the air?
Yes, and we treat it as the highest-risk flow in the product: an interrupted OTA update is how a smart device becomes a brick in a customer's photo on social media. We test update, rollback, power loss mid-update where the hardware allows it, and the app's behaviour when device and app versions drift apart — which they always eventually do.
Do you cover IoT security basics?
We cover the product-level ones that burn companies in the news: default credentials, unencrypted local traffic, APIs that let one customer query another's devices, and pairing flows that trust too easily. A full penetration test of firmware and radio protocols is specialist work we'd scope separately or refer; we're clear about where that line sits.
Why do my BLE pairing tests keep failing intermittently?
Flaky device tests usually trace back to the test environment rather than the firmware: RF interference, stale bonds, timing dependencies and shared rigs. Hardware-in-the-loop suites are never clean 100% of the time, and engineers who stop trusting the suite stop reading its results. The fix is disciplined rig design: isolated devices, automated reset between runs, and a triage process that separates genuine regressions from environmental noise.
When should a hardware startup hire QA?
Before your first major fleet deployment, which is the point where a bad OTA or a pairing bug stops being an engineering annoyance and becomes RMA costs, field servicing and refunds. Pre-launch teams rarely need a full-time hire; a testing partner engaged around launches and firmware releases covers the risk without a year-round salary. From scale-up onwards, a senior in-house QA lead plus external surge capacity is the common pattern.
How much does IoT device testing cost in the UK?
UK contractor rates for QA test engineers currently sit around a £700 median day rate, with junior testers nearer £425, and a full-time hire adds recruitment, equipment and management overhead on top. Outsourced testing engagements cost a fraction of that because you pay only around releases. Compare either figure with one field-failure incident, including RMAs, support load and lost reviews, and pre-shipment testing is the cheaper line item.
Ready to improve your software quality?
Tell us about your product and we'll get back to you with a plan.
Contact Us