Static Code Analysis Alone Is Not Enough:
Add Unit Testing & Code Coverage to Your Verification Program
Seven FDA enforcement cases. One consistent pattern: teams that passed system-level testing and managed static-analysis findings were still cited for missing code-level verification. This brief shows the gap - and how ESL closes it with unit testing and code coverage, added to the static analysis you already have.
1. The Gap Static Analysis Leaves Open
Static code analysis examines source code for defect patterns, unsafe constructs, and coding-standard violations. It is an essential layer of any medical-device software verification program - and it is what FDA inspectors increasingly expect to see. But static analysis has a structural limit: it examines code as text; it never executes the code.
That limit shows up in three ways that FDA findings repeatedly target:
No evidence of correct behavior
A clean scan cannot show that a function produces the right output for valid inputs, boundary values, invalid inputs, and error conditions. Only executed tests with expected results can.
No visibility into unexercised code
System-level black-box tests can pass while large parts of the internal logic - error branches, recovery paths, edge cases - are never executed at all. Without coverage measurement, nobody knows.
No proof that a fix worked
Correcting a reported coding pattern is not the same as demonstrating the required behavior is correct. FDA has cited companies for fixing source-code defects without validating the correction’s effectiveness.
“Executing code does not prove its result was correct.”- The central lesson of the seven FDA cases analyzed with ESL
2. Seven FDA Enforcement Cases at a Glance
ESL’s research into recent FDA software-related enforcement actions identified seven cases that illustrate this pattern. They are FDA enforcement findings at issuance - not seven demonstrated submission rejections - but together they map exactly where code-level verification evidence goes missing.
| Company | Letter date | Verification gap FDA identified |
|---|---|---|
| Inovo | Feb 19, 2015 | Missing code-level structural verification documentation, missing software validation procedures, and inadequate regression-testing procedures. FDA explicitly referenced static code checkers and independent code review. |
| Xoran Technologies | Dec 9, 2024 | System-level black-box testing without component/integration testing documentation; FDA questioned whether code coverage was commensurate with software risk. |
| Abiomed | Sep 19, 2023 | A source-code correction (a counter that failed to reset) was not validated to establish the fix’s effectiveness. |
| ZYTO Technologies | Jun 21, 2023 | Verification documentation marked “approved” despite no evidence that the specified tests had actually been executed. |
| Visgeneer | Jun 13, 2025 | Validation records could not be consistently tied to the tested software configuration; version inconsistencies across validation reports. |
| Compass International Innovations | May 23, 2011 | Retrospective validation lacked updated requirements, source-code evaluation, and user-site testing. |
| iRhythm Technologies | May 25, 2023 | A reuse process lacked verification of its required operational outcome - previous patient data was not verifiably erased before devices were distributed. |
The strongest direct precedent for unit testing and coverage is Xoran: FDA explicitly questioned whether code coverage was “commensurate with risk” and requested procedures for regression testing and adequate coverage. Abiomed supports defect-specific regression testing; ZYTO supports detailed execution reporting; Compass supports requirements traceability.
3. What Each Case Teaches - and How ESL Solves It with Parasoft
For every case below, the card links directly to the FDA letter and the specific observation, and shows how ESL would have closed that exact gap with Parasoft tools - extending the static analysis you already have with unit testing, code coverage, and traceable evidence.
Inovo - missing code-level verification
FDA Letter: Observation 4(a), p.3 ↗The FDA gap: missing software-development/validation procedures, missing code-level structural verification documentation, and inadequate regression-testing procedures. FDA explicitly referenced static code checkers and independent code review.
- Defined code-level verification (Parasoft C/C++test, dotTEST, PythonStator): static analysis executed through the real build with a versioned test configuration stored in the repository - a defined engineering activity with an executed record, exactly the artifact chain Observation 4(a) found missing.
- Documented regression procedure (cpptestcc changed-code analysis): every source change triggers an incremental scan and re-test of the changed code, with results retained per run - the regression procedure exists, is executed, and is demonstrable on demand.
- Independent code review, structured and recorded (Parasoft DTP review workflow): analyzer findings seed a recorded peer-review process with named reviewers and dispositions, replacing the undocumented reviews FDA criticized.
- Evidence over time (Parasoft DTP): dashboards retain every run’s findings, dispositions, and tool/configuration identity, showing continuous execution rather than a one-time scanner installation.
Net effect: code analysis becomes a documented, executed, and reviewable activity with regression and independent-review records - closing each element of Observation 4(a).
Xoran Technologies - system testing did not establish adequate internal testing
FDA Letter: Observation 2 ↗The FDA gap: system-level black-box testing without component/integration testing documentation; FDA questioned the regression analysis and whether code coverage was commensurate with software risk.
- Baseline code examination (Parasoft C/C++test static analysis): agreed MISRA/CERT/security configurations run over every owned component through the real build - documented, repeatable code-level examination of internal logic, not just product-level black-box results.
- Component and integration tests where none exist (C++test unit testing): auto-generated test harnesses and stubs for the modules the product-level suite never reaches, plus targeted tests for internal interfaces, boundary conditions, and error paths - with expected and actual results per test.
- Risk-matched coverage evidence (C/C++test coverage): statement and branch coverage (MC/DC where the risk file justifies it) per module, compared against the documented software risk classification - a direct answer to FDA’s “commensurate with risk” question.
- Regression records per change (cpptestcc changed-code analysis): incremental static analysis and re-testing restricted to changed code for every fix batch, enabling the retrospective review of earlier changes that the response omitted.
- Same workflow for mixed code and auditable aggregation (dotTEST, PythonStator, Parasoft DTP): C#/Python components get identical evidence, and findings, tests, and coverage are aggregated per module and linked to source revisions and configurations.
Net effect: each gap FDA cited - missing component/integration testing documentation, questioned regression analysis, and coverage not matched to risk - is closed by a named Parasoft capability with a retained artifact.
Abiomed - a corrected defect still needed verification
FDA Letter: Observation 2(B) ↗The FDA gap: a counter that failed to reset, allowing report data to carry over from a previous test, was corrected in source - but FDA found the corrective action had not been validated to establish effectiveness.
- Reproduce the defect as a test (C++test unit testing): an auto-generated harness with a test that exercises the counter-reset behavior and fails on the original code. A defect that can be reproduced in a test can be proven fixed.
- Demonstrate effectiveness (failing-before / passing-after record): the fix is accepted only when the same test passes on the corrected build, with both runs retained - the effectiveness validation FDA found missing.
- Verify nothing else broke (cpptestcc changed-code regression): incremental static analysis and re-testing of all code touched by the change, plus a full re-scan of the module, so the correction cannot silently introduce new findings.
- Link fix to evidence (Parasoft DTP): the change record connects the reviewed patch, the tool version, the source revision, and the passing test run, making the corrective action’s effectiveness auditable.
Net effect: the corrective action is validated by a reproducible test record rather than by the disappearance of the reported symptom - precisely what Observation 2(B) required.
ZYTO Technologies - approval without execution evidence
FDA Letter: QS Observation 1 ↗The FDA gap: verification documentation marked approved despite missing evidence that the specified tests were ever performed.
- Execution evidence generated by the tool, not typed by hand (C++test / dotTEST test runs): every test execution automatically produces machine-generated results with timestamp, tool version, configuration, and source revision - an approved document can only exist where a matching execution record exists.
- Execution history that cannot be backfilled (Parasoft DTP): results are uploaded as produced and retained server-side with run history, so “approved but never executed” becomes detectable by comparing approval dates against recorded runs.
- Automatic evidence index: the package for each module (scan results, test runs, dispositions, approvals) is generated from DTP with hashes and cross-references, replacing hand-assembled summaries.
- Tool validation built in: QMS validation of the analyzers uses the recorded tool version and configuration identity, so results are traceable to a validated tool state.
Net effect: approvals reference retained execution artifacts automatically - closing the approved-without-execution gap of QS Observation 1.
Visgeneer - validation evidence could not be tied consistently to the product
FDA Letter: Observation 1 ↗The FDA gap: missing configuration records for tested devices, and version inconsistencies across validation reports (2.1 vs 2.5) that were never explained.
- Every run bound to an exact configuration (C/C++test / dotTEST + cpptestcc): each scan and test execution records the source revision, analyzer configuration, and build inputs, so the tested configuration is identifiable after the fact.
- Version-to-version explanation (changed-code analysis): comparing the analysis results of version 2.1 against 2.5 produces an explicit list of what changed and which verifications remain valid - directly answering FDA’s unanswered version-discrepancy question.
- Configuration records for tested devices (Parasoft DTP): run history per release candidate is retained with build and configuration identity, giving the per-device configuration records FDA could not find.
- Acceptance criteria under control: rule sets, severities, and scope are fixed in versioned configurations; changing them requires a recorded change, preventing the broadened-acceptance-criteria practice FDA criticized.
Net effect: validation evidence carries its exact tested configuration and a documented path between versions - closing the traceability gaps of Observation 1.
Compass International Innovations - retrospective testing did not repair missing lifecycle evidence
FDA Letter: Observation 1 ↗The FDA gap: missing validation procedures and plans; later retrospective validation lacked updated requirements, source-code evaluation, and user-site testing.
- Source-code evaluation for the retrospective effort (Parasoft C/C++test static analysis): a full documented analysis of the existing source gives the retrospective validation the source-code evaluation element it lacked.
- Requirements-linked tests, not ad-hoc testing (C++test unit testing + traceability): tests are written against identified requirements with traceability maintained in Parasoft DTP, so the retrospective program has the requirements link FDA found missing.
- Validation procedures and plans that exist on paper first: the analysis plan, rule configuration, and test plan are written and approved before execution, so the retrospective record includes the missing procedures and plans.
- Prioritized, defensible scope: risk-ranked findings and coverage direct the retrospective effort to safety-relevant modules first, with dispositions recorded for every finding.
Net effect: retrospective validation is executed under an approved plan, with source evaluation and requirements traceability included - rather than repeating the incomplete program of Observation 1.
iRhythm Technologies - executing a process did not prove its intended outcome
FDA Letter: QS Observation 3 ↗The FDA gap: a reuse process lacked verification that previous patient data had been erased from circuit boards - products were distributed with prior patient data remaining.
- Outcome-based tests, not process-based ones (C++test unit testing): tests assert the required outcome itself - for example, that a data-erasure routine leaves no residue - rather than merely confirming that the erasure procedure was invoked.
- State hazards exercised (harnesses and stubs): auto-generated stubs simulate the reuse scenarios behind the finding - successive operations on the same hardware, stale data present, interrupted processing, and recovery after failure - each with expected results.
- Contributing defects found statically (Parasoft C/C++test): data-flow and security configurations flag uninitialized reads, missing cleanup paths, and unreachable error handling that could leave data behind, so code-level causes are fixed alongside the outcome tests.
- Proof the safety path is exercised (C/C++test coverage): coverage measurement confirms the erasure and recovery paths are actually executed by the tests, and changed-code regression keeps them tested on every future change.
Net effect: the required operational outcome is verified directly, including failure and recovery conditions - closing the gap of QS Observation 3, where the process ran but the outcome was never checked.
The strongest direct precedent for unit testing and coverage is Xoran: FDA explicitly questioned whether code coverage was “commensurate with risk” and requested procedures for regression testing and adequate coverage. Abiomed supports defect-specific regression testing; ZYTO supports detailed execution reporting; Compass supports requirements traceability.
4. Two Reasons to Add Unit Testing and Coverage - Straight from FDA Guidance
Reason 1 - Unit testing demonstrates expected behavior
Tests should derive expected results from requirements and design, including boundaries, invalid inputs, error handling, and safety controls. For Enhanced Documentation Level submissions, FDA recommends providing all unit and integration test protocols and reports - including expected results, actual results, and objective pass/fail determinations (FDA software submission guidance, section VI.H(2)).
Reason 2 - Code coverage identifies the gaps your tests never reached
A passing test suite may never execute a critical error branch. FDA’s software validation guidance relates structural coverage to risk, states that statement coverage alone provides insufficient confidence, and describes decision/branch coverage as a minimum for most software products (FDA software-validation guidance, sections 5.2.4-5.2.5). There is no universal mandatory percentage or universal MC/DC requirement - the right metric is the one commensurate with your software’s risk, exactly the question FDA asked Xoran.
5. How ESL Extends Your Static Analysis Program
ESL delivers unit testing and code coverage as a controlled extension of the static code analysis programs we already run for our customers. Our recommended engagement adds five core elements, completed by requirements traceability:
Evidence & gap assessment
Assessment of your existing tests, requirements traceability, and current coverage - identifying whether you have a code defect problem, a test gap, a documentation gap, or a combination.
Risk-based unit test development
Development of unit tests for identified gaps, with expected results derived from requirements - including boundaries, invalid inputs, error handling, and safety controls.
Coverage metrics & targets
Agreed, risk-appropriate coverage metrics and targets, with documented review and treatment of every uncovered code area.
Defect-specific regression testing
Every correction gets a test that reproduces the defect, verifies the fix’s effectiveness, and remains in the regression suite. Fixed code is verified, not just rescanned.
Final evidence package
Results, coverage, deviations, and reviews tied to the exact release candidate - source revision, build, and configuration - ready for your regulatory submission.
Requirements traceability
Import requirements, associate them with test cases, and identify requirements without linked tests - closing the lifecycle gap FDA cited at Compass and Inovo.
Tool support: Parasoft C/C++test
For C/C++ codebases, ESL builds this capability on Parasoft C/C++test, which unifies static analysis, unit testing, stubbing, and structural coverage in one platform: automatic test-case generation with configurable stubs for isolation, execution on host or target, coverage collection including branch, simple condition, and MC/DC, detailed test-execution reports (inputs, outputs, passed assertions, failures, execution logs), and requirements traceability. See the Parasoft white paper on unit testing with code coverage on target »
Reporting detail and requirements traceability must be configured and licensed before execution - ESL scopes both explicitly in every engagement, so your evidence is captured correctly the first time.
6. Unit Testing and Coverage on Target Hardware
For embedded medical devices, the behavior that matters lives on the target hardware - with its own embedded OS, constrained memory, and different toolchain. Host-based testing alone cannot expose target-specific defects, and attack surfaces of embedded devices are hard to simulate on a host. Cross-platform testing lets the same test suite run on host, simulator, and the actual target, with results and coverage collected back for analysis.
Traceability between test cases, test results, source code, and requirements must be recorded and maintained - which is why collecting test results and coverage data during target-based testing is critical for standards compliance (IEC 62304) and FDA submission evidence alike.
7. The Supportable Claim
ESL’s tools, engineering review, controlled remediation, and evidence workflow address the same types of verification failures FDA identified in these seven cases. Their value is earlier detection, verified corrections, and reviewable evidence. Complete regulatory acceptance remains dependent on the product, the full submission, and your team’s execution of its own responsibilities - automated analysis does not replace human review, and tests using stubs alone do not establish correct integration.
That is precisely why we state it this way, and why our customers’ auditors and reviewers accept it.
- Direct answers to the question FDA asked Xoran: is your coverage commensurate with risk?
- Verified - not just corrected - defect fixes, per the Abiomed finding
- Executed-test evidence behind every approval, per the ZYTO finding
- Baseline-attributable reports, per the Visgeneer finding
- A submission-ready evidence package aligned with FDA’s Enhanced Documentation recommendations
8. Sources and Further Reading
FDA Warning Letters (the seven cases)
- Inovo, Feb 19, 2015 - observation 4: original letter (Ofni Systems archive)
- Xoran Technologies, Dec 9, 2024 - FDA letter, observation 2
- Abiomed, Sep 19, 2023 - FDA letter, observation 2(B)
- ZYTO Technologies, Jun 21, 2023 - FDA letter, quality-system observation 1
- Visgeneer, Jun 13, 2025 - FDA letter, observation 1
- Compass International Innovations, May 23, 2011 - original letter (Ofni Systems archive)
- iRhythm Technologies, May 25, 2023 - FDA letter, quality-system observation 3
FDA Guidance Documents
- FDA software submission guidance - section VI.H(2): unit and integration test protocols and reports for Enhanced Documentation Level
- FDA software-validation guidance - sections 5.2.4-5.2.5: structural coverage and risk
- FDA OTS software guidance - sections III.C-D: testing and supplier assurance for off-the-shelf components
Parasoft
- White paper: How to Perform Unit Testing With Code Coverage on Target - cross-platform testing, target test executables, runtime library, and coverage collection (images in this brief are from this white paper)
- Parasoft C/C++test - static analysis, unit testing, stubbing, and coverage for C/C++
Ready to Close the Gap?
ESL will assess your current static analysis, test, and coverage posture and propose a risk-based plan for adding unit testing and code coverage - scoped to your codebase and your regulatory pathway.
Contact ESL - Engineering Software Lab - sales@eswlab.com • www.eswlab.com
Contact ESL →