Warum Testen im Medizinprodukt anders ist

Die ISO 13485 definiert die Anforderungen an das Qualitätsmanagementsystem und ist in der EU praktisch Voraussetzung für die Konformitätsbewertung nach MDR. Für die Software gilt die IEC 62304 mit drei Sicherheitsklassen: A (keine Verletzung möglich), B (nicht-schwere Verletzung) und C (schwere Verletzung oder Tod). Je höher die Klasse, desto strenger die Pflichten. Die Unit-Verifikation ist ab Klasse B gefordert, der detaillierte Softwareentwurf je Einheit nur für Klasse C. Die Klasse ergibt sich aus dem Risikomanagement nach ISO 14971, das damit den gesamten Verifizierungsaufwand bestimmt. Ergänzend wirken unter anderem IEC 62366-1 (Usability), IEC 81001-5-1 (Cybersecurity) und die AAMI TIR45, die beschreibt, wie sich agile Methoden mit der IEC 62304 vertragen. Die IEC 62304 wird derzeit überarbeitet, die zweite Edition ersetzt die Klassen durch Prozess-Rigor-Level.

Drei Grundsätze, bevor Sie ein Tool auswählen

Teststrategie vor Tool. Das Tool bildet Ihren Prozess ab, nicht umgekehrt. Vorher sollten klare Teststufen mit Verantwortlichkeiten, eine risikobasierte Testtiefe, Verifizierungskriterien je Anforderung und eine Re-Verifikationsstrategie feststehen.

Testmanagement ist nicht Testautomatisierung. Die Automatisierung führt Tests aus und erzeugt Ergebnisse. Das Tool orchestriert und belegt: was, gegen welche Anforderung, in welcher Umgebung, mit welchem Ergebnis und mit welcher Freigabe. Ziel ist ein Nachweis-Layer über einer weitgehend automatisierten Testwelt.

Angemessenheit statt Bürokratie. Die Normen verlangen Angemessenheit, nicht Maximaldokumentation. Zu viel Dokumentation ist genauso ein Anti-Pattern wie zu wenig.

Neun Kriterien für ein geeignetes Test-Management-Tool

1. Durchgängige Traceability.
Anforderung, Risikomaßnahme, Testfall, Ergebnis und Anomalie sind in beide Richtungen verknüpft und auswertbar. So sehen Sie sofort, welche Anforderungen ungetestet und welche Risiken unverifiziert sind. Insellösungen neben dem Requirements-Management bedeuten manuelle Pflege und Auditrisiko.


2. Revisionssicherheit und Baselines.
Jeder Testfall hat einen unveränderlichen Audit Trail, jeder Teststand ist eindeutig einer Softwareversion zugeordnet. Auch Jahre nach dem Release muss rekonstruierbar sein, was in welcher Version mit welchem Ergebnis lief. Abgeschlossene Ergebnisse bleiben unveränderbar, Korrekturen entstehen nur als neuer, begründeter Eintrag.


3. Teststufen und risikobasierte Testtiefe.
Unit-, Integrations- und Systemtests sind getrennt berichtbar, passend zu den Verifizierungsstufen der IEC 62304. Wie tief getestet wird, richtet sich nach dem Risiko.


4. Anomalie- und Änderungsmanagement.
Ein fehlgeschlagener Test führt direkt in den Problem-Resolution-Prozess, inklusive Sicherheitsbewertung und Re-Test-Tracking. Ändert sich eine freigegebene Anforderung, macht das Tool betroffene Testfälle und Traceability-Ketten sichtbar, als Basis für die Impact-Analyse.


5. Freigaben, Rollen und Rechte.
Reviews und Zweitprüfer-Sign-offs sind dokumentiert. Verlangt Ihr QMS ein Vier-Augen-Prinzip, setzt das Tool es technisch durch. Sonst entsteht die Lücke zwischen beschriebenem und gelebtem Prozess, ein Standardbefund bei Audits. Bei FDA-Relevanz kommen elektronische Signaturen nach 21 CFR Part 11 hinzu.


6. Ergebnisimport und Testumgebung als Metadatum.
Ergebnisse kommen automatisch aus der CI-Pipeline, nicht per Hand. Zu jedem Lauf werden DUT-Version, HIL-Konfiguration, Compiler und Testbench-Setup festgehalten. Das ist entscheidend für die Reproduzierbarkeit auf Hardware. Varianten bei Hardware-Derivaten sollten abbildbar sein.


7. Scrum-Tauglichkeit.
Testfälle lassen sich direkt aus Stories im Issue-System anlegen und im Sprint bedienen, der Re-Test-Workflow ist schlank. Je mehr manuelle Pflege ein Tool verlangt, desto eher weicht das Team aus, und die Traceability stimmt nicht mehr.


8. Langzeitverfügbarkeit.
Die MDR verlangt, die technische Dokumentation mindestens zehn Jahre aufzubewahren, bei implantierbaren Produkten fünfzehn. Das Tool braucht exportierbare, stabile Formate. Vendor-Lock-in ist ein reales Risiko.


9. Validiertes Tool. Auch das Tool selbst muss für seinen Zweck validiert sein (ISO 13485, 4.1.6; IEC/TR 80002-2), inklusive risikobasierter Revalidierung bei Upgrades. Anbieter mit Validierungsunterlagen sparen hier erheblichen Aufwand.

Scrum und Embedded: Wo es auf die Details ankommt

Scrum und IEC 62304 sind vereinbar, erfordern aber bewusste Verzahnung. Bewährt hat sich das Release-Zug-Modell: Mehrere Sprints laufen auf einen Release zu, formelle Aktivitäten wie Design-Reviews, Verifikationsabschluss und Dokumentations-Freeze liegen an den Release-Grenzen. Die Definition of Done wird um regulierte Aktivitäten erweitert, etwa Code-Review, bestandene Unit-Tests, fehlerfreie statische Analyse, aktualisierte Traceability und im Sprint gepflegte Dokumentation. Typische Stolpersteine sind aufgeschobene Dokumentation, Änderungen verifizierter Anforderungen ohne Impact-Analyse und ein vergessener Wartungsprozess.

Bei Embedded-Software kommen Besonderheiten hinzu: Die Testpyramide reicht von Host-Unit-Tests mit Mocks über HIL-Integrationstests bis zu Systemtests auf dem echten Gerät. Die Hardware-Software-Integration muss in der Verifikationsstrategie ausdrücklich adressiert werden. Compiler, statische Analyse und Testframeworks müssen selbst qualifiziert werden, und die Toolchain wird versioniert, damit Builds reproduzierbar bleiben.

Wo KI das Testmanagement schon heute unterstützt

Am meisten Nutzen bringt KI derzeit bei der Qualitätsanalyse von Requirements: Sie erkennt Mehrdeutigkeiten, fehlende Verifizierungskriterien und Testbarkeitsprobleme, also Fehler, die vor dem Test auffallen. Hilfreich sind außerdem Testfall-Entwürfe aus Anforderungen, die das Team prüft und übernimmt, die Erkennung von Duplikaten sowie Zusammenfassungen von Testergebnissen für Release-Readiness-Berichte. Die Verantwortung für den Nachweis bleibt beim Menschen.

Fazit

Ein gutes Test-Management-Tool belegt, was gegen welche Anforderung, in welcher Umgebung und mit welchem Ergebnis getestet wurde und wer es freigegeben hat. Es steht auf einem klaren Prozess: Teststrategie zuerst, Traceability als Rückgrat, Nachweise so viel wie risikogerecht nötig und so schlank wie möglich. Automatisieren statt dokumentieren.

NewTec unterstützt Hersteller dabei, Teststrategie, Prozess und Tool-Landschaft für Medizinprodukt-Software aufeinander abzustimmen, von der Einordnung der Normanforderungen bis zum auditfähigen Nachweis im Scrum-Alltag.