What you will learn
- Explain the relationship between software unit verification and dynamic unit testing.
- Identify the Class B and Class C activities in IEC 62304 clause 5.5.
- Select methods that address requirements, interfaces, abnormal conditions and risk controls.
- Define acceptance criteria and assemble reproducible verification records.
- Separate FDA submission documentation from the evidence retained during development.
Prerequisite: MTL-312 — IEC 62304 Software Lifecycle. This module uses IEC 62304:2006 with Amendment 1:2015. The worked practices below are engineering recommendations; they are not additional normative clauses.
Three perspectives on unit verification
This module connects lifecycle verification with US submission evidence. The labels below distinguish requirements of the cited standard, FDA guidance recommendations and suggested engineering practice.
IEC 62304 requirements
Section 2 summarises clause 5.5 and its software safety class applicability. Use your controlled copy for the complete requirements. See MTL-312 — IEC 62304 Software Lifecycle for the wider lifecycle.
FDA recommendations
Section 8 explains the unit-testing documentation recommended for Basic and Enhanced submissions. These documentation levels are separate from IEC 62304 safety classes. See MTL-318 — FDA Device Software Functions — Premarket Submissions for the complete submission overview.
Practical good practice
The methods, worked example, evidence checklist and exercise show how to build useful verification evidence. These are illustrative engineering recommendations, not additional normative clauses or a universal test checklist.
Unit-verification evidence contributes to a premarket submission; this module does not cover the full FDA software documentation package.
Practical good practice
01Verification is broader than testing
Verification asks whether the implemented unit satisfies its specified requirements and design. Dynamic testing answers part of that question by executing software with controlled inputs and comparing observed behaviour with expected outcomes. Reviews and static analysis can provide complementary evidence without executing the unit.
Static verification
Inspect interface assumptions, calculation logic, coding-rule compliance, data handling and potentially unsafe constructs. Record findings and their disposition.
Dynamic unit testing
Execute the unit through a controlled harness. Exercise normal inputs, boundaries, invalid data, state transitions and injected faults.
A passing test suite does not establish that its cases are adequate. A clean static-analysis report does not establish that behaviour is correct. Select a combination that addresses the failure mechanisms of the particular unit.
IEC 62304 requirements · Clause 5.5
02What changes with software safety class?
Under IEC 62304:2006+A1:2015, the following clause applicability is central. Consult the controlled standard for the complete requirements and class assignment rules.
| Clause | Activity, paraphrased | Class A | Class B | Class C |
|---|---|---|---|---|
| 5.5.1 | Implement the units | Yes | Yes | Yes |
| 5.5.2 | Define unit-verification methods; evaluate test-procedure adequacy when testing is used | — | Yes | Yes |
| 5.5.3 | Establish unit acceptance criteria before integration and ensure they are met | — | Yes | Yes |
| 5.5.4 | Address additional acceptance criteria where relevant to the design | — | — | Yes |
| 5.5.5 | Perform unit verification and record its results | — | Yes | Yes |
For Class C, additional criteria address sequencing, flows, resources, fault handling, initialisation, diagnostics, memory and boundaries as applicable. A dash means that particular clause is not assigned to that class; it does not exempt the product from adequate verification under other applicable requirements.
Do not treat Class C as the point at which documented unit verification begins. Choose and justify suitable techniques for the allocated software safety class and actual risks.
Practical good practice
03Define a unit that can be verified
A useful unit boundary has a clear responsibility, observable outputs and controlled dependencies. A unit may be a function, class or small component; a source file is not automatically the right boundary.
- Identify the unit, source location and version.
- State its purpose and links to requirements and design.
- Describe input types, ranges, units, output meanings and error responses.
- Identify persistent state, shared data, timing assumptions and external services.
- Define which dependencies will be real and which will be replaced by stubs or mocks.
A host-based test can isolate calculation logic effectively. It cannot, by itself, demonstrate target-specific interrupt timing, processor arithmetic behaviour or peripheral interaction. Allocate those checks to suitable target or integration tests and retain the connection.
Practical good practice
04Choose methods around credible failures
Calculation or conversion
Use independently calculated expected values, equivalence partitions, rounding boundaries and overflow checks. Do not generate expected values using the same algorithm as the implementation.
Stateful control
Exercise permitted and forbidden transitions, repeated events, missing events, recovery and reset. Check outputs and persistent state after each step.
Parser or interface
Try truncated, oversized, malformed, stale and inconsistent messages. Verify rejection, error reporting and absence of unintended state changes.
Resource or fault management
Inject allocation failures, timeouts and dependency errors. Check bounded execution, cleanup and safe error propagation.
Use structural coverage to reveal code that the tests have not exercised, then investigate why. Define the appropriate metric and target in the verification plan. IEC 62304 does not prescribe one universal coverage percentage or require MC/DC for every Class C unit. High coverage is not evidence that every requirement or hazardous behaviour has been addressed.
Practical application of acceptance criteria
05Make acceptance criteria objective
Replace “works correctly” with observable outcomes. For example: a valid request produces the specified value within an agreed tolerance; an invalid request returns the designated error and leaves the last valid state unchanged; a timeout releases resources within the specified interval.
Define expected results before execution. Specify tolerances, timing limits, side effects, diagnostic outputs and prohibited behaviour. Review the test procedure itself: can it detect the defect of concern, are its expected values independent, and do the mocks reproduce the dependency behaviour that matters?
For automated tests, readable controlled scripts can serve as procedures. Preserve the expected results, execution evidence and review trail; a separate manually copied document is not inherently stronger evidence.
Practical good practice · Worked example
06Worked example: validating an infusion-rate request
Consider an illustrative rate-validation unit. Its approved requirement permits integer values from 1 to 1,000 mL/h inclusive. It accepts only an integer input, rejects all other values and preserves the last accepted rate on rejection. These are fictional teaching limits, not clinical recommendations.
| Test input or condition | Expected outcome | Purpose |
|---|---|---|
| 1, 500 and 1,000 | Accept; return and store the requested rate | Limits and representative valid input |
| 0 and 1,001 | Reject; preserve previous rate | Immediately outside each boundary |
| −1, 1.5, null, text and a very large integer | Reject without conversion, overflow or state change | Invalid type, precision and range |
| Accept 500, reject 1,001, then accept 1 | Stored values are 500, 500, then 1 | State preservation and recovery |
Review the implementation for conversion before validation, signed/unsigned comparisons and unintended writes on error paths. If the production interface supplies a fixed-width integer, test malformed transport data at the parser boundary and retain that allocation. Do not claim tests against impossible function inputs as evidence of interface robustness.
This unit evidence does not prove that the pump delivers the requested flow. Integration and system verification must demonstrate the path from validated request through motor control, feedback and alarms.
Practical good practice · Evidence checklist
07Retain a reproducible evidence chain
- Plan: unit scope, safety class, methods, responsibilities and criteria.
- Identify: requirement and design references, source commit, test version, compiler, settings and environment.
- Execute: retain inputs, expected outcomes, observed outcomes and pass/fail decisions, plus review and analysis findings.
- Resolve: connect failures to problem reports, fixes, impact analysis and repeat verification.
- Conclude: record coverage limitations, residual anomalies and the authorised acceptance decision.
Keep traceability bidirectional: a requirement should lead to its evidence, and evidence should have a clear purpose. Distinguish an excluded check from a passed check. Protect CI records from routine expiry and associate the evidence with the configuration actually considered for release.
After a change, assess which units, interfaces, risk controls and tests may be affected. Regression selection should follow that impact assessment. Retesting only the changed lines can miss interactions and altered assumptions.
FDA recommendations · Submission documentation
08FDA Basic and Enhanced are separate decisions
FDA documentation level concerns what is recommended in the submission; it is not an IEC 62304 software safety class. The June 2023 guidance, section VI.H, recommends:
- Basic: summaries of unit, integration and system testing, plus system test protocols and reports with expected and observed results and pass/fail conclusions.
- Enhanced: the Basic information plus unit and integration test protocols and reports.
Basic does not mean that unit evidence can be omitted from development records. Nor does targeting the US automatically make every software item Class C. Determine both classifications independently, plan adequate verification and retain the underlying evidence. FDA may request further information.
Read MTL-318 — Device Software Functions: Premarket Submissions for the broader submission context. FDA guidance expresses recommendations; applicable legal requirements and the manufacturer’s QMS remain relevant.
Practical good practice · Exercise
09Practical exercise: review an inadequate test set
A Class B unit validates an integer temperature limit from 2 to 8 °C inclusive. The team has tested only 5 °C. Its report says “passed”, identifies no source version and argues that FDA Basic means no further unit records are needed.
- Identify at least four gaps.
- Propose boundary and invalid-input tests with expected outcomes.
- Choose a complementary static-verification activity.
- List the evidence needed before accepting the unit.
Worked answer and discussion
The test set misses both valid limits, out-of-range values, input-type rules and any specified state or error behaviour. The requirement also needs a defined rejection response. There is no controlled baseline, reproducible execution record or adequacy assessment. Class B and FDA Basic do not remove unit-verification evidence.
Test 2, 5 and 8 as accepted values; 1 and 9 as rejected values; and non-integer, absent or malformed inputs at the appropriate interface. Define the required error and state response first. Review comparison operators, type conversion and error paths. Retain requirement links, criteria, procedures, configuration, actual results, findings, fixes and the acceptance decision. Where relevant, add target and integration checks.
Key takeaways
- Unit testing is one verification technique; the evidence must collectively support the unit’s acceptance.
- Classes B and C require defined unit verification and recorded results. Class C adds criteria.
- Make boundaries, abnormal conditions, state and risk controls visible in the verification strategy.
- Evaluate test adequacy, not just execution success or coverage percentages.
- Retain controlled evidence even when the submission needs only a summary.
References and further reading
- IEC 62304:2006 + Amendment 1:2015, especially clauses 5.5, 5.6, 5.7, 8 and 9. Use your controlled licensed copy. ISO catalogue — IEC 62304 Amendment 1.
- FDA — Content of Premarket Submissions for Device Software Functions, June 2023, particularly section VI.H.
- MTL-116 — Verification and Validation.