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.
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.
Software as a Medical Device leicht gemacht
Entdecken Sie jetzt, wie Sie Ihre Software als Medizinprodukt in Verkehr bringen können. Erfahren Sie alles über die IEC 62304 Norm und lernen Sie, wie Sie die Anforderungen einfach und praxisorientiert umsetzen können. Mit über 25 Videos und einem kompletten Set einer IEC 62304-konformen Software-Akte unterstützen wir Sie dabei, Ihre Software erfolgreich und schnell zu vermarkten
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.
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?
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.
Sie weisen darauf hin, dass es aus aus normativer Sicht nicht ausreichend ist nur Unit-Tests (aus Entwickler-Sicht, weisse Kästchen) durchzuführen, sondern dass die Software-Einheiten (Units im normativen Sinne, rote Kästchen) explizit getestet werden müssen.
Im folgenden Artikel gehen Sie jedoch nicht weiter darauf ein, wie mit den „Entwickler-Tests“ zu verfahren ist. Ich stelle mir daher folgende Frage:
Einige Entwickler-Tests entstehen klar Bottom-Up, ergeben sich also aus der Art und Weise wie eine Funktionalität umgesetzt wurde, also aus dem Aufbau der weissen Kästchen. Is es ausreichend, wenn die „Anforderungen“ an diese Tests nur implizit innerhalb der (automatisierten) Tests beschrieben sind? D.h., dass hierzu keine getraceten Requirements vorhanden sind? So lassen sich wirkliche Requirements an die Software, also solche bis auf Ebene der normativen Units, von „Erwartungshaltungen“ der Entwickler trennen.
Lassen sich solche „Entwickler-Tests“ für die Code-Coverage heranziehen?
Sehr geehrter Herr Klöckner,
danke für die wichtige Frage!
Ich würde Sie sehr ermutigen, die „Entwicklertests“ weiter durchzuführen. Die Anforderungen, die Sie damit abtesten sind im Testcode enthalten. D.h. Sie müssen keine Requirements für jedes weiße Kästchen formulieren.
Meine Aussage war vielmehr, dass Sie auch und aus regulatorischer Sicht v.a. die roten Kästchen testen.
Sie dürfen durchaus den Code-Coverage der Entwickler-Tests heranziehen. Das würde ich auch empfehlen, weil dieser Coverage-Grad i.d.R. auch viel höher und aussagekräftiger ist.
Viele Grüße, Christian Johner
Vielen Dank für die sehr hilfreichen Informationen. In unserem SW Entwicklungsprozess verwenden wir die Software Requirement Specification für die Anfordeurngen an das SW System. Die Software Design Specification bildet das Design und das detaillierte Design wieder. Im Augenblick brechen wir die Anforderungen auf SRS Ebene (Ebene 0 – SW System-Ebene) auf Ebene 1 (Software Design Ebene – Wir nennen die Items auf dieser Ebene Komponenten) runter, und die Anforderungen brechen wir weiter runter auf Ebene 2 (Software detailled design – Hier sind unsere 62304 UNITs).
Auf diese Weise bekommen wir auch die Akzeptanzkriterien für unsere UNITs. Das heißt, wir definieren auf jeder Ebene unsere Software Architektur formale Anforderungen die auch formal geprüft werden, samt Test-Spezifikation, Testprotokoll und Traceability-Matrix.
Inzwischen bin ich aber der Meinung, dass die 62304 dieses runterbrechen von Anforderungen gar nicht verlangt, sondern lediglich das Runterbrechen (Dekomposition ) der Architektur und eine Architektur-Traceability.
Jetzt möchte ich gerne die Anfroderungen aus unserem SDS komplett entfernen, so dass es endlich ein reines Design-Output Dokument wird und nicht selbst wieder neue Anforderungen definiert und die Akzeptanzkriterien auf andere Art und Weise definieren (Generell: Code-Reviews, static code analysis, Entwickler-Unit-Tests + Funktional: Prüfen der Anwendbarkeit der Anforderungen die in der 62304 5.5.4 angegeben sind).
Jetzt bin ich aber ins Zweifeln gekommen, ob das richtig ist was ich vor habe, weil ich in diesem Artikel gelesen habe: „Generell sollten die Akzeptanzkritieren von Unit-Tests die in der Software-Architektur spezifizierten Anforderungen sein“
Jetzt war ich eigentlich sicher, dass in die Software Architektur keine Anforderungen rein gehören, damit es ein klares Design-Output Dokument ist. Könnten sie zu dem Punkt ein paar Worte sagen: Software Architektur – Anforderungen ja oder nein?
Danke im voraus,
Beste Grüße,
Ty-4
Sehr geehrter Herr Ty-4,
danke für Ihre ausführliche Schilderung!
Eine Software-Architektur ist (u.a.) die Zerlegung eines Software-Systems in Komponenten und eine Spezifikation der Schnittstellen dazwischen.
Jede Spezifikation einer Schnittstelle (einer Komponente) ist eine Beschreibung, wie sich die Software-Komponente über diese Schnittstelle verhalten soll. Und diese Beschreibung entspricht Anforderungen — allerdings an eine Komponente und nicht mehr an das Software-System insgesamt.
Bei den Komponententests (z.B. Unit-Tests) prüfen Sie, ob sich die Software gemäß dieser Spezifikationen verhält. D.h. Sie testen ob die Komponente die Komponentenanforderungen erfüllt.
Damit setzt eine Software-Architektur die Software-Anforderungen d.h. die Anforderungen an ein Software-System in eine Aufteilung des Systems in Komponenten und in eine Anforderungen an diese Komponenten um.
Hilft das ein wenig? Falls nicht, haken Sie gerne nach.
Viele Grüße, Christian Johner
Vielen Dank für die schnelle Antwort!
Ja, sie hilft auf jeden Fall schon mal weiter. Demnach ist die Antwort auf die Frage: Ja, in der SW Architektur werden Anforderungen definiert, die von den Software System Anforderungen abgeleitet werden.
Allerdings widerspricht das der Trennung zwischen Design Input und Design Output. Wenn mich heute jemand fragt was unser SDS eigentlich in dem Sinne ist, muss ich antworten: „Beides, es ist der Design-Output für das Software System (SRS) und der Design-Input für unser Source-Code. Würden sie das auch so interpretieren?
Wenn ich im Web z.B. nach Templates für die 62304 suche, ist es immer so, dass im SRS-Template Beispiele für Anforderungen drin stehen. Im zugehörigen SDS allerdings werden an der Stelle wo Komponenten oder UNITS definiert werden nur die Anforderungen aus dem SRS erwähnt, die von der Komponente oder UNIT erfüllt werden. Es tauchen keine neuen Anforderungen auf. Gerne kann ich ihnen per E-Mail mal solche Templates schicken, und die Stellen die meine markieren?
Sehr geehrter Herr Ty-4,
sowohl die SW-Architektur als auch die darin identifizierten Anforderungen an die Komponenten sind Design-Output. Damit gibt es keinen Widerspruch.
Die Trennung von Design-Input und Design-Output bezüglich der Anforderungen bestenfalls auf Ebene des Produkts, aber nicht auf Ebene der Komponenten.
Wenn es keine Komponenten-Anforderungen gäbe, könnten Sie keine Unit-Tests entwickeln. Denn diese müssen genau diese Anforderungen abprüfen.
Diese Ableitung von Produkt-Anforderungen aus Stakeholder-Anforderungen, von Komponenten- (z.B. PESS) Anforderungen aus Produkt-(z.B. PEMS) Anforderungen, von Software-Anforderungen aus PESS-Anforderungen, von Unit-Anforderungen aus Software-Anforderungen muss im „vertikalen Tracing“ erkennbar sein. Beispielsweise die IEC 60601-1 beschreibt das sogar explizit z.B. in Bild H2.
Beste Grüße, Christian Johner
Alles klar. Dann werde ich meine Bemühungen an der Stelle die Anforderungen aus dem SDS zu nehmen und einen anderen Weg für die Akzeptanzkriterien zu finden erst mal einstellen. Vielen Dank wie immer für die schnellen Rückmeldungen.
Hallo Herr Johner,
ich habe gerade mit sehr großem Interesse diesen spannenden Dialog gelesen, da ich an einer verwandten Fragestellung feststecke und etwas den Verdacht habe, dass ich ein paar Aspekte bisher falsch interpretiert haben könnte:
1. Auch ich war bisher der Annahme, dass es sich bei den Anforderungen (unabhängig, ob sie gegen das (SW) System auf oberstem Level oder – auf tieferem Level – gegen eine SW Unit formuliert sind, um Design Input im Sinne der FDA handelt. Das würde aus meiner Sicht zu einer Art rekursivem Zick-Zack-Pattern führen, bei dem z.B. „System Design“ als Design Output auf dem System Level zu Design Input für die Sub-Systeme auf der nächst tieferen Systemhierarchieebene (z.B. für SW Items oder Units) wird. Auf der unteren Hierarchieebene würde dann wiederum Design Output „als Antwort“ auf diesen Design Input entstehen.
2. Da die FDA grundsätzlich eine formale Traceability von Design Input zu Design Output und zur Verifikation fordert, bin ich davon ausgegangen, das sich auch diese Forderung auch „entlang der (SW-)Systemdekomposition“ bis auf die kleinste Zerlegungsebene fortsetzt. Was bedeuten würde, dass alle Dokumentationselemente von Design Input über Design Output bis zu deren Verifikation eindeutig auf allen Zerlegungsebenen identifizier- und zuordenbar sein müssten.
Wenn ich mir Ihre Erklärungen in diesem Thread und allgemein zur 62304 und der Verifikation von SW Items/Units anschaue, dann gewinne ich den Eindruck, dass meine Interpretation etwas über das Ziel hinausschießt, was vermutlich auf Missverständnissen meinerseits beruht. Meine Frage an der Stelle:
Wenn es auf Komponenten-Level (z.B. für SW Units) eigentlich nur noch Design Ouput und keine Design Input gibt, muss ich jedes Design Output Element auf SW Unit Level eindeutig identifizierbar machen und zu jedem solchen Element (direkte) formale Traceability zu einem Test Case auf SW Unit Level herstellen, der diese Design Entscheidung verifiziert? Das wirkt etwas merkwürdig, weil man ja eigentlich gegen Design Input verifiziert und nicht gegen Design Output?
Oder wäre der richtige Ansatz, dass man nur per Design Review verifiziert, dass die dokumentierten Design Entscheidungen (also der Design Output) den Anforderungen auf der Design Input Seite folgen?
Die Durchführung von SW Unit Test würde man dann nur als „allgemeines“ Akzeptanzkriterium definieren (z.B. mit einer Anforderung an die erwartete Code Coverage und einem formalen Review, dass die Tests das Gesamtdesign auch abdecken), ohne dass man hier für jeden Unit Test explizite und granulare Traceability herstellt.