DEV Community: Dzmitry Lubneuski

Why Medtech needs QA for compliance

Dzmitry Lubneuski — Mon, 17 Aug 2026 13:58:29 +0000

When a software defect can harm a patient, compliance turns into the mechanism that protects them. It builds a verifiable chain from risk to requirement to test, so medtech teams can show auditors clear proof of control and give clinicians confidence at the point of care.

Medical device software operates in a completely different reality than consumer applications. A coding error in a streaming app might cause frustration, but a similar error in a clinical device, like an insulin pump, could directly harm patients. This fundamental difference in risk is precisely why regulatory bodies approach software validation with such scrutiny.

The concern is also growing. FDA officials reported that Class I medical device recalls increased by 232% between 2020 and 2025. In 2026 alone, the FDA’s public list of serious medical device recalls and early alerts includes issues involving insulin pumps, infusion pump software, ventilators, pacemakers, heart pumps, blood glucose monitors, anaesthesia equipment, dialysis bloodline sets, and paediatric care beds.

Medtech QA also has to match updated US quality rules. The FDA’s Quality Management System Regulation, effective February 2, 2026, brings US medical device rules closer to the ISO 13485:2016 quality standard. For QA teams, this means testing needs to do more than confirm that the software works. It also has to create clear proof that risks were managed, design choices were checked, suppliers were controlled, issues were fixed, and post-release feedback was acted on.

For auditors, testing is the formal process of generating traceable proof that every risk is controlled. Failing to provide this specific proof, the link between a risk and its test, is seen as a fundamental safety failure, which translates directly into lost revenue and competitive disadvantage.

The following testing types represent where this proof and rigorous testing converge to create the compliance foundation that regulators evaluate.

1. Risk-based & functional testing

Risk management per ISO 14971 underpins the entire product lifecycle, with testing providing the evidence that risk controls are effective. This standard is important because it provides the framework for transforming abstract clinical risks (like an incorrect dosage) into testable control mechanisms (like input validation). The QA team's role is to execute specific tests that prove these controls work:

Risk-based functional tests: Verifying that the software behaves as expected under both normal and invalid conditions, directly testing the risk control.
Boundary value analysis: A more rigorous form of testing that focuses on the edges of acceptable inputs (e.g., minimum and maximum values) where errors are common.
Fault injection: Deliberately forcing error conditions (e.g., simulating a sensor failure) to verify the software fails safely, such as by triggering an alert.
The traceability mandate: QA is responsible for creating and maintaining the Requirements Traceability Matrix (RTM). This is the auditable backbone of the project, linking every requirement to its risk control and its test. A design control deficiency is often a finding that this matrix is broken or incomplete.

2. Software lifecycle & code-level testing

This category of testing is dictated by software lifecycle standards, such as IEC 62304, which require a process that ensures software quality and safety. This standard works in tandem with the system-level risks from ISO 14971. Higher-risk software (like Class C, which could cause serious injury) requires more thorough testing. The QA team's role is to ensure these specific testing types are performed:

Static code analysis: Using automated tools to scan source code for vulnerabilities, bugs, and deviations from coding standards before the software is even run.
Formal code reviews: A documented, manual process where peers review code to ensure it is correct, maintainable, and adheres to design and safety requirements.
SOUP validation: Formally testing Software of Unknown Provenance (SOUP), any third-party or open-source library. The manufacturer inherits 100% of the risk for this code, and QA must prove it meets safety and performance requirements.

3. Usability & human factors testing

Usability testing helps ensure that a device's software interface is clear and safe to use. This testing, guided by standards like IEC 62366, is an essential risk-control activity to prevent user errors. QA must ensure this testing happens at two key stages:

Formative tests: Exploratory tests run during development, where users think aloud while performing tasks. This helps the team find and fix design flaws early.
Summative tests: This is the final, formal pass/fail validation of the finished product. While the IEC 62366 standard defines the process, regulatory bodies like the US FDA strongly recommend a minimum of 15 representative users per user group (e.g., 15 patients, 15 clinicians) to provide strong validation data.

4. Cybersecurity & security testing

New laws in both the US (Section 524B) and EU (MDR GSPR) make cybersecurity testing a requirement. A failure here can lead to an automatic refuse to accept status. These laws require proof that the device is secure. QA must oversee a layered testing approach to build this proof:

SAST (Static Application Security Testing): Automatically scanning the code for security flaws before it's run.
DAST (Dynamic Application Security Testing): Testing the running software from the outside to find weaknesses.
Penetration testing: Using security experts to try and hack the software to find flaws a real-world attacker would use.

5. Performance & load testing

Performance failures, like a lagging UI during an emergency or system freezes, are clinical risks. Testing must validate that the software performs reliably under real-world conditions, as required by the EU's General Safety and Performance Requirements (GSPR). Testing types include:

Load testing: Simulating concurrent usage, such as many devices reporting to a central server at once.
Stress testing: Pushing the system beyond its expected capacity to identify failure points and, critically, to verify it recovers gracefully without data corruption.
Soak testing: Running the system under a normal load for an extended period (e.g., 48-72 hours) to find subtle, long-term issues like memory leaks or resource depletion.

6. AI/ML model validation

Artificial intelligence introduces a new validation challenge: proving both the code and the data are safe. This requires a new set of testing protocols to address unique risks. QA's validation role includes:

Data validation: Examining the training and test datasets for completeness, accuracy, and potential bias that could affect clinical outcomes across different patient populations.
Model robustness testing: Challenging the AI with adversarial or out-of-distribution data (scenarios it was not trained on) to verify its performance boundaries and ensure it fails safely.
Understanding regulatory paths: The validation strategy must account for divergent global frameworks. The FDA's PCCP framework provides an adaptive path, allowing QA to help document a plan to get the process of future changes pre-approved. Concurrently, the EU AI Act provides a prescriptive path, requiring QA to comply with a legal layer that classifies most AI devices as high-risk by default.

7. Interoperability & data exchange testing

As devices connect to hospital Electronic Health Records (EHRs), their ability to safely exchange data is a compliance area mandated by laws like the 21st Century Cures Act. QA must validate that data is sent correctly and securely using established healthcare standards.

Standards validation: Testing compliance with data standards like HL7 v2 (the legacy standard) and FHIR (the modern API-based standard).
Profile conformance: Proving the device can function in a real hospital ecosystem. This involves testing the device against specific clinical profiles to ensure it can correctly and safely communicate with other systems.

8. Continuing compliance: post-market monitoring

This area is about ensuring safety and compliance after a product is launched. This closed-loop process is an important part of keeping tabs on real-world performance. Regulators mandate that all manufacturers have systems in place for this, which generally involves two parts:

Medical device reporting: Fulfilling the legal duty to report serious incidents to regulatory bodies within their strictly enforced timelines.
Proactive surveillance: Systematically gathering data from the field to analyze trends and identify potential issues before they become serious incidents.

Integrating compliance into the modern SDLC

Treating these testing areas as a final checklist is a common pitfall. This approach creates a compliance bottleneck, where all validation is saved for the end, delaying release and isolating safety from development.

A modern, more effective approach is to weave these activities directly into the development process, such as Agile and DevOps. This integration creates a digital thread, an auditable, real-time link between a requirement, its risk, the code, and its test. Instead of a linear V-model of development, compliance becomes an iterative part of every sprint, following a feature from its conception to its post-release monitoring.

In planning: The risk analysis and usability requirements are not just QA documents; they are the source of truth that defines the User Stories for the development team.
In development: A feature isn't done when the code is written. The "Definition of Done" for a sprint becomes an auditable checkpoint that now includes: code written, unit tests passed, risk controls verified, and the traceability matrix updated.
In CI/CD: The automated pipeline becomes the first line of compliance. It automatically runs code scanning (SAST) and dependency checking (SCA), preventing non-compliant code from ever being merged.
In validation: Formal testing (performance, interoperability, and the final summative usability test) becomes the last step to validate the entire integrated system before release.
After release: The post-market monitoring loop is just another form of production observability. Real-world data from logs and user reports feeds directly back into the product backlog to drive the next patch or version.

Conclusion: From validation to assurance

This integrated approach transforms compliance from a pre-submission bottleneck into a continuous process. It marks a fundamental shift in regulatory thinking, moving from old models of Computer System Validation (CSV), which were documentation-heavy and often treated all features as equal, to a modern philosophy of Computer Software Assurance (CSA).

This new, risk-based approach encourages critical thinking and focuses rigorous testing on high-risk functions while reducing the burden for low-risk ones. By building quality into the development cycle, teams can build safer products, experience fewer post-market issues, and achieve faster, more predictable regulatory approval. It shifts the mindset from doing this for the auditors to doing this to build a better, safer product.

Full-cycle testing: hands-on tips to troubleshoot QA hurdles

Dzmitry Lubneuski — Fri, 30 Aug 2024 17:54:42 +0000

With the rapid advancement of digitization and cutting-edge technologies, modern IT products are becoming increasingly complex. Open banking systems, eCommerce platforms, CRMs, ERPs, CMSs, AR/VR-based games, dApps, and virtual fitting rooms are all marked by intricate business logic, multifaceted architectures, numerous dependencies, integrations, and even the incorporation of big data. These products often include sophisticated features, such as biometric authentication. For example, virtual fitting rooms may offer 3D body scanning, augmented reality integration, fabric simulation, size recommendation engines, and virtual try-on capabilities, enhancing the online shopping experience.

Ensuring their failsafe operation is also becoming more challenging. Sporadic or chaotic testing activities can only aggravate a situation and cause insufficient test coverage, issues slipping into the production environment, missed deadlines, and even increased costs because of rework.

Luckily, these can be mitigated with full-cycle testing. But how to ensure its effectiveness and efficiency? In this article, we provide a closer look on this concept, its ubiquitous obstacles, and approaches for surmounting them.

The what, when, and why of full-cycle testing

Full-cycle testing can be characterized as an all-encompassing QA approach that starts from the early phases of the Software Development Life Cycle (SDLC) and continues through post-release support. This continuous, holistic testing process consists of the following essential, sequential activities: delving into requirements, planning, preparing a test approach or creating a test plan, creating a test model, developing test cases (including automated scripts), generating high-quality test data, setting up environments, conducting tests, creating reports, and post-release monitoring.

Companies should consider implementing Full cycle testing in several scenarios. Complex IT products that possess various integrations and rapidly accrete new components should be continuously verified to prevent new defects and crashes. Ongoing releases also require regular QA supervision to ensure they operate as intended. Full cycle testing is also a good choice when organizations need to make sure their software complies with regulatory demands. Finally, development projects that span for years and incorporate legacy code should also be supported with QA.

When applied correctly, full cycle testing provides multiple benefits to project teams, allowing them to significantly extend test coverage, find errors early, improve software quality, and minimize the chances of rework. In addition, when IT products operate like clockwork, end users will probably like them and may even advertise it by word-of-mouth recommendations.

Full-cycle testing challenges: things aren’t always simple

Testing is a momentous step vital for ensuring correct software operation. However, project teams can confront QA challenges that may complicate reaching set objectives. It’s important to be aware of them and know how to address them with a well-tuned test strategy.

Pressing deadlines

Almost half of all respondents of the latest report stated that the shortage of time has become one of the key problems when ensuring software quality. We all understand that meeting milestones is hardly possible without sticking to a set schedule. However, when QA engineers follow a tight release timetable and perform a myriad of tasks in no time, of course, software quality can be compromised, and overtime can become QA engineers' constant companion.

Poor interaction

There's a risk that when collaboration between QA engineers, software developers, business analysts, and other stakeholders is insufficient—particularly in globally distributed teams—the work environment can become unstable, and confusion may arise. This can slow down decision-making and compromise the quality of work. To mitigate these risks, it's important to adopt clear communication strategies and utilize collaboration tools that facilitate thorough discussion and planning of software requirements, potential challenges, and user journeys. By ensuring effective coordination, teams can maintain project stability and deliver high-quality outcomes, regardless of team location.

Shortage of experts

The ratio of QA engineers to software developers is of high importance, if an imbalance occurs, risks related to small test coverage may arise, leading to late identification of defects, security vulnerabilities, software inability to cope with high loads, and other problems that can negatively affect end-user experience.

Issues with requirements

Vague, missing, or constantly changing requirements introduce significant complexity, as QA engineers rely on them as the foundation for planning the scope of work and defining necessary activities. When requirements are unclear or unstable, project teams may end up with incomplete test cases, which can lead to issues in the production environment.

Continuous technological upgrade

IT ecosystems are changing at a fast pace. State-of-the-art development solutions, such as frameworks, libraries, or tools, appear quite often. It means that if QA engineers don’t upgrade their competencies and QA techniques on an ongoing basis, they likely won’t manage to ensure efficient quality control activities and may skip critical or major issues.

Incorrect priorities

Prioritizing test cases based on the criticality of features for business success is crucial in any software development project. This ensures that key functionalities, such as payment processing and product catalogs in eCommerce solutions or billing, service activation, and bandwidth management in telecom software, operate as required. If priorities are incorrectly defined, there is a risk of unoptimized testing efforts, which can lead to insufficient focus on the most critical areas, potentially compromising the overall quality and reliability of the product.

Problems with test environments

QA engineers are responsible for properly setting up testing environments, ensuring they closely resemble the production environment to the greatest extent possible, and contributing to their stability. Working with test data is another essential activity—in fact, according to the World Quality Report 2023-2024 (WQR), 69% of organizations are working on implementing a company-wide test data provisioning strategy. QA specialists must adopt a specific approach to ensure that the data used is relevant, diverse, complete, and protected. Without effective management of these activities, there is a risk of invalid testing outcomes, which can affect the software's quality.

Small test coverage

Regardless of the type of software testing, test coverage is one of the most crucial aspects that QA engineers must focus on. It represents the extent of code covered by various QA verifications, serving as a key indicator of overall IT product quality. When test coverage is insufficient, the risk of undetected issues increases, leading to potential problems in production and higher maintenance costs. Therefore, ensuring adequate test coverage is essential to minimizing risks and maintaining software quality.

Low effectiveness of automated workflows

Test automation serves as a powerful tool to improve the capabilities of manual QA engineers. The WQR interviewees stated that it helps minimize risks (54%), boost test efficiency (52%), decrease the number of live defects (51%), and speed up time to market (42%). Its improper introduction or ineffectiveness can cause issues with stability and further maintenance.

QA solutions to surmount full-cycle testing challenges

Considering above-mentioned risks, it’s a good idea to understand how they can be mitigated by testing best practices.

1. Ensure productive communication

The success of any activity involving more than two people relies heavily on open and effective communication, particularly in software development projects where QA engineers, developers, business analysts, product owners, and other stakeholders work together as distributed teams to release robust IT products.

Establishing stable interaction channels for both synchronous and asynchronous communication is crucial, along with introducing tools that facilitate transparent and easy monitoring of all project activities. Regular team meetings are also essential to discuss questions, progress, and problems, ensuring that everyone is informed about relevant project aspects and milestones. Team members should practice active listening, maintain respectful behavior, and work to prevent escalation, especially during conflicts, to foster a collaborative and productive environment.

2. Improve requirements-related processes

To ensure consistent test cases and prevent defects in the production environment, it's crucial that requirements are always complete and up to date. QA engineers should actively clarify any ambiguities with other team members and promptly update test documentation as changes arise. While documenting the requirements is primarily the responsibility of business analysts, QA specialists play a critical role in analyzing the impact of any changes or omissions in the requirements. They must assess how these changes affect the software and the existing test cases, ensuring that test documentation is accurately adjusted to reflect the current state of the project..

3. Decide what tests to execute first

QA managers should apply several critical practices to prioritize testing effectively. First, they need to analyze existing requirements and create a traceability matrix to ensure each requirement is covered by one or more test cases. Based on the criticality of the requirements to the business, managers can then decide which cases should be executed first. Regular meetings should be held to reassess priorities, especially if there are changes to the requirements, ensuring that testing efforts remain aligned with project goals.

4. Cultivate a culture of continuous education

Even if a company faces temporary constraints in hiring new project team members, it can still invest in improving the skills of its existing staff. Beyond smart prioritization of test cases and enhancing test automation, companies can focus on upskilling their current resources. By offering practical-oriented courses, facilitating knowledge transfer, and establishing Centers of Excellence (CoEs) and Research and Development (R&D) initiatives, companies can significantly boost the efficiency of their QA engineers and overall project outcomes.

5. Introduce continuous testing (CT)

Continuous Testing (CT) is essential for minimizing challenges in full-cycle testing CT ensures ongoing, early, and automated testing throughout the entire SDLC. This approach enables QA engineers to increase test coverage, identify issues of varying severity earlier, and reduce the risk of defects in the production environment. CT also provides continuous feedback on software quality, helping to make timely improvements and increasing the velocity of the testing process, which contributes to meeting quality gates on time.

6. Consider agile testing approaches

Unlike the Waterfall model, where testing is conducted near the end of the development cycle, Agile emphasizes continuous quality assurance activities throughout the process. Agile testing involves close and open communication among all project members, high flexibility to adapt to changing conditions, and a focus on customer needs. By adopting Agile testing approaches, QA engineers can enhance team collaboration, test software in parallel with development, manage evolving requirements more effectively, and reduce the risk of software issues.

7. Boost capabilities of automated workflows

To ensure the effective adoption of test automation and achieve reliable results, QA engineers should carefully identify which tests are best suited for automation, such as regression, performance, and cybersecurity tests that require frequent execution. They should prioritize the scope of automation and consider both functional and non-functional requirements to maximize test coverage. Additionally, ensuring the stability of test environments and selecting a toolkit that aligns with the team's competencies and project specifics are crucial. As software functionality expands over time, it’s advisable to write short, independent automated scripts and regularly update them to facilitate more effective maintenance.

Closing thoughts

Although full-cycle testing provides various benefits, such as sped up time to market, minimized chances of production defects, early identification of issues, or lessened probability of rework, QA teams can still confront challenges, impeding its effectiveness.

To successfully overcome them, companies can introduce CT and Agile testing, improve test automation effectiveness, establish a communication framework, ensure high quality of requirements, prioritize test cases, and stick to continuous learning.