Does IEC 62304 Really Require Unit Testing?

Ask a medical device software engineer whether unit testing is mandatory and the answer will often be an immediate yes.

But is that what IEC 62304 actually requires?

The answer is more interesting, and more useful, than a simple yes or no.

Verification is not necessarily testing

IEC 62304 distinguishes between software unit verification and software unit testing. Verification establishes whether a software unit satisfies its specified requirements and acceptance criteria. Testing is one method of achieving this, but it is not the only one.

Structured code reviews, static analysis, formal techniques and dynamic tests can all contribute to unit verification. The standard's requirements also depend on the Software Safety Class.

• Class A: the specific unit verification activities applicable to Classes B and C are not mandated.
• Class B: documented software unit verification is required, but dynamic unit testing is not universally prescribed as the only method.
• Class C: additional unit acceptance criteria apply, increasing the expected rigour.

The distinction matters: verification is mandatory for Classes B and C, but dynamic testing of every software unit is not universally mandated by IEC 62304.

That does not mean manufacturers should avoid unit testing. For safety-related algorithms, state machines and complex calculations, dynamic unit tests can provide valuable evidence that alternative methods may not adequately replace.

FDA Basic and Enhanced: another common misunderstanding

FDA's guidance Content of Premarket Submissions for Device Software Functions introduces Basic and Enhanced documentation levels.

For Basic documentation, FDA recommends a summary of testing at unit, integration and system levels, alongside system-level test protocols and reports. Enhanced documentation additionally calls for detailed unit- and integration-level test protocols and reports in the submission.

What must be done during development is not necessarily identical to what must be submitted to FDA.

Basic documentation is not an exemption from appropriate software verification. Nor are FDA's documentation levels equivalent to IEC 62304 Software Safety Classes: they address different questions.

What should manufacturers actually do?

Rather than applying identical test requirements to every software unit, manufacturers should establish a verification strategy that considers:

• The software safety classification and applicable lifecycle requirements.
• The complexity and risk significance of the software unit.
• The effectiveness and limitations of available verification methods.
• The objective evidence needed to demonstrate that acceptance criteria have been satisfied.

Consider an assay calculation algorithm in an IVD analyser. Dynamic unit testing with reference datasets, boundary conditions and invalid inputs may provide particularly strong evidence. For a simpler, lower-risk component, structured review and static analysis may be suitable if the applicable unit verification criteria are addressed.

The objective is not to minimise testing. It is to choose verification methods that are technically justified and capable of demonstrating the required outcomes.

Better verification, not more paperwork

There is a temptation in regulated development to equate compliance with documentation volume. A hundred unit test protocols do not automatically provide better assurance than a carefully designed verification strategy. Equally, successful system testing does not automatically close gaps in required software unit verification.

Manufacturers need controlled, objective evidence showing what was verified, how it was verified and whether the applicable criteria were met. Version-controlled automated tests, code review records and reproducible analysis results can often provide that evidence without elaborate manual documents.

References

• IEC 62304:2006+A1:2015, Medical device software — Software life cycle processes, Clause 5.5.
• FDA, Content of Premarket Submissions for Device Software Functions (2023).
• ISO 14971:2019, Medical devices — Application of risk management to medical devices.