Das Software-Testing zählt neben den Code-Reviews zur Software-Verifizierung. Gesetze und Normen stellen Anforderungen an die Art und den Umfang des Software-Testings.
Inhalt
Diese Seite verschafft Ihnen einen schnellen Überblick über das Software-Testing und verlinkt für weitergehende Informationen auf Fachartikel.
Das Ziel des Testens von Software besteht darin, Fehler in der Software zu finden. Damit ist das Software-Testing ein Teil der analytischen Qualitätssicherung (s. Abb. 1).
Abb. 1: Software-Tests sind ein Teil der analytischen Qualitätssicherung.
Es weder möglich noch erlaubt, die Software-Qualität nur mit Testen zu erreichen.
Zur konstruktiven Qualitätssicherung zählen
Auf der Meta-Ebene gibt es Gesetze und Normen sowie Schulungs- und Weiterbildungsmaßnahmen, die sich u. a. auf die drei oben genannten Aspekte beziehen.
Die analytische Qualitätssicherung versucht, mithilfe von verschiedenen Prozessen, Methoden und Werkzeugen Fehler in verschiedenen Testobjekten zu finden. Man unterscheidet:
Software-Tests lassen sich nach vielen Kriterien sortieren (s. Abb. 2).
Abb. 2: Taxonomie der Methoden beim Software-Testing
Die IEC 62304 unterteilt ihre Anforderungen nach den Lebenszyklus-Phasen (s. Abb. 3).
Die MDR und IVDR verlangen Software-Lebenszyklus-Prozesse nach Stand der Technik (s. MDR, Anhang I, Abschnitt 17.2) und die Dokumentation der „Verifizierung und Validierung der Software“ (s. Anhang II, Abschnitt 6.1.b).
Die für diese EU-Verordnungen harmonisierte Norm IEC 62304 fordert das Software-Testing in folgenden Kapiteln:
Bei der Software-Freigabe (Kapitel 5.8) müssen die Hersteller überprüfen, ob die Software-Tests so durchgeführt wurden, wie im Softwareentwicklungsplan beschrieben.
Abb. 3: Die IEC 62304 fordert in den Kapitel 5.5 bis 5.7 die Verifizierung der Software durch u. a. Software-Tests.
Bei Legacy-Software erlaubt die Norm Ausnahmen.
Die Software-Validierung fällt nicht in den Anwendungsbereich der IEC 62304, sondern den der IEC 82304-1. Allerdings sind deren Anforderungen sehr unspezifisch.
Wichtige Methoden zur Validierung von Software sind die klinische Bewertung und die Usability-Validierung, typischerweise in Form einer summativen Evaluation bzw. eines Usability-Tests.
Der Begriff Software-Validierung wird in verschiedenen Kontexten unterschiedlich verstanden. Beispielsweise umfasst Computerized Systems Validation nicht nur eine Validierung am Ende der Entwicklung, wie in Abb. 3 zu sehen.
Das Video auf der Seite zur Validierung hilft, Missverständnisse zu vermeiden.
Die FDA erkennt die IEC 62304 als „recognized standard“ an. Aber die relevantesten Vorgaben an die Software-Architektur formuliert die Behörde in ihrer Leitlinie General Prinicples of Software Validation.
Die Leitlinie Content of the premarket submission gibt vor, welche Unterlagen Hersteller einreichen müssen. Darin macht die FDA auch Vorgaben für das Software-Testing.
Hersteller, die die Anforderungen der FDA und der EU an das Software-Testing erfüllen, dürften weitgehend auch konform mit Anforderungen anderer Märkte sein.
Manchmal hilft es, weitere Normen zu beachten. Dazu zählen:
Entwickler verstehen unter dem Unit-Testing etwas anderes als Auditoren: Für die Ersteren sind Unit-Tests die Tests der granularen Einheiten, also z. B. der Methoden und Klassen. Hingegen müssen aus regulatorischer Sicht die Unit-Tests die Software-Einheiten testen, die größere Komponenten darstellen können.
Lesen Sie mehr dazu in diesem Artikel.
Je nach Testziel sollten die Hersteller die passenden Methoden wählen. Ein Fuzz-Test hat eine andere Zielsetzung als ein Penetration-Test.
Nutzen Sie Blackbox-Testverfahren. Damit kann man nicht nur bei Software-Systemtests systematisch diejenigen Testfälle ermitteln, die die höchste Wahrscheinlichkeit haben, Fehler zu finden.
Tests können nur dann Fehler finden, wenn der Testcode die zu testende Software tatsächlich durchläuft. Mit Werkzeugen lässt sich der Code-Coverage automatisiert bestimmen. Diese Metrik sollten Hersteller für sich festlegen.
Jeder zusätzliche Test erhöht die Wahrscheinlichkeit, dass Fehler rechtzeitig gefunden und beseitigt werden. Deshalb hat es sich bewährt, nach Änderungen alle Tests als Regressionstests zu wiederholen. Nicht nur während der Entwicklung, sondern auch während der Software-Wartung.
Wenn Hersteller es den Anwendern erlauben, die Software anzupassen (etwa durch die Parametrierung der Software oder gar eigene Scripts), dann sollten diese Anpassungen ebenfalls durch Software-Tests überprüft werden.
Beta-Tests haben das Ziel, ein Produkt (hier eine Software) vor dem offiziellen Release einem ausgewählten Anwenderkreis zur Verfügung zu stellen, um Feedback zum Produkt zu erhalten.
Medizinproduktehersteller müssen sich bewusst sein, dass solch ein Beta-Test bereits eine gesetzeswidrige Inverkehrbringung des Produkts darstellen kann.
Software-Testing ist eine Kompetenz, die Hersteller festlegen und gewährleisten müssen. Dazu verpflichtet sie u. a. die ISO 13485; und zwar spezifisch für jedes Entwicklungsprojekt.
Nutzen Sie die Unterstützung des Johner Instituts:
Melden Sie sich gleich, damit wir die nächsten Schritte besprechen können. So stellen Sie sicher, dass die „Zulassung“ sicher gelingt und Ihre Software bzw. Ihr Produkt schnell in den Markt kommt.
Fuzz-Testing ist eine Methode zur Identifizierung bisher nicht-erkannter Schwachstellen und Sicherheitslücken in Software (stand-alone oder embedded), die die Schnittstellen der Systeme automatisiert mit korrekten oder falschen Werten testet.
Der UL 2900-2-1 nennt sich „Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems“. Er zählt zur UL-2900-Familie, der Normenfamilie zur IT-Security. Lesen Sie in diesem Artikel, welche Schwächen der Standard hat und unter welchen Umständen er Ihnen dennoch nützlich sein kann.
WeiterlesenDieser Artikel beschreibt die Anforderungen der In-vitro Diagnostic Regulation IVDR an die Entwicklung und Dokumentation der Software. Die Anforderungen betreffen sowohl Software, die Teil eines IVDs ist (embedded Software), als auch Software, die selbst ein IVD darstellt (standalone Software). Ebenso finden Sie in diesem Beitrag einen Vergleich der Anforderungen der MDR und der IVDR an die Software.
WeiterlesenLegacy Software definiert die IEC 62304 in deren neuen Ammendment I als Software (Teil eines Medizinprodukts oder eigenständige Software), die zum damaligen Zeitpunkt legal in Verkehr gebracht wurde, aber heutigen Anforderungen (insbesondere der IEC 62304) nicht mehr genügt. Update: Abgrenzung von Legacy Software, SOUP und OTS
WeiterlesenDie IEC 62304 fordert in Kapitel 5.8 eine Software-Freigabe, auf Englisch „Software Release“. Besonders bei Herstellern von Standalone-Software beobachte ich häufig ein Missverständnis des Begriffs Software-Freigabe. Das kann regulatorisch zum Problem werden.
Der AAMI TIR 36 ist ein Best Pratice Guide, der den Titel “Validation of software for regulated processes“ trägt. Die AAMI möchte mit diesem „Technical Information Report“ Medizinprodukteherstellern Hilfestellung dabei geben, computerisierte Systeme zu validieren. Inhaltsübersicht Wer den TIR 36 lesen sollte » Übersicht über die Anforderungen » Verbindlichkeit, Ziel, Bezugsquelle » Stärken und Schwächen…
WeiterlesenDie Baumusterprüfung zählt zu den Konformitätsbewertungsverfahren, die die Medizinprodukterichtlinie MDD (93/42/EWG) kennt. Auch die MDR hält an der Baumusterprüfung als einem der Konformitätsbewertungsverfahren fest. Doch ist die Baumusterprüfung auch für Software geeignet?
Ein Mock-Objekt hilft beim Integrationstest, Teile eines Software-Systems zu ersetzen bzw. zu simulieren, solange bis diese Teile schrittweise dem System hinzugefügt werden. Lesen Sie in diesem Artikel, wie sich Mocks von Dummies und Stubs unterscheiden und ob Sie ein Mock-Objekt auch verifizieren müssen.
WeiterlesenUnter Code-Reviews versteht man das Prüfen des nicht kompilierten Quell-Codes durch weitere Personen beispielsweise im Rahmen von Inspektionen oder Walk-Throughs. Regulatorische Anforderungen an Code-Reviews Die IEC 62304 fordert keine expliziten Code-Reviews. Sie sieht aber Code-Reviews als eine Möglichkeit, um Software-Einheiten zu prüfen. Dabei müssen allerdings schriftliche Prüfkriterien für die Code-Reviews vorliegen, ebenso ist das Code-Review schriftlich…
Weiterlesen
„Findet ein Software-Audit statt?“ lautet eine Frage, die mich über unser Micro-Consulting erreicht. „Und kann ich durch eine geeignete Wahl der Software-Sicherheitsklasse so ein Software-Audit vermeiden?“ Erst ist mir weder klar, was genau mit „Software-Audit“ gemeint, noch was die genaue Befürchtung ist. Doch dann verstehe ich und finde die Frage sehr bedeutsam für alle Medizinprodukte-Hersteller.
Weiterlesen