Medical device software testing is the layered check that the code does what the spec says: unit, integration, system, plus the non-functional work (security, performance, usability) that 62304 class actually requires. It is not software validation (intended use), and it is not device design V&V.
If you meant software validation / intended use → medical device software validation. If you meant how the software is built (IEC 62304) → medical device software development. If you meant device verification vs validation / V-model → medical device verification and validation.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the 62304 / validation / vendor house.
Why the layers exist
A bug in a social app is an annoyance. A bug in pump firmware or a diagnostic model is a patient. Testing here is not “QA at the end.” It is the evidence that every requirement has a test, and that the test ran. IEC 62304 is the primary software-lifecycle standard; ISO 13485 / 21 CFR 820 are the QMS wrapper that says those tests are a controlled process. The lifecycle how-to is 494. This page is the test layers inside it.
Class A/B/C from 62304 sets how deep you go. Class C (death or serious injury possible) does not get a smoke suite and a shrug. Class A still needs a written argument that the software cannot contribute to harm. SOUP — libraries and OS you did not write — is in scope for risk and for the tests that bound that risk, even when you did not author the code.
Unit, integration, system
| Layer | Question | Typical evidence |
|---|---|---|
| Unit | Does this function do what it claims in isolation | Developer tests on a dose-rate calculator, a segmentation metric, an alarm threshold |
| Integration | Do the pieces hand off correctly | Calculator output reaches the motor controller; image header survives the PACS send |
| System | Does the whole software meet the spec as a black box | End-to-end scenarios on the integrated build, often in a simulated clinical environment |
Find the defect at unit cost, not at system cost. User acceptance / clinical-use testing is validation of intended use — that job is 498. Verify vs validate as device design V&V is 699 502.
Non-functional is not optional: usability under a noisy ward, security tests on the interfaces that exist in the field, performance at the load you claimed. SaMD on a patient’s phone adds OS versions, screen sizes, and other apps. That is still this page — more matrix, same layers.
Traceability and a plan
A test without a requirement is a demo. A requirement without a test is a hole. The matrix links user need → software requirement → design → code → the test case that passed. Example: “alarm if battery < 10%” traces to the alarm logic, the function, the case that simulates 9% and 11%, and the report line that says pass. Auditors walk that chain. They do not accept a slide.
The testing lifecycle around the layers: plan (scope, class, what “done” means), cases with inputs and pass/fail written before the run, execution and defect records, a summary that a stranger can read. That pack is what the QMS stores.
Tools, without the catalogue
You need a place that holds requirements and cases and the link between them (a requirements / test-management system). You need automation that can replay regression. You need static analysis on the code you ship. 21 CFR Part 11 matters if the tool holds electronic records and signatures. An audit trail of who ran what, when, is not a nice-to-have. Vendor names are not the point; a spreadsheet with no trail is the failure mode.
Risk (ISO 14971) tells you where to spend the hours: the dose algorithm gets more cases than the colour of a menu. Link the test to the hazard it bounds.
Automation for regression
Every change can break something that used to pass. Manual regression on a Class B/C device is how releases stall and how defects return. Automate the deterministic checks — units, interface contracts, the alarm matrix — and leave humans the exploratory and usability work. Change control plus a green regression suite is how a patch stays as safe as the release you already filed.
FAQ
Verification or validation?
Verification is this page’s centre of gravity: built to spec, layer by layer. Validation is “the right software for the intended use.” You need both. The validation how-to is 498.
Do I test every piece of software for 62304?
You test the medical-device software you wrote, to the class. You still risk-assess SOUP and bound it. “We didn’t write the OS” is not a pass.
What is different about SaMD?
You do not control the hardware. Matrix the OS, the device class, the network. Re-validate on the update cycle the store will force. Cybersecurity is a test, not a paragraph in the README.