A software test strategy for an MDR device is a single document that explains which test activities you run, why those activities are sufficient for your software safety class under EN 62304:2006+A1:2015, and how test results trace back to requirements and risk controls. Clauses 5.5 (unit verification), 5.6 (integration), and 5.7 (system testing) give you the structure. Safety class A, B, or C tells you how deep to go.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN 62304 clauses 5.5, 5.6, and 5.7 define three verification layers: unit implementation and verification, integration and integration testing, and system testing.
  • The depth of each layer is scaled by software safety class. Class A has minimum obligations, Class C the deepest.
  • A software test strategy is not a test plan — it is the document that explains which tests exist, why that set is sufficient, and how results feed the release decision.
  • The test pyramid (many unit tests, fewer integration tests, fewest system tests) maps cleanly onto the 62304 clauses without contortion.
  • Traceability from requirement to risk control to test case is what turns a test strategy from documentation into evidence.
  • Every test activity must produce a record. No record, no verification — that is the rule notified bodies audit against.

Why a test strategy document exists at all

Small MedTech teams often have excellent tests and terrible test documentation. The engineers wrote unit tests from day one, hooked integration tests into CI, and even set up a nightly end-to-end run. Then the notified body audit arrives and the reviewer asks a simple question: "Show me your software test strategy." The team has no document by that name. The tests exist, but the argument for why this particular combination of tests is sufficient for a Class B SaMD has never been written down.

That gap is what the test strategy document closes. It is not bureaucratic theatre. It is the artefact that lets a reviewer, a new engineer, or a future auditor understand the reasoning behind your test setup without reverse-engineering the CI pipeline.

The MDR route to this document runs through Annex I §17.2, which requires software to be developed "in accordance with the state of the art taking into account the principles of development life cycle [...] verification and validation". The harmonised standard for that is EN 62304:2006+A1:2015, and clauses 5.5 through 5.7 are where verification lives.

What EN 62304 actually says about testing

EN 62304 does not say "write a test strategy document". It says something more useful: it defines three layers of verification and scales them by safety class.

Clause 5.5 — Software unit implementation and verification. For Class A, you implement units. For Class B and C, you must also establish unit verification procedures and verify each software unit against its requirements. Clause 5.5.3 lists acceptance criteria categories that your procedures must cover, including proper event sequence, data and control flow, error handling, and boundary conditions.

Clause 5.6 — Software integration and integration testing. Applicable to Class B and C. Integration testing must be planned (5.6.1), conducted according to the plan (5.6.2), and must evaluate software behaviour at integration points, especially functional and performance requirements. Clause 5.6.6 requires you to conduct regression testing when integrating changes.

Clause 5.7 — Software system testing. Applicable to Class B and C. System testing verifies that the integrated software meets the software requirements. Clause 5.7.3 requires you to retest after changes. Clause 5.7.4 requires that software system testing be shown to verify software requirements.

For Class A, 62304 is deliberately light. You still have to implement, but formal unit verification, integration testing, and system testing obligations at the same depth do not apply. This is not a loophole — it reflects that Class A software cannot contribute to a hazardous situation. If you are Class A and you are still running a full pyramid, that is good engineering, but you document only what the standard requires.

For Class C, the bar is highest. Every requirement must be verified, every unit must be verified against its acceptance criteria, and integration and system testing must be comprehensive. The evidence burden matches the safety stakes.

Mapping the test pyramid onto 62304

The test pyramid that modern software teams already use — many unit tests, fewer integration tests, fewest system tests — maps onto 62304 with no translation gymnastics. The challenge is not renaming your tests. It is proving that the pyramid you already have is sufficient for your safety class and that the results are captured as records.

Unit tests → clause 5.5. Your existing pytest, jest, or JUnit suites already satisfy the "verification of software units" activity. What 62304 adds is the expectation that you documented, somewhere, what acceptance criteria you used and that those criteria covered the categories in 5.5.3. A one-page "unit verification procedure" that says "we write unit tests covering the clause 5.5.3 categories as applicable to each unit, using pytest, with results captured in CI logs archived for five years" is often enough.

Integration tests → clause 5.6. These verify that modules work together. In a modern SaMD, this usually means contract tests between services, API tests against a running backend, or component tests with mocked dependencies. The 62304 requirement is that they are planned (document the plan), conducted to the plan, and regression-tested on change (CI already does this).

System tests → clause 5.7. End-to-end tests against a deployed version of the system, verifying software requirements. For a web-based SaMD, this is usually Playwright or Cypress tests hitting a staging environment, or manual test scripts for parts that cannot reasonably be automated.

The key insight: 62304 does not demand a specific tool, framework, or test count. It demands that the tests you run are sufficient for your requirements and safety class, and that the results are captured as records. If your strategy document explains the mapping, you are compliant.

A worked example

A Class B SaMD team maintains an image analysis tool used by clinicians to flag suspicious findings. Their current test setup:

  • 1,200 unit tests in pytest, running on every commit, full coverage reports archived.
  • 85 integration tests using testcontainers to spin up the database and external services, running on merge to main.
  • 40 automated end-to-end tests in Playwright against a nightly staging deployment.
  • 12 manual test scripts for workflows that require clinician-like interaction patterns, run before each release.

Their test strategy document is nine pages long. It contains:

  1. Scope and safety class. States the device is Class B under EN 62304 and therefore clauses 5.5, 5.6, and 5.7 apply in full.
  2. Verification layers. Maps the test pyramid onto 62304 clauses with a table showing which clause each layer satisfies.
  3. Acceptance criteria categories. Lists the 5.5.3 categories and shows how the team's test writing guide ensures each is considered per unit.
  4. Integration strategy. Documents how services are integrated, which integration points are tested, and how regression testing is triggered under 5.6.6.
  5. System testing strategy. Lists the software requirements (by ID) and maps them to specific system test cases. Requirements without an automated test are explicitly assigned to manual scripts.
  6. Tools and environment. Names the tools (pytest, testcontainers, Playwright), the test environment, and how tool outputs are archived.
  7. Records. Specifies that CI build records, test reports, and manual test execution records are retained for the device lifetime plus five years.
  8. Release gating. Defines that no release proceeds unless all tests at the three layers have passed and the results are linked to the release record in the DHF.

That document, plus the traceability matrix linking requirements to risk controls to test cases, is what the notified body reviewer opens. It took the team one week to write, once their tests already existed.

The Subtract to Ship playbook

You do not need six different documents. You need one test strategy, one traceability matrix, and real test records. Everything else is overhead.

1. Classify first. Write down your software safety class under clause 4.3. Until you know whether you are A, B, or C, you cannot scope test effort correctly. Class matters more than any other decision in this workflow.

2. Write the strategy before you scale the tests. A two-page draft beats a perfect 40-page document written after the fact. The draft forces you to decide what you are going to test and why. You can refine it as the product evolves.

3. Reuse your CI as the record system. Test records do not need to live in a separate system. A retained CI build log, immutable and linked to a release tag, is a valid record under EN 62304 and EN ISO 13485:2016+A11:2021. The requirement is retention and retrievability, not fancy dashboards.

4. Traceability is the deliverable that unlocks everything. Requirements → risk controls → test cases → test results. If that chain holds in a spreadsheet, a Jira query, or a markdown table, your reviewer can follow it. If it does not hold, nothing else in the test strategy saves you.

5. Scale with class, not with fear. Class A teams do not need integration test plans. Class C teams cannot skip them. Many startups over-test on Class A work and under-document on Class B work. Match the effort to the class.

6. Update the strategy when the test setup changes. If you adopt a new tool or change the environment, the strategy document must reflect reality. A strategy that describes a setup you abandoned two releases ago is worse than no document at all.

Reality Check

  1. Do you have a written software test strategy document, or only the tests themselves?
  2. Does the document explicitly name your software safety class under EN 62304 clause 4.3?
  3. Can you trace every software requirement to at least one test case and every test case to a recorded result?
  4. Are the acceptance criteria categories in clause 5.5.3 reflected in how your team writes unit tests?
  5. For Class B or C devices, is integration testing planned (5.6.1) and does the plan exist as a document?
  6. Does regression testing run automatically on every change, and is that wired into your release gate?
  7. Are test records retained in a way that survives a CI migration — meaning outside the CI system itself if needed?
  8. If a notified body reviewer asked for the system test evidence for a release from a year ago, could you produce it in under thirty minutes?

Frequently Asked Questions

Is a test strategy the same as a test plan? No. The strategy explains the overall approach — which layers exist, why, and how they map to 62304. A test plan describes specific test activities for a specific release or component. Large projects have one strategy and several plans. Small projects can fold plan content into the strategy document.

Do Class A SaMD projects need a test strategy document? Formally, many of the testing clauses do not apply at Class A. Practically, writing a short test strategy is still valuable because it forces clarity about what you test and why. A one-page document is enough.

Can we use BDD or exploratory testing under EN 62304? Yes. The standard does not mandate a methodology. BDD scenarios and structured exploratory sessions are acceptable if they produce records and are traceable to requirements. The strategy document must explain how.

How much unit test coverage does EN 62304 require? The standard does not specify a coverage percentage. It requires that your acceptance criteria address the categories in clause 5.5.3 and that unit verification is conducted. Coverage numbers are a useful internal metric but are not a compliance threshold in themselves.

What about static analysis and code review — do they count as verification? Yes. Clause 5.5.5 explicitly allows verification activities other than dynamic testing. Static analysis and reviews can satisfy unit verification obligations if the strategy documents them and the results are recorded.

Do we need a separate test strategy for each release? No. The strategy is a living document that applies to the software as a whole. Release-specific testing activities are captured in test records, not in new strategies.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes. Clauses 4.3, 5.5, 5.6, 5.7.
  3. EN ISO 13485:2016+A11:2021 — Quality management systems for medical devices. Clauses 4.2.4, 4.2.5 (records).