Software Verification vs. Validation: Evidence That Holds Up

Most software teams I work with can show me thousands of passing tests. Fewer can tell me which of those tests show that the device does what clinicians actually need. We say verification and validation as one word, V&V, and that habit hides a real gap. When a reviewer asks how you know the software is fit for its intended use, a stack of green unit tests is not the answer. In this post I separate the two activities, show where the standards draw the line, and lay out what I check before a software V&V package goes to a reviewer.

Two questions, two kinds of evidence

Verification asks whether we built the software right: does each design output meet the input it was derived from? Validation asks whether we built the right thing: does the finished device meet user needs and its intended use, in the environment where it will be used?

The distinction matters because the failures look different. A verification gap means a requirement was never tested, or was tested against the wrong build. A validation gap means every requirement passed and the device still does not work for the person using it. Both surface in audits, but the second one tends to surface in complaints first.

Where the standards draw the line

ISO 13485:2016 treats them as separate design control steps: clause 7.3.6 for design verification and clause 7.3.7 for design validation, each with its own planned arrangements, acceptance criteria and records. Since February 2, 2026, that structure is also the US expectation, because FDA's Quality Management System Regulation incorporates ISO 13485:2016 by reference.

IEC 62304 sits almost entirely on the verification side. Clauses 5.5 through 5.7 cover unit verification, integration testing and software system testing, and the standard states that validation and final release of the medical device are outside its scope. This is a frequent source of confusion. A team completes clause 5.7 system testing and believes the software is validated. It is verified. Validation happens at the device level, with representative users, representative units and the intended use environment.

One more boundary worth keeping: software that runs your quality system or manufacturing process is not product software. Its validation falls under ISO 13485 clauses 4.1.6 and 7.5.6, and that is where a risk-based computer software assurance approach fits. Keep the two vocabularies out of the same plan.

Building verification that holds up

Good verification is deliberately unexciting. Every test traces to a requirement, every requirement has an acceptance criterion someone can measure, and every result is tied to a specific software build. This is what I look for:

• Requirements written to be testable, one behavior per requirement, with a measurable pass condition
• Two-way traceability from software requirements to tests and back, including the risk control measures from your ISO 14971 file
• Test protocols approved before execution, with the software version and test environment recorded at the time of execution
• A written regression rationale for every change made after formal testing, covering what was re-run and why the rest was not
• Anomalies handled through the IEC 62304 clause 9 problem resolution process, with a risk-based rationale for any deferred past release

Practitioner note: On one program the system test report showed every protocol passing, and the reviewer's first question was which build had been tested. The protocols had been executed across three builds over several weeks, and the report named only the last one. We spent two weeks reconstructing a regression rationale that should have been written as we went. Since then I ask for the build identifier on every executed protocol page, not just on the summary.

Validation is about the user, not the code

Design validation for a software-driven device uses production-equivalent software on representative hardware, operated by people who match the intended users, in conditions that match intended use. It draws on more than test cases:

• Usability evaluation under IEC 62366-1, including summative evaluation of the critical tasks
• Clinical or performance evaluation appropriate to the device and its claims
• Confirmation that risk control measures are effective in actual use, not only on the bench

Validation inputs are user needs and intended use, so they have to be written down before design starts. If the only documented needs are the software requirements, validation has nothing independent to check against, and it collapses into a second run of system testing.

What FDA expects to see in a submission

FDA's final guidance on the content of premarket submissions for device software functions, issued in June 2023, scales testing documentation to the documentation level. For Basic documentation it asks for a summary of unit, integration and system testing, the software version tested, a system level test protocol and report, regression testing where it applies, and a record of changes made in response to failed tests. Enhanced documentation adds the unit and integration level test protocols and reports. At either level, the system test report should show that any unresolved anomalies were deferred on the basis of a risk assessment.

Notice what is missing from that list: a bare pass count. Reviewers want the protocol, the expected result, the observed result and the build. If you cannot produce those quickly, expect questions.

Closing perspective

Verification and validation answer different questions, and a credible design history file keeps them apart. Verification shows the software meets its specification; validation shows the device meets the needs of the people who use it. Write user needs early, keep traceability current, tie every result to a build, and treat IEC 62304 system testing as necessary but not sufficient. If you are planning a software V&V strategy or preparing test evidence for a submission, I would be glad to talk; reach out at softwarequality.guru/contact.