Unit, integration, and system tests — what is expected under IEC 62304?
IEC 62304 §5.5 (unit testing) · §5.6 (integration testing) · §5.7 (system testing)
The short answer
IEC 62304 requires verification at three levels: unit (Class B/C mandatory), integration (Class B/C mandatory), and system (all classes). The standard defines what must be verified, not how tests must be written or run. Automated test frameworks are explicitly compatible — what matters is that test records are captured, linked to requirements, and archived.
Testing levels by safety class
| Test level | Required for | What is verified | Basis |
|---|---|---|---|
| Unit testing | Class B and C mandatory | Each software unit meets its design specification | Software Design Specification (Class C); SRS functional decomposition (Class B) |
| Integration testing | Class B and C mandatory | Software items work correctly when integrated; interfaces behave as specified | Software Architecture Document; interface specifications |
| System testing | All classes (A, B, C) | Complete software system meets all SRS requirements | Software Requirements Specification |
What must be documented for each test level
- Test plan: What will be tested, how, under what conditions, pass/fail criteria
- Test cases: Specific inputs, expected outputs, pass/fail criteria — linked to requirements
- Test results: Actual outputs, pass/fail for each test case, tester identity, date, software version
- Link to requirements: Each test case must reference the requirement(s) it verifies
- Anomaly records: Failed tests must generate problem resolution records (§9)
Automated tests and CI/CD
Automated test frameworks (pytest, Jest, JUnit, NUnit, etc.) can produce test results that serve as IEC 62304 verification records, provided:
- Test case names or IDs can be linked to specific software requirements in the traceability matrix
- Test output (full results, not just a pass/fail badge) is captured and archived with the release baseline
- The test runner configuration and test code are under version control
- Failed tests are actioned through the problem resolution process — not silently re-run
Coverage expectations
IEC 62304 does not mandate specific code coverage percentages. What is required is a rationale for why the test set is sufficient to demonstrate that the software meets its requirements. In practice:
- A risk-based approach is expected — higher-risk software items warrant more thorough testing
- Every SRS requirement must have at least one test case (for Class B/C)
- Safety-critical paths (risk controls implemented in software) require explicit test coverage
- A coverage argument — explaining why the test set is sufficient — is more valuable than a coverage number
Regression testing after changes
Whenever software changes are made (bug fixes, enhancements, SOUP updates), regression testing is required to verify that unchanged parts of the software still function correctly. The extent of regression testing must be justified based on the impact of the change — a minor isolated fix may require only targeted regression; a change to a core shared module may require full regression. This impact analysis is documented as part of the change record.
Frequently asked questions
Is 100% code coverage required?
No. IEC 62304 does not require 100% code coverage. What is required is that every software requirement is verified by at least one test. Requirements-based coverage is the standard expectation, not line-by-line code coverage. For safety-critical items (Class C), higher coverage with rationale is expected — but no specific percentage is mandated.
Can automated CI tests replace manual tests?
Yes, for functional requirements where automated testing can reliably verify the requirement. Some test types may still require manual execution (e.g. usability testing, physical hardware interaction testing). The key requirement is that all test evidence is captured, linked to requirements, and archived — whether tests are manual or automated.
Is regression testing required after every change?
Yes, but the scope of regression testing is proportional to the scope and risk of the change. The change impact analysis (part of the change record) defines which test areas must be re-run. For critical changes to shared components, full regression testing of the affected scope is expected.
Is equivalence partitioning required?
IEC 62304 does not require specific test design techniques. Equivalence partitioning, boundary value analysis, decision table testing, and other techniques are useful but not mandated. What is required is that test cases are designed to verify requirements with defined pass/fail criteria — how you design those test cases is your choice.