Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Unit Testing und IEC 62304

Freitag 4. November 2016

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.

Regulatorische Anforderungen an das Unit Testing

Forderungen der IEC 62304

Die IEC 62304 kennt zuerst kein „Unit Testing“. Vielmehr kennt sie Software-Einheiten (auf Englisch Software Units), die daraufhin zu prüfen sind, ob vorher genannte Akzeptanzkriterien erfüllt sind.

Abhängig von der Sicherheitsklasse (hier mehr dazu)

  • können Sie sogar auf diese Verifizierung verzichten (Klasse A) oder
  • Sie können die Akzeptanzkriterien so bestimmen, dass sich diese nur mit einer Analyse des Quellcodes (z.B. Code Review, statische Code-Analyse) überprüfen lassen (Klasse B) oder
  • Sie müssen tatsächlich die Software-Einheit testen.

Allerdings entspricht die Granularität der Software-Einheiten häufig nicht dem, was die Hersteller unter Unit-Tests verstehen.

Unit Testing: Was sind die Units?

Abb. 1: Im Sinne der IEC 62304 entsprechen die rot markierten Komponenten den „Units“ (Software-Einheiten). Hingegen verstehen Entwickler unter Units (beim Unit Testing) die Komponenten auf unterster Ebene (in weiß dargestellt).

Die Hersteller verstehen unter dem Unit-Testing das Testen von Methoden oder Funktionen und gehen (bei OO-Entwicklungen) runter bis auf die einzelnen Klassen. Im Architekturdokument sind als kleinste Komponenten aber nur viel grob-granularere Teile der Software erkennbar — und genau das sind die Software-Einheiten.

Mit anderen Worten: Die Software-Entwickler testen sehr feingranular (und nennen das Unit Testing), testen aber nicht die in der Software-Architektur spezifizierten Software-Einheiten. Und das ist ein Verstoß gegen die IEC 62304.

Forderungen der FDA an Unit Tests

Die FDA formuliert ihre Vorstellungen vom Unit Testing in den Guidance Dokumenten z.B. im „Software Validation Guidance„. Sie nennt diese Tests „Tests for Modules and Functions“, die sich auf der einen Seite in den Source Code und auf der anderen zurück zur Architektur verfolgen lassen müssen.

Ähnlich wage formuliert sie die Anforderungen an die „Verification and Validation“ im Guidance Document „Content of the Premarket Submissions for Software contained in Medical Devices„.

Umso überraschender ist angesichts solch unpräziser Vorgaben, dass 100% Zweigabdeckung „is considered to be a minimum level of coverage for most software products, but decision coverage alone is insufficient for high-integrity applications“. Diese Forderung haben wir noch bei keiner Firma als erfüllt vorgefunden.

Unit Testing praktisch und gesetzeskonform umsetzen

1. Wahl der Granularität: Unit Testing versus Komponenten-Testing

Vermeiden Sie die oben erwähnte typische Falle, dass Sie zahllose Unit-Tests durchführen, aber die Software-Einheiten nicht explizit testen. Das bedingt aber, dass Sie überhaupt isoliert testbare Software-Einheiten haben. Und dies wiederum ist eine Frage der Güte Ihrer Architektur.

Ergänzen Sie also ggf. Ihre Unit-Tests (in Ihrer Definition) durch die Tests der wahrscheinlich grobgranulareren Software-Einheiten. Automatisieren Sie auch diese Tests, um sie als Regressionstests (idealerweise täglich) wiederholen zu können.

2. Prüfen der Akzeptanzkriterien statt Unit Testing?

Wenn Sie aus Zeitgründen oder wegen einer verkorksten Software-Architektur Ihre Software-Einheiten nicht (automatisiert) testen können, dann legen Sie bei Software-Einheiten der Klasse A und B zumindest formale Akzeptanzkriterien fest, wie Kodierrichtlinien, Metriken oder Namenkonventionen. Das hat zwar wenig mit professionellem Software-Engineering zu tun, erfüllt aber wenigstens die wenigen Anforderungen der IEC 62304. Bei Software der Klasse C bleibt Ihnen dieser Kunstgriff verwehrt.

Bei Klasse C müssen Sie als Teil der Akzeptanzkritierien (soweit anwendbar) auch Performanz-Aspekte, Fehlerbehandlung, Speicherauslastung usw. prüfen. Generell sollten die Akzeptanzkritieren von Unit-Tests die in der Software-Architektur spezifizierten Anforderungen sein.

3. Werkzeuge fürs Unit-Testing

Unit-Tests sollten automatisiert als Regressionstests (täglich) ausgeführt werden. Das bedingt, dass Sie Unit-Testwerkzeuge wie JUnit, NUnit oder CppUnit ebenso im Einsatz haben, wie Werkzeuge für die kontinuierliche Integration wie sie Kombinationen von ANT, make, Maven, Grunt im Zusammenspiel mit beispielsweise Jenkins erlauben. Für die statische Code-Analyse gibt es ebenfalls zahlreiche Werkzeuge.

Die ISO 13485 fordert allerdings die Validierung vieler Werkzeuge! Lesen Sie hier mehr zur Validierung von Werkzeugen.

4. Dokumentation

„Reicht es, die Unit-Tests als PDF zu speichern?“, werde ich in meiner kostenlosen Auditsprechstunde gefragt.

Ich sehe nicht einmal die Notwendigkeit, die Unit-Tests in PDF zu konvertieren. Allerdings würde ich die Ergebnisse – das sind ja oft HTML-Dateien – unter Versionskontrolle stellen, um sie einer eindeutigen Software-Version zuordnen zu können.

Eine Bewertung und Freigabe der (Unit-)Testergebnisse sollten Sie auch haben. Das lässt sich oft bequem im Rahmen des Software-Release formell erreichen. Falls Sie – was ich nicht unbedingt empfehlen würde – „manuell“, d.h. nicht automatisierte Unit-Tests fahren, wird man wahrscheinlich eher auf Papier dokumentieren. Hier können Sie unterschreiben und sollten neben den Ergebnissen auch die Bewertung dieser Ergebnisse nicht vergessen.

Vor vielen Jahren hatte ich mir selbst eine „Minor Non-Conformity“ „eingefangen“, weil ich zwar die Ergebnisse meiner Unit-Tests dokumentierte aber vergessen hatte, explizit zu bewerten, ob die Akzeptanzkriterien erfüllt waren.

Nochmals zur Automatisierung: Ich empfehle diese auch, um der Forderung nach Regressionsprüfung zu erfüllen.

Weitere Tipps

Die Videotrainings des Auditgarant zeigen Ihnen Schritt für Schritt, wie Sie

  • eine Software-Architektur entwerfen, die nicht nur normenkonform ist, sondern auch ein „Unit Testing“ erlaubt,
  • Unit Tests spezifizieren, ausführen und dokumentieren und
  • auch die Integrations- und Systemtests gemäß IEC 62304 durchführen.

Lesen Sie hier mehr über den Auditgarant.


Kategorien: Software & IEC 62304
Tags:

2 Kommentare über “Unit Testing und IEC 62304”

  1. Adrian Wyssmann schrieb:

    Die FDA fordert ja die Möglichkeit einer unabhängigen Bestätigung des Resultats “ factual records documenting the result of an examination, which support the pass/fail conclusion in an unambiguous and understandable manner, and which allow for independent confirmation of the result“

    Heisst das nicht auch, dass man in der Lage sein muss, zu zeigen was der Test gemacht hat. Bei manuellen Tests ist das ja einfach, indem man die Test Schritte und Resultate auf Papier bringt (PDF). Wie kann man dasselbe für Automatisierte tests erreichen?

    Für mich ist die Dokumentation eines automatisierten Tests der Test Code selbst, entsprechend würde ich den Source Code archivieren so dass ich jederzeit darauf zugreifen und zeigen kann was der Test gemacht hat.

    Wie sehen Sie dass?

  2. Christian Johner schrieb:

    Absolut, das sollte man zeigen können. Bei automatisierten Tests sind die Schritte einschließlich der pass/fail-Krititerien im Source-Code. Das sehe ich genau wie Sie. Daher sollte der Test-Code unbedingt der gleichen Dokumentenlenkung unterworfen sein wie der Programm-Code und die Testergebnisse.

Kommentar schreiben