Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Software-Systemtest: Diese 6 Anforderungen müssen Sie erfüllen

Freitag 4. März 2016

Software-Systemtest: Was versteht man genau darunter? Wann sind sie vorgeschrieben? Was sollten Software-Systemtests testen? Auf welche Fallen sollten Sie achten? Antworten gibt Ihnen dieser Beitrag.

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.

Software-Systemtest: Testen des Software-Systems über Schnittstellen

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:

  1. 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.
  2. Pass-Fail-Kriterien
    Sie müssen Kriterien festlegen, wann eine Prüfung als erfolgreich einzustufen ist.
  3. 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.
  4. Problemlösungsprozess
    Wenn Sie beim Test Fehler finden, müssen Sie den Problemlösungsprozess starten. Zu dieser Forderung finden Sie gleich mehr.
  5. 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.
  6. 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:

  1. 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.
  2. 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.
  3. 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

    1. die Problemberichte schnell und einfach ausgefüllt werden können,
    2. keine unnötigen Freigaben und Unterschriften verlangt werden,
    3. 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,
    4. 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?


Kategorien: Software & IEC 62304
Tags: , ,

Kommentar schreiben