Behaviour Driven Development beim Testen von Medizinprodukten
22. Juli 2021Tests bei der Entwicklung von Medizinprodukten
Das Durchführen von Tests zur Sicherstellung der Erfüllung von Anforderungen ist unerlässlich bei der Entwicklung von Medizinprodukten. Gleichzeitig aber ist das Testen eine zeit- und kostenintensive Aufgabe, die nicht selten durch den oft kurz bevorstehenden Marktzugang zusätzlich unter Druck erfolgen muss. Doch ganz gleich, wie hoch die Kosten für das Testen auch sein mögen, die Kosten für nachträglich erkannte Fehler sind weitaus höher. Effizienz bei der Entwicklung und beim Testen spielt zwar eine große Rolle, an erster Stelle steht aber, in der Entwicklung möglichst alle Fehler zu vermeiden und spätestens in der Testphase alle Fehler zu finden. Dabei ist unter anderem entscheidend, ob die Requirements durch die Entwickler und die Tester richtig verstanden und umgesetzt werden. Dann können später kostspielige und langwierige Veränderungen vermieden werden.
Schließe die Lücke zwischen Anforderungen und Tests!
Bei der Entwicklung von Medizinprodukten sind Tests in verschiedensten Bereichen und auf unterschiedlichsten Ebenen nötig. Sei es zum Testen des Gesamtsystems (System-Test), ein manuell durchgeführter Test an einem Gerät (manueller Test) oder ein Test für eine kleine Software Einheit (Unit-Test). Typischerweise entsteht ein Testfall, indem sich jemand das bereits formulierte Requirement vornimmt, es liest und versucht zu verstehen. Basierend auf diesem Verständnis wird nach bestem Wissen und Gewissen ein Testfall spezifiziert. Der später durchgeführte Test dient dann als Nachweis dafür, dass das Requirement (oder ein Teil davon) technisch umgesetzt ist (oder eben nicht).
Dieser Ansatz hat jedoch folgende Nachteile:
- Die Person, die den Testfall spezifiziert, hat das Requirement normalerweise nicht formuliert. Dadurch entstehen häufig Missverständnisse bei der Formulierung des Tests.
- Die Person, die den Testfall spezifiziert, dokumentiert in der Regel nicht, welche Beweggründe für die gewählte Spezifikation des Testfalls ausschlaggebend waren.
Potentiell leiden also bei diesem Prozess sowohl Korrektheit als auch Nachvollziehbarkeit der Spezifikation des Testfalls. Hinzu kommt, dass Requirements zwar häufig beschreiben, wie das Medizinprodukt handeln soll und welche Eigenschaften / Bedingungen es erfüllen muss. Nicht selten sind diese Beschreibungen aber unstrukturiert und gegebenenfalls sogar mehrdeutig.
Diese Probleme können durch den Einsatz von Behaviour Driven Development (BDD) gelöst werden. Während BDD auch für das Design und bei der Entwicklung von Systemen eingesetzt werden kann, fokussieren wir uns in diesem Blogbeitrag auf den Einsatz in Bezug auf das Testen von Medizinprodukten.
Was ist Behaviour Driven Development (BDD)?
Behaviour Driven Development (BDD) ist eine Technik zur verhaltensgetriebenen Entwicklung von Software und Systemen. Das gewünschte Verhalten des Systems wird in einem Zwischenschritt auf Basis des gegebenen Requirements abstrakt und zugleich strukturiert beschrieben. Dadurch ist der Weg vom Requirement zur Spezifikation des Tests nachvollziehbar und präzise.
Innerhalb des genannten Zwischenschritts ist Gherkin eine typische Sprache zur Beschreibung von gewünschtem Systemverhalten im Rahmen von BDD. Gherkin gibt die folgende dreistufige Struktur vor:
Die einzelnen Beschreibungen der Teile sind in einer beliebigen Sprache verfasst und ermöglichen, bestimmte Worte als „wichtig“ zu markieren, um diese später für die (Teil-)Generierung von Tests zu nutzen.
In Zusammenarbeit mit dem Tool „Cucumber“ können mit Gherkin direkt aus diesen Beschreibungen Schablonen für Tests generiert werden, die sowohl eine grobe Teststruktur als auch einzelne Details vorgeben. Diese müssen dann noch mit weiteren Details zur Durchführung des Tests gefüllt werden.
Zur Verdeutlichung haben wir den Entstehungsprozess eines Testfalls anhand eines einfachen Beispiels zwischen „herkömmlich“ und „mit BDD“ gegenübergestellt.
| herkömmlich | mit BDD | |
|---|---|---|
| Requirement | Das Gerät muss sofort aus gehen, wenn der Nutzer auf den roten Knopf drückt. |
Antibakterielle Beschichtung Beschichtung zurVerbesserung des Einwachsverhaltens |
| BDD Zwischenschritt | Given Das Gerät ist eingeschaltet. When Der Nutzer auf den roten Knopf drückt. Then Schaltet sich das Gerät sofort aus. |
|
| Testfall | If roterKnopfGedrueckt schalteGeraetAus() |
If geraetAn If roterKnopfGedrueckt schalteGeraetAus() |
| Fazit | Der Testfall ergibt sich direkt aus dem Requirement, wie es sich der Testersteller vorstellt. |
Der Zwischenschritt führt zu einer klaren Strukturierung, der Testfall ist der Formulierung im Zwischenschritt sehr ähnlich. Die Struktur: Given- When-Then führt hier zu weiterer Erkenntnis: Gerät muss eingeschaltet sein. |
Tabelle für PC oder Smartphone herunterladen
Mit unserer Tabelle "Gegenüberstellung von der herkömmlichen Technik und der BDD-Technik" erhalten Sie den Überblick.
Wie löst BDD die oben genannten Probleme beim Testen von Medizinprodukten?
Die Vorteile werden schnell deutlich. Der Zwischenschritt
- verbessert die Nachvollziehbarkeit deutlich,
- kann auch von einem Requirements Engineer geschrieben werden, da er keine speziellen Kenntnisse benötigt,
- dient dem Testersteller als eindeutige Beschreibung des gewünschten System-Verhaltens, das durch das Requirement gefordert wird und
- ist gleichzeitig formal genug, um eine automatisierte (Teil-)Erstellung zu ermöglichen.
Der Zwischenschritt liefert noch weitere Vorteile. Es können
- schon frühzeitig Verständnisprobleme und Unklarheiten gefunden und beseitigt werden, bevor diese weitere Auswirkungen haben.
- auftretende Fehler oder Diskrepanzen zwischen dem Test und dem Requirement effizienter nachvollzogen werden.
- Mitarbeiter*innen, die nicht direkt an dem Test beteiligt waren, trotzdem sehr schnell einen Überblick bekommen und effizient nachvollziehen, welche Gedanken der Ersteller des Tests bei dessen Entwicklung hatte.
Weil BDD beide Seiten unterstützt, also sowohl den Requirement Engineer als auch den Testentwickler, hilft es der gesamten Entwicklungskette.
Insgesamt erlaubt der Einsatz von BDD
- eine Effizienzsteigerung in der korrekten Entwicklung von Tests, da durch die zusätzliche Ebene weniger Fehler passieren.
- eine bessere Nachverfolgbarkeit und ein generell besseres Verständnis.
- eine (teilautomatische) Generierung von Testfällen.
- die Unterstützung von Requirement Engineer und Testentwickler.
- gegebenenfalls durch Given-When-Then-Struktur Erkenntnis über weitere Fälle oder Bedingungen, die im Requirement implizit enthalten sind.
Zusammenfassung
In der Entwicklung und insbesondere in der Verifikationsphase eines Medizinprodukts kommt es vereinfacht ausgedrückt auf zwei Dinge an: So schnell wie möglich fertig werden (das Produkt soll ja verkauft werden) und so genau wie nötig testen, um vor dem Verkauf möglichst alle Fehler (also nicht erfüllte Anforderungen) im System zu finden. BDD kann dabei unterstützen, diese Herausforderung zu bewältigen. Durch den beschriebenen Zwischenschritt gewinnt die Verifikationsphase an Effizienz, Nachvollziehbarkeit, Exaktheit und Automatisierbarkeit.
Passende Seminare in der qtec Academy
20.11.- 21.11.2024
Unser Expertenwissen für Ihren Erfolg
Wir haben fundiertes Fachwissen bei der Zulassung von Medizinprodukten weltweit. Stellen Sie uns Ihre Fragen – wir geben konkrete Antworten und stellen auf Wunsch ein Projekt-Team für Sie zusammen.
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitieren Sie von unserem Fachwissen.
Jetzt anmelden
