KI‑generierte Testfälle im regulierten Umfeld

KI-gestützte Testfallgenerierung im regulierten Medizintechnik-Umfeld funktioniert, wenn das System keine Daten interpretiert, sondern nur eigene Dokumentation abruft. Ein RAG-System liefert Textchunks per Ähnlichkeitsanalyse, ein LLM erzeugt daraus strukturierte Testfälle. Der Mensch reviewt und gibt formal frei. So entsteht Nachvollziehbarkeit ohne Tool-Validierungspflicht.

Das Wichtigste in Kürze

• Das Hyde-Prinzip löst das Tagging-Problem bei hunderttausenden Dokumentseiten: Statt Fragen zu stellen, formuliert das System Behauptungen und prüft per Ähnlichkeitsanalyse, welche Dokumentchunks diese belegen.
• KI-generierte Testfälle im regulierten Bereich brauchen keine Toolvalidierung, solange ein Mensch jeden Output formal reviewt und per eSignature freigibt.
• Automatisches Prompt-Engineering, bei dem ein KI-Subsystem optimierte Prompts für ein anderes erzeugt, ermöglicht One-Click-Testfallgenerierung ohne Schulung der Tester im Prompten.
• Modularität schlägt Modellwahl: Wer die KI-Architektur so baut, dass einzelne Modelle austauschbar sind, ist unabhängig davon, welches Modell gerade aktuell ist.

Warum KI-gestütztes Testen in der Medizintechnik anders aussieht

Im regulierten Umfeld der Medizintechnik darf ein KI-System nichts hinzudichten. Genau das ist die zentrale Bedingung, unter der Alexander Frenzel von der Fresenius Medical Care einen Testfallgenerator aufgebaut hat: ein Assistenzsystem, das Tester unterstützt, ohne die regulatorische Nachvollziehbarkeit zu untergraben.

Fresenius entwickelt Hämodialyse-Maschinen, wie sie in Dialyse-Kliniken stehen. An solchen Geräten hängt der Blutkreislauf von Patienten. Fehler sind keine Option, und Innovation muss sich dieser Realität unterordnen. “Good is not good enough for us”, beschreibt Alexander den Anspruch, der jede technische Entscheidung rahmt.

Das Testen dieser Systeme ist vielschichtig. Es umfasst nicht nur Software, sondern auch Hardware, Elektronik, Materialien und biokompatible Komponenten, die alle miteinander interagieren. Der Proof of Concept startete bewusst bei der Software, mit dem Ziel, später breiter auszurollen.

Was den Testfallgenerator von einem Chatbot unterscheidet

Der Generator ist kein Prompt-Werkzeug für Endnutzer, sondern ein One-Click-Ansatz. Der Tester gibt ein Requirement ein, drückt einen Knopf, und am Ende kommt ein Testfall heraus.

Diese Entscheidung folgt aus der Usability. In einer großen Testorganisation müsste man sonst viele Menschen erst dazu befähigen, vernünftig zu prompten. Stattdessen übernimmt ein KI-Subsystem die Prompt-Erstellung selbst: Es generiert aus dem Input mehrere Prompts, die für ein nachgelagertes KI-System optimiert sind.

Dahinter steht keine einzelne KI, sondern eine Architektur aus mehreren Systemen, teils unterschiedlichen LLMs und Modellen. Genau diese Komplexität ist der Grund, warum die Frage “Wie ziehe ich so etwas auf?” über den Erfolg entscheidet, nicht die Wahl eines einzelnen Tools.

Warum Nachvollziehbarkeit von Anfang an eingebaut sein muss

Im regulierten Bereich darf es keinen Platz für Halluzinationen geben. Deshalb war Reasoning für Fresenius schon vor der breiten KI-Welle ein Pflichtbestandteil, zu einem Zeitpunkt, als gängige Chatbots das noch nicht boten.

Die Tester müssen wissen, woher eine Aussage stammt. Wie kommt das System von einem Textbaustein zu den Grenzwerten einer Boundary-Analyse? Wie entstehen die Äquivalenzklassen? Diese Gedankengänge müssen abbildbar sein, sonst ist das Ergebnis im regulatorischen Sinn wertlos.

Fresenius brachte dafür nicht KI-Expertise mit, sondern Domänenwissen. Die KI-Kompetenz kam von externen Partnern. Der eigene Beitrag war das Geschäftskonzept: zu definieren, wie das System aussehen muss, damit ein echter Mehrwert entsteht.

Wie das Hyde-Prinzip verteilte Dokumentation nutzbar macht

Das System arbeitet mit den eigenen Dokumenten über ein RAG-System, ohne sie zu interpretieren. So wird nichts Neues hinzugedichtet, und die Tester behalten ihre originale Dokumentation.

Das Grundproblem: Die Daten liegen auf verteilten Systemen und Ablagen, teils als Word-Dateien aus dem Jahr 2002, die nie in ein aktuelles ALM-System überführt wurden. Bei Hunderttausenden Seiten lässt sich nichts manuell taggen.

Die Lösung kam von einem der Architekten: das Hyde-Prinzip. Statt eine Frage zu stellen, stellt das System eine Behauptung auf und lässt sie anhand der Daten im RAG-System belegen. Ähnlichkeiten erkennt ein KI-System leichter als direkte Antworten.

Über eine Ähnlichkeitsanalyse prüft das System, zu wie viel Prozent ein Textabschnitt von den Vektoren her zur Behauptung passt. So findet es die relevanten Chunks, ohne dass die KI den Inhalt verändert. Ein weiterer Vorteil: Die nötige Menge an eigenen Testdaten, um ein LLM direkt zu trainieren, hätte Fresenius für ein einzelnes Projekt gar nicht gehabt. Der RAG-Ansatz löst diese Abhängigkeit auf.

Der Mensch bleibt in jedem Prozessschritt

Ein Man in the Middle war von Anfang an gesetzt. Der Tester kann an jeder Stelle eingreifen, tweaken und eigene Erfahrungswerte einbringen, ohne bei null neu zu starten.

Das macht den Output zu einem Draft, nicht zu einem fertigen Ergebnis. Tester entscheiden selbst, ab wann sie das Generierte als Grundlage übernehmen. Danach folgen weiterhin der Test an der Maschine, das Review und die Freigabe als Voraussetzung für eine formale Testdurchführung.

Die Entwicklung lief 2024 über etwa ein Dreivierteljahr, mit einem kleinen internen und einem größeren externen Team, im Schnitt rund zehn Personen, die das zusätzlich zur Regelarbeit stemmten. Mit einem dedizierten Team wäre das in zwei bis drei Monaten machbar, heute vermutlich schneller.

Modularität schlägt die Wahl des perfekten Modells

Die Architektur ist so gebaut, dass Modelle austauschbar sind. Das war Fresenius wichtiger als die Entscheidung für ein bestimmtes Modell, weil sich diese Modelle laufend weiterentwickeln.

Im Verlauf wurde viel ausprobiert: erst Llama, dann Claude, dann wieder Llama. Hinzu kamen technische Hürden rund um den Betrieb in einer eigenen Cloud, denn Intellectual Property lässt sich nicht in öffentliche Dienste schieben. Das System muss separat laufen und beherrschbar bleiben.

Kommt ein neues Modell heraus, lässt es sich gegen das bestehende tauschen und auf höheren Output prüfen. Diese Adaptierfähigkeit hält die Lösung über Modellgenerationen hinweg lebensfähig.

Wo KI-gestütztes Testen an Grenzen stößt

Bei Software funktionierte der Generator sehr gut. Schwierig wird es, sobald physikalische Abhängigkeiten ins Spiel kommen.

Ein Beispiel: ein Schlauchsystem, das gefüllt wird. Der Druck ist nicht statisch, sondern hochdynamisch. Solche Effekte lassen sich nicht ohne Weiteres modellieren. Man braucht ein Physical Model dahinter, und dieses Modell müsste bei jedem neuen Feature, jedem neuen Motor, jedem ausgetauschten Bauteil nachgepflegt werden. Dieser Aufwand setzt der KI-Unterstützung in der physikalischen Domäne enge Grenzen.

Warum hier keine Tool-Validierung nötig ist

Ein generatives, nicht-deterministisches System lässt sich kaum klassisch validieren. Nach langer Diskussion stand die entscheidende Frage im Raum: Muss man das überhaupt? Die Antwort war Nein, und zwar mit Begründung.

Mehrere Bedingungen tragen diese Einschätzung:

• Der Output dient als Draft, nicht als finales Ergebnis.
• Ein Mensch reviewt und gibt per E-Signatur formal frei.
• Die Daten liegen ungelabelt im RAG-System, das System verändert sie nicht.
• Für jeden Prozessschritt entsteht Dokumentation, in die man jederzeit einspringen und tweaken kann.

Dann ist das nur ein Tool, das dich befähigt, aber nicht eines, das dir die Arbeit abnimmt. Und damit bist du regulatorisch schon wieder auf gutem Fuß. — Alexander Frenzel

Mit gutem Logging bleibt nachvollziehbar, was herauskommt. Wie das System exakt zu einem Ergebnis kommt, lässt sich nicht hundertprozentig rekonstruieren, und sprachlich fällt mal die eine, mal die andere Formulierung schöner aus. Die zugrunde liegende Information bleibt aber gleich, weil sie nicht verändert wird.

Was Tester überraschend nützlich fanden

Im internen Beta-Test war die erste Reaktion Euphorie über den Output. Den größten Mehrwert sahen die Tester aber an einer Stelle, mit der das Team nicht gerechnet hatte: dem Knowledge Transfer.

Weil das System für jeden erwarteten Testschritt zeigt, woher die Erwartungshaltung stammt, stießen Tester auf Dokumente, die sie nicht auf dem Schirm hatten. Bei vielen verteilten Dokumentationen wird so sichtbar, wo relevante Information tatsächlich steht.

Der zweite große Punkt war die Eingriffsmöglichkeit über den gesamten Prozess. Niemand muss bei null beginnen. Ein nicht perfekter, aber tragfähiger Draft spart Zeit, die in das Feintuning vor Review und Freigabe fließen kann.

Vom Draft zur Pipeline: die naheliegenden nächsten Schritte

Die nächsten Ausbaustufen ergeben sich fast von selbst aus dem bestehenden System. Zuerst soll der bisher als Web-Anwendung laufende Generator direkt in die ALM- und PLM-Systeme integriert werden.

Die RAG-Datenbank soll über Service-Interfaces an unterschiedliche Dokumentenverwaltungssysteme und Datenbanken angebunden werden, um die Daten besser verfügbar zu machen. Aus einer gut dokumentierten Testspezifikation mit Trace lässt sich ein Keyword-Driven-Test erzeugen, indem man dem System die eigene Keyword-Bibliothek übergibt.

Von dort ist der Weg zu einem Test-Script für ein Software-in-the-Loop-System kurz. Das Script könnte direkt in die Pipeline laufen, in der Simulation getestet und bei Fehlern vom System selbst überarbeitet werden, etwa über einen LLM-as-a-Judge-Ansatz.

Eines bleibt in jeder Ausbaustufe bestehen: der Man in the Middle für Freigabe und Nachvollziehbarkeit. Das nötige Systemverständnis und das Testdesign muss der Mensch beherrschen, um beurteilen zu können, ob das Ergebnis wirklich das prüft, was geprüft werden soll. Lehrpläne wie der neue GenAI-Lehrplan von GTB und ISTQB helfen dabei, diese Beurteilung fundiert zu treffen.