Integration testing as a standard SDLC phase — verifying combined behavior before system testing has been standard practice.
Class B applicability added by A1:2015. Normative tie to the integration plan (5.1.5) — integration testing must follow a planned test set, not be exploratory. [Class B, C]
Test-case-level result records (not just summary pass/fail), anomaly documentation in the problem resolution process, and test plan coverage of abnormal conditions.
Maps to
IEC 62304: §5.6.3 Software integration testing
ISO 13485: §7.3.6 Design and development verification
Pre-QMSR Part 820 (legacy QSR): §820.30(f) Design verification.
Requirement text
The manufacturer shall test the integrated software items in accordance with the integration plan and document the results. Applies to Class B and Class C software.
Why this clause exists
Integration testing sits at the architectural boundary between unit-level verification and system-level testing: it verifies that software units behave correctly in combination, not just individually. Clause 5.6.3 requires that this testing follow the integration plan (rather than ad hoc exploration) because safety-relevant integration behaviors — particularly risk controls that depend on multiple units cooperating — must be verified by planned tests with defined expected results, not by informal observation. The documentation requirement ensures that integration test results constitute evidence, not just activity.
What changed
Clause 5.6.3 was present in IEC 62304:2006. Amendment 1 (2015) added Class B applicability and refined the clause title from 'Test integrated software' to 'Software integration testing' to align with the overall structural revision. The cross-reference to the integration plan (5.1.5) is unchanged.
Common gaps (what we see in audits)
- Integration testing results not documented at test-case level — Integration testing is performed and a summary result (pass/fail) is recorded, but individual test case results are not documented. Clause 5.6.7 requires pass/fail per test case and a list of anomalies — a summary report does not provide the test-case-level evidence required for auditability.
- Integration testing limited to happy-path scenarios — Integration test cases cover only nominal behavior without testing abnormal conditions, interface error handling, or boundary conditions. Clause 5.6.4 requires that integration testing address whether the integrated software item performs as intended across scenarios including testing under abnormal conditions and foreseeable misuse.