Medical Device Software Testing: Standards, Strategies, and Tools

Developing medical device software demands rigorous testing to ensure patient safety and regulatory compliance. Such software often runs on hardware with real-time constraints and in life-or-death situations, making thorough testing non-negotiable.

At Scythe Studio, we specialize in Qt/C++ embedded medical applications and approach testing with an expert, systematic methodology. This article outlines our technical perspective on testing, covering:

 

• industry standards (IEC 62304, ISO 13485, FDA guidelines),
• test methodologies (unit, integration, system, verification & validation),
• tools for Qt/C++ (Squish, Google Test, CppUnit, static analysis),
• and how we manage traceability, risk, and documentation throughout the process.

In this article, we share practical insights from real medical device projects to illustrate best practices in medical device software quality assurance. All in the realms of this highly regulated domain.

In future articles, we will probably touch on how to tie all these concepts together into a single, working and possibly automated testing process.

 

Regulatory Standards and Requirements for Medical Device Software Testing

Some people may curse regulatory bodies for setting such high requirements when it comes to medical device software development. In practice, I even like it because in the world of software development, there is a lot of talk about quality and testing, and at least here, software testing and quality assurance is not empty talk.

 

Let’s see what regulatory requirements we have to deal with.

 

FDA Regulations

Medical device software testing is governed by strict international standards and U.S. FDA regulations that dictate how we plan, execute, and document tests. The FDA’s Quality System Regulation (21 CFR Part 820) requires manufacturers to establish and maintain procedures for validating the device design, including software validation and risk analysis.

Compliance with FDA regulations ensures that testing is traceable, repeatable, and aligned with patient safety objectives. In addition, FDA guidance emphasizes the importance of documenting how software performs under both normal and fault conditions, reinforcing the need for thorough and risk-aware testing strategies.

 

IEC 62304

IEC 62304 is the international standard for medical device software life cycle processes, covering development from planning to maintenance. It classifies software safety by risk (Class A/B/C) and requires testing throughout the development life cycle to verify that the software meets its intended use and design requirements. The depth of software testing depends largely on the class of the device.

In practice, IEC 62304 expects requirements-based testing, functional testing, and risk-based testing as part of the verification strategy. The standard also requires final software validation in the actual operating environment to ensure the device software safely fulfills its intended purpose.

In short, risk management and comprehensive testing are key under IEC 62304, especially for higher-risk Class C systems.

 

ISO 13485

ISO 13485 is the international Quality Management System (QMS) standard for medical devices software that affects how we test. Medical device manufacturers implementing ISO 13485 have to include formal design controls and ensure that processes like verification and validation are planned and documented.

ISO is not a regulation per se, but it’s a standard that is desired for medical device developers. It plays a key role in test process management by ensuring comprehensive documentation, standardized processes, and continuous improvement.

 

As we have ISO 13485:2016 standard implemented at Scythe, (and FDA’s similar Quality System Regulation), we maintain detailed test plans, procedures and results as part of the Design History File, providing full transparency and traceability of testing.

Every decision – from tool selection to test coverage – must be justified and recorded according to the QMS. This means our testing activities are not only technically sound but also audit-ready, with evidence that requirements are verified and any anomalies addressed.

 

Testing Methodologies for Embedded Medical Software

We use a multi-layered testing strategy to systematically verify medical device software – from low-level code units up to the complete system. Testing software wouldn’t exist without automated and manual testing methodologies.

Key testing methodologies are:

 

• Unit testing,
• integration testing,
• system testing
• usa
• well-known manual testing.

 

Each level targets different types of defects, aligning with the development process where low-level tests verify detailed design and higher-level tests validate against user needs. Below, we describe each testing level except manual, testing process, and how it’s applied in a medical device software context:

 

Unit Testing

In unit testing, we focus on the smallest software components – individual functions, classes, or modules – to ensure they behave correctly in isolation. We mock or simulate hardware components or external service dependencies to perform deterministic off-target tests.

Reliable unit performance is crucial because even minor issues like calculation errors can impact patient safety. Unit testing also helps us maintain coding standards and detect potential issues early using static analysis tools to identify problems such as buffer overruns.

The goal of the unit testing process is to make sure that each single function of the device software fulfills its role in the expected way.

 

Example

Let’s take a simple example. When testing an infusion pump, we might verify the accuracy of the dose calculation algorithm.

 

 

Integration Testing

Proper medical device testing includes making sure that separate medical devices or components building one system interact robustly. We typically perform these tests on target hardware or simulators to uncover problems related to memory constraints or task scheduling.

In the realities of medical device development using Qt and C++, integration testing often involves verifying that Qt signals and slots are correctly connected and that threads operate without deadlocks, preparing the system for comprehensive system testing.

 

Example

In a Qt-based mobile app communicating with a glucometer, you should implement a mechanism to test communication and timing between those two elements. For medical devices of higher risk, performance testing should also be done.

 

 

System Testing

In system testing, we evaluate the fully integrated software and hardware against all defined functional, performance, and safety requirements within realistic usage scenarios. This stage involves treating the software as a black box and verifying its external behaviour.

We simulate clinical workflows and scenarios, such as patient monitoring, alongside performance (response time) and fault-handling tests. We heavily use automated regression tests, using tools like Squish, to verify software stability after changes.

You have to remember that having a proper testing process in place is part of risk management. It’s how you ensure patient safety. Testing medical devices means mitigating risks.

 

Example

System tests on an MRI machine involve running the GUI, control software and imaging algorithms together to ensure accuracy and safety compliance.

 

Tools and Frameworks for Medical Device Software Testing

We use a set of testing tools and frameworks tailored to C++ and Qt development to implement the above methodologies efficiently and reliably. Using the right tools helps us automate tests, enforce coding standards, and gather verification evidence.

Below are some of the tools we use and how they fit into our Qt/C++ medical software testing workflow:

 

1. Unit Testing Frameworks (C++)

For low-level testing of our C++ code, we use frameworks like:

 

• QTest
• Google Test,
• CppUnit
• and occasionally other software testing frameworks depending on the project.

Google Test (gtest) is particularly suited for embedded systems, supporting modern C++ features and detailed test reporting. We often configure it to output JUnit XML results for integration with CI systems.

In legacy projects, we encounter CppUnit, another xUnit-style framework. These tools support test-driven development (TDD), allowing us to test on PCs or directly on embedded hardware via cross-compilation, ensuring our logic is reliable and regression-tested.

Medical systems of the highest class (C, according to IEC 62304, or III for FDA or MDR) require 100% test coverage.

 

Measuring test coverage

If you are looking for tools that will help you measure unit test coverage, you might want to have a look at gcov, which isa free and open-source tool that analyzes whether a program executes each line of code. It’s for GCC compiler only so it means that it’s mostly for Linux-based medical devices.

There are also paid options that you can employ in your software development process like Coco which is part of Qt’s Quality Assurance offering.

 

 

2. GUI and Integration Testing Tools

Testing the GUI of Qt embedded applications is tricky, so we use Squish, a GUI automation tool for Qt interfaces. Squish automates user interactions (touch, clicks, keyboard) and validates UI responses remotely on embedded devices.

We write scripts in Python to simulate user workflows, automating otherwise manual tests. Squish supports testing required by standards like IEC 62304, and it’s quite useful as GUI testing often means integration testing as what UI does is calling features behind it.

For advanced integration-level tests, we combine Squish with other tools or write custom test harnesses.

 

 

3. Static Analysis and Code Quality Tools

Static analysis helps to ensure quality by detecting:

• memory leaks,
• buffer overruns
• or standard violations early.

Tools like qmllint and Clang-Tidy are used in most of our embedded C++ projects. Coverity finds issues like null dereferences and concurrency problems, enforces MISRA C++ and other standards.

Axivion Suite, certified for IEC 62304 Class C, provides additional verification. Integrating static analysis in our build pipelines maintains high code standards and prevents costly late-stage bugs, also producing documented verification evidence.

For performance-critical embedded code, we use profilers (Valgrind/callgrind or ARM-specific) to verify timing requirements, complementing functional testing.

 

 

4. Continuous Integration (CI) and Test Management

Automation servers and CI/CD pipelines (Jenkins, GitLab CI, GitHub Actions) tie our testing tools together, providing feedback on test results after each commit.

What we do is organize a test environment in Docker containers so the testing environment can be quickly set up on other devices without a need to spend long hours on installing all dependencies.

Embedded targets use hardware-in-the-loop or simulation environments integrated with CI, so builds are validated realistically. CI ensures that consistent, rigorous testing is required for regulatory compliance.

 

Traceability, Risk Management, and Documentation

Testing medical device software isn’t just about running tests – it’s equally about proving coverage and compliance. As it’s one of the regulatory requirements, we practice strict traceability, risk management and documentation to ensure every requirement and risk is covered by a test and we have a paper trail to prove it.

 

Requirements Traceability

For each software requirement (functional, performance, safety) we have at least one corresponding test case. A traceability matrix links requirements, design elements, tests and results, either in a requirements tool or document. It allows tracing from requirements to verifying tests and vice versa.

This ensures full test coverage and proves verification during regulatory audits or FDA submissions. Hazard-related requirements derived from risk analysis (ISO 14971) are traced separately in a Hazard Traceability Matrix.

 

Risk-Based Testing

We test according to risk, following ISO 14971 practices. High-risk functionality gets extensive and early testing, including normal, edge, and fault scenarios.

Documented rationale aligns testing rigor with risk level, clearly distinguishing between critical and cosmetic features. Each software risk mitigation corresponds to a verification activity, documented in traceability matrices or risk tables.

 

Example

Critical dosage calculations get full testing. Risk control mechanisms (alarms, redundancies) get fault simulation according to IEC 62304 guidelines.

 

 

Documentation and Compliance Evidence

Our testing generates a lot of documentation required by ISO 13485 and FDA regulations. Key artifacts include Software Test Plans, detailed Test Protocols, and Test Reports with objective evidence (e.g., logs, screenshots, data logs), and usually, all of that becomes a part of the final documentation submitted to regulatory bodies.

We improve test quality through version control, peer reviews, and automated test scripts. Auditors review these documents and traceability matrices to verify compliance, so we treat documentation as an integral part of testing and maintain strong traceability for easier audits.

Compliance with standards like IEC 62304 and ISO 13485 is ensured through a structured testing approach: unit, integration, and system-level testing.

Strict traceability between requirements, risks, and test results increases transparency and confidence. Early, risk-driven testing leads to higher reliability and smoother regulatory approvals.

 

Conclusion

As a medical technology engineering team, we see testing as continuous throughout development, including regression testing and documentation updates. Our approach ensures software quality, functional correctness, and validation in real-world usage. Good engineering practices and compliance to medical software standards are the basis of our strategy, resulting in safer and better medical devices.