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.

  1. Software-Testing: Die Grundlagen
  2. Regulatorische Anforderungen
  3. Sieben Praxistipps
  4. Unterstützung

1. Software-Testing: Die Grundlagen

a) Software-Testing als Teil der Software-Qualitätssicherung

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).

Das Software-Testing zählt zur Software-Qualitätssicherung

Abb. 1: Software-Tests sind ein Teil der analytischen Qualitätssicherung.

Vorsicht!

Es weder möglich noch erlaubt, die Software-Qualität nur mit Testen zu erreichen.

Zur konstruktiven Qualitätssicherung zählen

  1. Prozesse, z. B. Entwicklungsprozesse
  2. Methoden und Verfahren, z. B. das Requirements-Engineering, das Modellieren mit UML und das Ableiten von Testfällen mit Äquivalenzklassen
  3. Werkzeuge wie ALM-Werkzeuge, Entwicklungsumgebungen, Modellierungs- und Testwerkzeuge

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:

b) Taxonomie der Software-Testmethoden

Software-Tests lassen sich nach vielen Kriterien sortieren (s. Abb. 2).

Taxonomie der Methoden zum Software-Testing

Abb. 2: Taxonomie der Methoden beim Software-Testing

Die IEC 62304 unterteilt ihre Anforderungen nach den Lebenszyklus-Phasen (s. Abb. 3).

2. Regulatorische Anforderungen

a) Europa

MDR, IVDR

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).

IEC 62304

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.

V-Modell für Software, dem die Kapitel der IEC 62304 zugeordnet sind

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.

IEC 82304

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.

Vorsicht!

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.

b) FDA

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.

c) Sonstiges

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:

3. Sieben Tipps zum Software-Testing

Tipp 1: Bei Unit-Tests auch die Units testen

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.

Tipp 2: Die richtigen Methoden wählen

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.

Tipp 3: Die Testabdeckung quantifizieren

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.

Tipp 4: Alle Tests als Regressionstests nutzen

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.

Tipp 5: Nicht nur in der Entwicklung testen

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.

Tipp 6: Mit Beta-Tests vorsichtig sein

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.

Tipp 7: Kompetenz sicherstellen

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.

4. Unterstützung

Nutzen Sie die Unterstützung des Johner Instituts:

  • Haben Sie noch Fragen zur Software-Architektur oder zu den regulatorischen Anforderungen? Dann nutzen Sie das kostenfreie Micro-Consulting.
  • Im Kompaktseminar medizinische Software erwerben Sie die vorgeschriebenen Kompetenzen. Sie lernen die gesetzlichen Anforderungen an die Software-Entwicklung kennen und erfüllen.
  • Mit dem Auditgarant lernen Sie anhand von Videotrainings, wie Sie Schritt für Schritt eine schlanke und IEC 62304 konforme „Software-Akte“ selbst erstellen. Ein vollständiger Satz an Templates nimmt Ihnen dabei viel Arbeit ab.

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.


Code Coverage: Vollständigkeit von Software-Tests bestimmen

Code Coverage dient den meisten Software-Entwicklern als die wichtigste Metrik für die Vollständigkeit von Software-Tests. Dieser Artikel verschafft Ihnen einen Überblick über die Abdeckungsgrade und gibt Tipps zum deren Bestimmung.  Inhaltsübersicht 1. Varianten des Code Coverage » 2. Regulatorische Anforderungen » 3. Bewertung der Code Coverage » 4. Bestimmen der Code Coverage »  

Weiterlesen

Validierung von Machine Learning Libraries

Immer mehr Hersteller setzen Machine Learning Libraries wie scikit-learn, TensorFlow und Keras in ihren Produkten ein. Damit beschleunigen sie ihre Forschungs- und Entwicklungsvorhaben. Allerdings ist nicht allen Herstellern klar, welche regulatorischen Anforderungen sie bei Machine Learning Libraries nachweisen müssen und wie sie das am besten tun. Das führt dazu, dass sie unnötige Aufwände treiben oder…

Weiterlesen

Risk Based Approach – Risikobasierter Ansatz

Viele Behörden und Regularien sprechen von einem Risk Based Approach, auf deutsch risikobasierter Ansatz. Allerdings definieren sie diesen Begriff nicht und nennen auch keine Beispiele. Dieser Artikel verschafft Ihnen einen Überblick darüber, was ein „Risk Based Approach“ ist und gibt konkrete Hinweise dazu, wie Firmen diese regulatorischen Anforderungen erfüllen können.  Inhaltsübersicht Um was es geht…

Weiterlesen

Parametrisierung von Software

Die Parametrisierung von Software – man spricht in dem Kontext auch von Parametrierung, Customizing oder Konfiguration – führt regelmäßig zu Diskussionen z.B. über die Verantwortlichkeit und über die Abgrenzung zur Eigenherstellung. Dieser Artikel gibt Herstellern und deren Kunden wichtige Hinweise, auf was sie bei der Parametrisierung achten sollten und wie sie die üblichen Fallen vermeiden…

Weiterlesen

Regressionstest: Ihre Software-Versicherung

Unter einem Regressionstest verstehen Software-Tester meist die Wiederholung eines bestehenden Tests. Damit möchten sie prüfen, ob dieser Test nach einer Software-Änderung noch immer erfolgreich durchläuft. Lesen Sie in diesem Beitrag, was Sie bei einem Regressionstest bei medizinscher Software beachten sollten.  Inhaltsübersicht Ziele von Regressionstests » Regulatorische Anforderungen » Teile, die erneut zu testen sind »…

Weiterlesen

IVD Software-Hersteller aufgepasst

Dieser 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.

Weiterlesen