Software-Systemtest, was ist das?
Ein Software-Systemtest ist eine Prüfung des gesamten Software-Systems, ob die daran gestellten Software-Anforderungen erfüllt sind. Diese Prüfung findet i.d.R. dadurch statt, dass die Blackbox „Software-System“ über deren Schnittstellen (Benutzer-System-Schnittstellen und System-System-Schnittstellen) getestet wird, entweder manuell oder automatisiert.
Die Hersteller müssen festlegen, was das Software-System ist: Ein Medizinprodukt kann über ein oder mehrere Software-Systeme verfügen. Das Software-System im Sinne der Regularien geht aber nicht über das Medizinprodukt hinaus.
Welche regulatorische Anforderungen muss ein Software-Systemtest erfüllen?
Die kurze Antwort auf die Frage, ob ein Software-Systemtest überhaupt vorgeschrieben ist, lautet: (Fast) immer. Lesen Sie weshalb:
Forderungen der IEC 62304 an den Software-Systemtest
Wann Sie Ihr Software-System prüfen müssen
Die IEC 62304:2006 fordert in Kapitel die „Prüfung des Software-Systems“ für Software der Klasse B und C. Diese Anforderung weitet das Ammendment I (IEC 62304:2006 A1:2016) auf alle Software, d.h. Software der Klassen A, B und C aus.
Das Ammendment fordert Aufzeichnungen aus dem Software-Systemtest sogar für Legacy Software.
Fazit: Ihr Auditor kann mit Bezugnahme zum Stand der Technik einen Software-Systemtest für alle Software-Systeme verlangen.
Wie Sie Ihr Software-System prüfen müssen
Die Norm stellt folgende Anforderungen an die Software-Systemtests:
- Vollständigkeit
Sie müssen die Erfüllung aller Anforderungen an das System prüfen, typischerweise durch Tests, und durch ein „Tracing“ nachweisen, dass Ihnen das gelungen ist. - Pass-Fail-Kriterien
Sie müssen Kriterien festlegen, wann eine Prüfung als erfolgreich einzustufen ist. - Dokumentation und Reproduzierbarkeit
Die Tests (Spezifikation, Kriterien, Ergebnisse) müssen Sie so dokumentieren, dass es möglich ist, sie einschließlich der Ergebnisse zu reproduzieren. Das schließt eine Dokumentation und Konfigurationskontrolle der Prüfumgebung mit ein. - Problemlösungsprozess
Wenn Sie beim Test Fehler finden, müssen Sie den Problemlösungsprozess starten. Zu dieser Forderung finden Sie gleich mehr. - Wiederholung bei Änderungen
Falls Sie an der Software Änderungen durchführen, müssen Sie die Tests in angemessener Weise wiederholen. Es steht nicht geschrieben, dass das alle Tests sein müssen. - Geeignete Teststrategie
Der Hersteller muss seine Testmethodik/Teststrategie auf Eignung prüfen. Wer beispielsweise das bei Anwendungen, die zeitkritisch sind oder bei denen „Race-Conditions“ auftreten können, das Laufzeitverhalten nicht testet, würde dieser Forderungen nicht gerecht.
Anforderungen der FDA
Um es kurz zu machen: Die FDA fügt dem keine Anforderungen hinzu. Der FDA Software-Validation ist auch nicht so präzise formuliert wie die IEC 62304.
Tipps zum Spezifizieren und Durchführen von Software-Systemtests
#1: Automatisierung
Bei einer Software, die über längere Zeit und mehrere Releases weiterentwickelt wird, sollten Sie Ihre Tester von repetitiver Arbeit verschonen. Automatisieren Sie die Systemtests so weit wie irgend möglich.
#2: Tester und Testmethoden
Die Herausforderung beim Testen besteht darin, dass Sie durch Testen niemals die Korrektheit des Software-Systems nachweisen können. Das liegt daran, dass ein vollständiges Testen ob der kombinatorischen Vielfalt ausgeschlossen ist.
Daher müssen Sie durch die Wahl geeigneter Testfälle eine möglichst hohe Wahrscheinlichkeit schaffen, Fehler zu finden. Für dieses Ableiten von Testfällen sollten Sie Blackbox-Testverfahren nutzen. Arbeiten Sie mit dezidierten Testern, die über diese Methodenkompetenz verfügen.
#3: ISO 25010
Die ISO 25010 ist eine Taxonomie von Software-Qualitätseigenschaften. Da die IEC 62304 diese Taxonomie nutzt, um Software-Anforderungen zu spezifizieren, und weil die Norm das vollständige Testen der Anforderungen verlangt, empfiehlt sich die ISO 25010 auch als Checkliste, mit der Sie die Vollständigkeit Ihrer Software-Systemtests prüfen können.
#4: Problemlösungsprozess: Nicht verzweifeln
Die IEC 62304 fordert von Ihnen, dass Sie Fehler, auf die Sie im Software-Systemtest stoßen, in den Problemlösungsprozess einspeisen. Manche Firmen legen sich damit förmlich still. Daher ein paar Gedanken:
- Fehler vermeiden oder vor dem Systemtest finden
Wenn Sie in Ihren Software-Systemtests auf sehr viele Fehler stoßen, heißt das, dass die vorangegangenen Quality Gates (z.B. Review der Anforderungen, Code Review, Unit-Tests) nicht ausreichend wirksam waren. Hier sollten Sie unbedingt ansetzen, denn die Fehler, die Sie in den Systemtests finden, sind immer nur die Spitze des Eisbergs. Sie haben dann ein wirkliches Qualitätsproblem. - Unterschiedliche Sprints?
Nirgends steht geschrieben, dass Sie jeden Software-Systemtest betrachten müssen. Beispielsweise könnten Sie „inoffizielle“ Systemtests bei Sprints durchführen und vor dem Release einen offiziellen Software-Systemtest durchführen. Nur für den letzteren würden Sie Probleme über den entsprechenden Prozess abwickeln. Empfehlen tue ich dieses Vorgehen aber nicht. Letztlich arbeiten Sie damit am Prozess vorbei. - Schlanker Problemlösungsprozess
Entscheidend ist, dass Sie einen schlanken Problemlösungsprozess definieren. Es darf niemand wegen des damit verbundenen Overheads in Versuchung gebracht werden, den Problemlösungsprozess zu umgehen. Zu einem schlanken Prozess zählt, dass- die Problemberichte schnell und einfach ausgefüllt werden können,
- keine unnötigen Freigaben und Unterschriften verlangt werden,
- der Prozess keine unnötigen Arbeitsschritte verlangt wie beispielsweise die Prüfung, ob etwas ans BfArM gemeldet werden muss, wenn die Software noch überhaupt nicht auf dem Markt ist,
- nur die Daten erfasst werden, die regulatorisch verlangt sind oder später wirklich ausgewertet werden.
Fazit
Leider stoßen auch wir immer wieder auf Firmen, die ernsthaft die Notwendigkeit von Software-Systemtests in Frage stellen. Dafür haben wir nur bedingtes Verständnis: Jeder professionelle Software-Entwickler, wird seine Software testen, wie das ein Studierender bereits im vierten Semester lernt. Abhängig davon, ob es sich um ein erstes Release oder ein Update handelt, gilt es die Software in Gänze oder im Rahmen von Regressionstests so weit wie sinnvoll zu testen.
Wer auch das nicht tun kann oder möchte, sollte eine andere Domäne als die Medizinprodukte wählen. Oder wollten Sie von einem Chirurg operiert werden, der mit Ihnen diskutiert, ob das Desinfizieren der Hände vor der OP nun wirklich notwendig sei?
Ein Problem der Systemtests ist die starke Überschneidung mit der IEC60601-1 Kapitel 14.
Dort wird nun auch für Klasse A eine Software Systemverifizierung für das PESS (bzw. PEMS wenn es kein weiteres PESS gibt) gefordert.
Bei einem Blackbox test wird man aber in den allermeisten Fällen das PESS brauchen um die Systemsoftware als System zu verifizieren. Wir haben schon bisher die Software intensive über das PESS getestet.
Nun fordert man von einen weiteren Level Software Systemtest, der aber bei „kleinen“ Systemen mit nur einem Prozessor eigentlich immer das PEMS darstellt.
Bei Klasse A sollte es möglich sein, das die Software Systemtests und die Verifizierung des PEMS (PESS) in einem durchgeführt werden.
Es muß Software und Systemanforderungen geben und beide müssen zu 100% getestet werden, aber das sollte in einem Durchlauf möglich sein.
Sehr geehrter Herr Mark,
danke für Ihre wertvollen Hinweise.
Man hat bei der IEC 62304 bewusst die Software-Systemtests bewusst auch für Klasse-A-Softwaresysteme verlangt.
Weil man eine „isolierte Software“ genauer prüfen kann, als eine in einem Gerät verbaute Software, möchte man die Software-Systemtests nicht (nur) im Rahmen der PEMS-Systemtests durchgeführt wissen. Beispielsweise muss eine Software bestimmte Fehlverhalten der Hardware überprüfen und darauf reagieren können. Im Rahmen von PEMS-Tests lässt sich das meist nicht prüfen.
Nochmals besten Dank!
Viele Grüße, Christian Johner
Hallo Herr Johner,
Ich gebe ihnen Recht das es Punkt gibt die sich bei einer isolierten Software besser prüfen lassen.
Diese werden aber auch bisher schon als Whitebox Test oder Code Review beim PEMS Test durchgeführt, weil anders überhaupt nicht testbar.
Da wir wie gesagt in der PEMS Spezifikation schon jede Menge „Software Requirements haben“.
Nehmen wir die ca. 60% der Software die sich mit der Anzeige und User Interaktion befassen, die da Sie Klasse A sind nicht kritisch sind.
Wenn wir alles das einmal im Software System und dann noch mal im PEMS prüfen, ist das ein sehr großer Aufwand mit vergleichsweise wenig zusätzlichem nutzen.
Wenn man mit der Erweiterung nur festlegen will das man ich hierüber Gedanken machen muß und auch solche Punkte testen muß gebe ich ihnen Recht.
Aber mit dem „Gießkannenprinzip“ zu sagen es muss nun für alle Requirements ein Software ein Softwaresystemtes zusätzlich her ist doch etwas sehr hoch gegriffen für Klasse A Software.
Oder muß man die Anforderungen hier nur neu Aufteilen in System und Software und dann eben auf der entsprechenden Ebene Testen.
Danke für Ihr Nachhaken, Herr Mark!
Meine Aussage war nicht, dass Sie die Anforderungen an das Software-System ausschließlich über Software-Systemtests prüfen müssen. Wenn Sie dort auf PEMS-Tests verweisen, wie beispielsweise bei der UI, dann ist das konform (Einschränkungen s.u.).
Umgekehrt ist es möglich, im Software-Systemtest auf Testergebnisse aus vorausgegangenen Testphasen zu verweisen. Beispielsweise ließe sich die korrekte Implementierung einer UI (statische Aspekte) bereits bei der Prüfung der UI-Komponente prüfen. Deren korrekte Anbindung an das Backend wäre wiederum ein Aspekt von SW-Integrations- oder SW-Systemtests.
Die Anforderungen, dass alle Software-Anforderungen überprüft wurden — gleich im Rahmen welcher Aktivität — bleibt aber unbenommen. Ob das bei Klasse A immer sinnvoll ist, lässt sich diskutieren.
Meine Empfehlung wäre, die Anforderungen immer möglichst früh zu prüfen. Andernfalls wäre es beispielsweise nicht möglich, die Software-Freigabe zu erteilen, bevor die Systemtests abgeschlossen sind. Das würden den ganzen Entwicklungsprozess konterkarieren.
Beste Grüße, Christian Johner