Software-Testing: Die Forderungen der IEC 62304 und FDA erfüllen

Das Software-Testing zählt neben den konstruktiven Maßnahmen (z.B. Arbeiten nach Software-Entwicklungsprozessen, Methoden und dem Einsatz von Werkzeugen) als wesentlicher Teil der Software-Qualitätssicherung. Meistens unterscheidet man — so auch die IEC 62304 — folgende Teststufen:

  • Unit-, Komponenten- oder Klassentests
  • Software-Integrationtests
  • Software-Systemtests
  • Software-Validierung (bei standalone Software)

Software-Tests

Es gibt noch weitere Maßnahmen der analytischen Qualitätssicherung von Software, die keine Software-Tests sind. Dazu zählt die Verifizierung des Quellcode von Software z.B. durch Code-Reviews oder durch Werkzeuge, die Code-Metriken, Bug-Patterns usw. bestimmen.

Weiterführende Informationen

Lesen Sie spezifischere Artikel zu den verschiedenen Software-Tests: Unit-Tests, Integrationstetsts, System-Tests und Usability-Tests.

Software-Testing und IEC 62304

Die IEC 62304:2006 fordert bei Software der Sicherheitsklasse A keine(!) Software-Tests. Bei Sicherheitsklassen B und C sind alle Teststufen verlangt. Seit dem Ammendment zur IEC 62304 aus dem Jahr 2015 sind Software-System-Tests immer verpflichtend. Dafür verzichtet die IEC 62304 ggf. bei Legacy-Software auf Tests.

Weitere Software-Tests

1. Beta-Tests

a) Was sind Beta-Tests?

Der Begriff Beta-Test stammt eigentlich aus dem Software-Umfeld, bei dem Software im „Beta-Stadium“ an einen begrenzten Kreis potenzieller Anwender verteilt, um Rückmeldungen zum Produkt zu bekommen. Bei diesen Rückmeldungen erhoffen sich die Software-Hersteller Informationen zur Gebrauchstauglichkeit und zu Fehlern (Bugs) in der Software.

Beta-Test

Auch große Firmen wie Google stellen regelmäßig „Beta“-Software zur Verfügung.

b) Beta-Tests unter regulatorischer Brille

Ein öffentlicher Beta-Test ist eine Inverkehrbringung. Eine Inverkehrbringung ist ohne CE-Zeichen verboten! Ein CE-Zeichen setzt wiederum ein erfolgreich durchlaufenes Konformitätsbewertungsverfahren voraus und dieses wiederum

  • eine klinische Bewertung,
  • eine Usability-Validierung und
  • Software-Systemtestst.

Alle diese sind aber keine Beta-Tests!

Unterscheiden Sie beides präzise und verteilen Sie nicht Ihr Produkt „einfach so“ an Ihre Kunden, auch nicht zum Beta-Testen. Das wäre eine Inverkehrbringung, denn die Frage, ob Sie das Produkt kostenlos abgegeben haben, ist irrelevant. Ein „öffentlicher“ Beta-Test setzt ein CE-Zeichen voraus!

c) Tipps zu Beta-Tests

Kennzeichnen Sie Produkte, die Sie für die klinische Prüfung benötigen, explizit. Lassen Sie die Ärzte wissen, dass das Produkt noch nicht „zugelassen“ ist. Holen Sie sich das Votum der Ethikkommission und des BfArMs ein.

Sie können und müssen nach der Inverkehrbringung Ihr Produkt im Markt weiter beobachten. Ob Sie dies dann Feldtests oder Beta-Tests nennen, bleibt Ihnen überlassen. Aber ein nicht CE-gekennzeichnetes Produkt hat bei einem Beta-Test nichts verloren!


Mittwoch 5. April 2017 von Prof. Dr. Christian Johner

Eine häufige Frage an uns: „Bieten Sie auch Computer System Validation“ (CSV) an?“ Einer der Gründe für das Interesse ist sicherlich: Behörden und benannte Stellen machen das Thema CSV immer öfter zum Gegenstand von Audits. Lesen Sie hier, welche Regularien es zur „Computer System Validation“ gibt und wie Sie deren Forderungen am elegantesten erfüllen.

Den ganzen Beitrag lesen »


Dienstag 4. April 2017 von Prof. Dr. Christian Johner

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.

Dieser Artikel fasst Ihnen das 111-seitige Dokument zusammen und stellt Ihnen das zentrale Prozessdiagramm als Download zur Verfügung.
Den ganzen Beitrag lesen »


Freitag 4. November 2016 von Prof. Dr. Christian Johner

Viele Hersteller medizinischer Software sind davon überzeugt, dass das Unit Testing der Bereich ihrer Entwicklung ist, bei dem sie die regulatorischen Forderungen (z.B. der IEC 62304) am besten erfüllen. Dies ist allerdings häufig nicht der Fall.

Den ganzen Beitrag lesen »


Donnerstag 22. September 2016 von Prof. Dr. Christian Johner

Code Coverage dient den meisten Software-Entwicklern als die wichtigste Metrik für die Vollständigkeit von Software-Tests. Die FDA stellt sogar explizite Anforderungen an die Code Coverage.

Übersicht

Den ganzen Beitrag lesen »


Donnerstag 5. Mai 2016 von Prof. Dr. Christian Johner

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.

Den ganzen Beitrag lesen »


Freitag 22. April 2016 von Prof. Dr. Christian Johner

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.

Den ganzen Beitrag lesen »


Freitag 4. März 2016 von Prof. Dr. Christian Johner

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.

Den ganzen Beitrag lesen »


Dienstag 29. September 2015 von Prof. Dr. Christian Johner

Sowohl die IEC 62304 als auch die FDA fordern Integrationsprüfungen typischerweise in Form von Integrationstests.

Update: Wie Sie die Forderung der IEC 62304 nach Evaluierung des Integrationsprüfverfahrens erfüllen können (mehr »).

Inhaltsübersicht
Integrationstests: Ziele »
Integrationstests: Aktivitäten »
IEC 62304: Was Sie prüfen sollten »
IEC 62304: Wie Sie prüfen sollten »

Den ganzen Beitrag lesen »


Dienstag 30. Juni 2015 von Prof. Dr. Christian Johner

on Blackbox-Testing spricht man, wenn man Testfälle alleine aus der Spezifikation des zu testenden Objekt (Produkt, Komponente) ableitet. Beim White-box-Testing leitet man die Testfälle hingegen aus der inneren Struktur des Objekts ab z.B. aus dessen Quellcode oder dessen Software-Architektur.

Blackbox testingLeider beobachte ich, dass viele Medizinproduktehersteller weder die Testfälle spezifizieren, noch diese systematisch mit einem Blackbox-Testverfahren herleiten. Vielmehr klickt sich ein Tester einfach durch die Anwendung. So etwas ist weder effektiv (Fehler werden nur mit einer unzureichend hohen Wahrscheinlichkeit gefunden) noch effizient. Das wird regelmäßig zum Problem im Audit.

Den ganzen Beitrag lesen »