
Medical Device Software Testing
Medical Device Software Testing Built for Clinical Reality
Medical device software testing only protects patients running across the whole product. Our testing covers verification, validation and traceability as one discipline. First we map the requirements, risks and software safety class. Then we build and run tests to prove the software's effectiveness.

Testing is Built
Into the Build
Get verification and validation designed into the development lifecycle rather than added at the end. One team owns the code and the evidence that it works.

Engineered for
MDR From
the First Sprint
We test to EU MDR, IEC 62304 and ISO 14971 as the software takes shape. The audit trail grows with the product rather than in a last-minute scramble.

Test Depth
Based on Risk
We set test depth by software safety class and patient risk. The effort lands exactly where a failure would reach a patient.






How Medical Device Software Testing Works at punktum

1. Requirements and Risk Analysis
We map the software requirements, the intended use and the risks under ISO 14971. This sets the software safety class that drives how much testing each part needs.

2. Test Strategy and Traceability
We plan verification and validation against every requirement and build the traceability matrix MDR auditors ask for. Nothing is left untested or unlinked.

3. Test Design
and Automation
We write the test cases and automate them where it pays off, from unit to integration to system level. Regression then runs on every change instead of once a release.

4. Execution and
Defect Management
We run functional, performance, usability plus security tests and manage defects to closure. You can see coverage and open risk at any point.

5. Documentation and
Release Evidence
We produce the V&V report, protocols and records for your technical file. You reach conformity assessment with the evidence already in place.
Industries Where We Test Medical Device Software
The same testing discipline applies across sectors. These are the areas where we have tested and shipped medical device software.

1. Connected Devices and Wearables
We test firmware, companion apps and connectivity for body-worn and connected medical devices. Coverage runs from the sensor to the cloud.

3. Remote Monitoring and Home Care
We test the apps and platforms that carry patient data from home to clinician. Reliability holds up outside lab conditions.

2. Diagnostics and Point of Care
We verify and validate software that turns readings into results clinicians act on. Accuracy and traceability are proven rather than assumed.

4. SaMD and Clinical Software
We test standalone software as a medical device against its Rule 11 class. The evidence matches the risk the software carries.
What Medical Device Software We Test
Medical device software testing covers more than a final check. Depending on your product and its risk class, we cover the following. See our testing capabilities in detail.

SaMD and Embedded Software
We test standalone software as a medical device and the firmware inside connected devices, at unit, integration and system level.

Mobile and Companion Apps
We test patient and clinician apps and their dashboards across iOS, Android and web on real devices.

Cloud, Backend and Interfaces
We test the backend, APIs and data pipelines, including the HL7/FHIR interfaces to clinical systems.
Clients We’ve Already Worked With
Solve Testing Challenges
Medical device software fails testing in predictable ways.
Challenges we have already solved.

Test Evidence That Fails an Audit
Ad-hoc testing leaves gaps a notified body will find. We build requirement-to-test traceability so the evidence holds up under scrutiny.

Regression That
Breaks Late
A fix in one release quietly breaks a feature two releases later when nothing re-tests it. We automate regression in CI so every change is checked.

Requirements You Cannot Trace
Untraceable requirements make it impossible to prove coverage under IEC 62304. We link every requirement to its test and its risk from the start.

Usability Risks Found Too Late
Use errors surface after launch when human-factors testing is skipped. We run usability evaluation to IEC 62366 before the software reaches patients.

Testing Bolted
On at the End
V&V left to the end becomes a costly scramble before conformity assessment. We build testing into the lifecycle so evidence accrues as you go.
Medical Software We Have Tested and Delivered
Clients Think About our Medical Device Software Testing

CaReHigh
Prof. Dr. med. Winfried März & Prof. Dr. Felix Fath
Stealth Wearable
Alexandra E., Founder
DiaperID
Prof. Dr. med. Philip BuflerWhy punktum for Medical Device Software Testing
Medical device software testing sits between engineering, risk and regulation. We bring all three together in-house, so your testing and your evidence come from one partner.

Full-Stack Test Engineering
We field 120+ engineers across embedded, apps and cloud, so the software is tested by people who also build it. No throwing code over a wall to a separate test house.

MDR and Regulatory Expertise
Our regulatory team handles EU MDR, IEC 62304 and ISO 14971 alongside the testing. Your evidence is built to stand up in an audit.

Proven MedTech
Delivery, ISO 27001
We have shipped and validated medical software from embedded firmware to remote monitoring apps. ISO 27001 certified, EU-hosted and CET-aligned.
Our Medical Device Software Testing Capabilities in Detail
The three areas above rest on five core testing capabilities. What each one covers and where it earns its place in a medical device.

1. Verification
and
Validation
We verify each software requirement and validate the product against its intended use.
- Testing runs at the unit, integration, system and acceptance levels.
- The output is documented evidence that the software meets its specification.

2. Risk and
Safety-Class Testing
We derive test depth from the IEC 62304 software safety class and ISO 14971 risk file.
- Higher-risk software items get deeper, documented testing.
- Effort concentrates where a failure would reach a patient.

3. Automated Continuous Testing
We build automated suites for unit, API and UI testing.
- These run inside CI, so every change is retested.
- Regression stops being a manual bottleneck at the end of a release.

4. Usability and
Human-Factors Testing
We plan and run usability evaluation to IEC 62366 for the intended users and use environment.
- Use-related risks are surfaced and fed back into design.
- This is where use errors get caught before patients meet them.

5. Security and
Cybersecurity Testing
We test the software against its threat model, from input validation to authentication and encrypted transport.
- Where the market needs it, we align the testing with recognised medical-device cybersecurity guidance.
- For the build side of this work, see our Development service.
Our Medical Device Software Testing Technology Stack
Medical device software testing spans the whole product: the embedded code, the apps and the cloud behind them. We test across every layer in-house.

Test Levels
- Unit testing
- Integration testing
- System testing
- Regression testing
- Acceptance testing
- Smoke testing

Test Automation
- pytest
- JUnit
- Selenium
- Appium
- CI-integrated suites
- Code coverage

Performance and Reliability
- Load testing
- Stress testing
- Soak testing
- Static analysis
- Boundary testing
- Fault injection

Security Testing
- SAST
- DAST
- Penetration testing
- Threat modelling
- Dependency scanning
- Fuzz testing

Traceability and ALM
- Requirements traceability
- Test management
- Defect tracking

Standards and Compliance
- EU MDR
- IEC 62304
- ISO 13485 / ISO 14971
- IEC 62366 (usability)
- ISO 27001 / GDPR
Your FAQs on Medical Device Software Testing
Q1: What is medical device software testing?
A1: Medical device software testing is the verification and validation of software in or as a medical device, so it is safe, effective and compliant. Verification checks the software against its requirements. Validation checks that it meets its intended use in real conditions.
Q2: What is the difference between verification and validation?
A2: Verification asks whether you built the software right, against its specified requirements. Validation asks whether you built the right software for its intended use and users. For a medical device both are required, because passing one does not prove the other.
Q3: Which standards apply to medical device software testing?
A3: In the EU the core set is IEC 62304 for the software lifecycle, ISO 14971 for risk management and IEC 62366 for usability, inside an ISO 13485 quality system and under EU MDR. The exact mix depends on the device, its class and its intended use. We map the applicable standards to your product before testing starts.
Q4: How does the software safety class change the testing?
A4: IEC 62304 assigns each software item a safety class of A, B or C based on the harm a failure could cause. A higher class calls for more detailed testing, documentation and traceability. We set the class early with your risk file, so test effort matches real patient risk.
Q5: Can you test software you did not build?
A5: Yes. We test software built by your team or another vendor, starting with a review of the requirements, the risk file and the existing evidence. Where the documentation has gaps, an MDR Assessment can map what is missing. We then build the test coverage and traceability needed to reach conformity.
Q6: How do you handle test automation and regression?
A6: We automate the tests that earn their keep across unit, API and UI levels. These run inside your CI pipeline, so every change triggers a regression run and a fix in one place cannot quietly break another. Manual testing stays for exploratory and usability work where a person sees more.
Q7: Do you cover usability and cybersecurity testing?
A7: Yes. We run usability evaluation to IEC 62366 for the intended users and environment, so use-related risks surface before launch. For security we test against the software threat model, from input validation to authentication and encrypted transport. Both feed back into design rather than sitting in a report.
















