Medtech application testing
When software sits next to a medical device, testing stops being a good habit and becomes evidence.
Regulated software has a paper problem as much as a code problem. IEC 62304 wants to see which requirement each test covers, who ran it, on which build, and what happened. We write test cases with that traceability in mind from the start, because retrofitting a traceability matrix two weeks before an audit is miserable work.
The bugs themselves are rarely exotic. A companion app that loses its Bluetooth pairing with a glucose meter when the phone sleeps. A unit toggle that displays mmol/L but stores mg/dL. A firmware update screen with no recovery path if the transfer dies at 60%. None of these need a laboratory to find. They need someone methodically trying the unhappy paths on real hardware.
Being honest about our role: we are testers, not a notified body. We will not certify your device or write your regulatory submission. What we produce is the verification evidence your auditor will ask for: executed test runs, defect records with reproduction steps, and a requirements-to-tests mapping that holds up under questioning.
We also test the unglamorous surroundings that regulated teams sometimes skip: the companion app's behaviour on older Android versions, what happens to queued readings after 48 hours offline, and whether error messages tell a patient something useful or just quote a code.
If you are pre-submission, involve testing early. Findings are cheap to fix before the design history file is frozen and expensive after. We find it before your users do — and before your auditor does.
Verification evidence
Executed test runs, defect records and a requirements-to-tests traceability matrix that survives an audit.
Companion app testing
Pairing, sync and recovery flows on real phones and real hardware, including older OS versions.
Unhappy paths
Interrupted firmware updates, lost connections, offline queues and unit conversions.
Documentation
Test plans and reports written to fit IEC 62304 and ISO 13485 quality processes.
Frequently asked questions
Can you test software that's part of a regulated medical device?
We test it; we don't certify it. If your software falls under UK MDR, EU MDR or FDA rules, your regulatory pathway needs its own specialists, and we work alongside them rather than pretending to replace them. What we contribute is the documented, reproducible functional evidence those processes feed on: traceable test cases, recorded results, and defect reports an auditor can follow.
How do you test a device companion app without the physical device?
Partially, honestly. Simulators and recorded device data cover pairing flows, data display and edge-case values, and they're how we test dangerous or rare conditions safely. But Bluetooth behaviour, reconnection after signal loss and battery interaction only show their real character on hardware. If you can ship us a device, testing gets meaningfully better; we'll tell you which findings came from which setup.
What's the riskiest part of a typical medtech app?
The value that's wrong but plausible. A crash gets noticed; a glucose reading or dosage figure displayed with the wrong unit, a stale timestamp or a rounding error looks fine and gets acted on. We design tests around data integrity end to end: what the device measured, what the API stored, what the screen shows, and every conversion in between.
Do you produce documentation suitable for audits?
Yes. Regulated environments need evidence, not vibes: test plans that trace to requirements, results with environments and versions recorded, and defects with reproduction steps and severity rationale. We write these as part of the work rather than reconstructing them afterwards, because retro-fitted documentation is the kind auditors distrust most.
How much does IEC 62304 software testing cost?
There is no fixed price, and practitioners on quality forums describe a vicious circle: test houses can't quote until requirements are defined, while investors want a number up front. Cost scales with your software safety class (A, B or C), the number and complexity of requirements, and how much retesting your first failures trigger. The biggest cost saver is well-written, traceable requirements before testing starts.
Can developers test their own code under IEC 62304?
For higher-risk classes, auditors and notified bodies expect independent verification: someone other than the author designing and executing the tests. Small teams regularly ask on quality forums how a one- or two-developer company can achieve meaningful testing independence. Outsourcing verification to an external testing partner is a common, accepted way to demonstrate that independence without hiring a full QA department.
How do I release medical device software updates without redoing all validation?
This is one of the loudest complaints in medtech: constant software updates collide with device-style change control, and some companies end up shipping once a year. The way out is risk-based regression: a documented impact analysis per change, an automated regression suite mapped to requirements, and pre-approved test evidence templates, so each release re-verifies only what the change can affect. Done well, this supports monthly or faster releases while keeping your technical file audit-ready.
Ready to improve your software quality?
Tell us about your product and we'll get back to you with a plan.
Contact Us