Einen Testfall, den eine KI geschrieben hat, muss am Ende ein Mensch prüfen und freigeben. Ein grüner Lauf belegt nur, dass der Code läuft – nicht, dass er das Richtige prüft. Ein generierter Testfall, den niemand liest, ist kein Nachweis. Und im Audit kommt trotzdem die Frage: Wer hat ihn geprüft und freigegeben?
Der Unterschied
Im regulierten Umfeld ist das keine Kleinigkeit
In der Web- und App-Entwicklung ist ein schlechter generierter Test ein Ärgernis – man merkt es beim nächsten Bug und bessert nach. In einem Medizingerät oder einer sicherheitsgerichteten Steuerung bricht damit die Verifikationskette: Der Nachweis, dass eine Anforderung geprüft wurde, hängt daran, dass der Testfall das Richtige prüft und dass das jemand bestätigt hat. Ein ungelesener KI-Testfall liefert kein solches Fundament.
Was heute üblich ist
Generierter Code, den niemand liest, trägt nicht
Üblich ist: die KI erzeugt Python- oder Robot-Code, ein Entwickler überfliegt ihn, der Lauf wird grün. Zwei Probleme bleiben. Erstens können Qualitätssicherung und Zulassung diesen Code nicht lesen – die Menschen, die im Audit unterschreiben, sehen eine Blackbox. Zweitens gibt es keinen Beleg, dass ihn überhaupt jemand geprüft hat. Ein erheblicher Teil der KI-generierten Testfälle braucht ohnehin Nachbesserung, bevor er taugt – nur sieht man einem grünen Lauf nicht an, ob sie stattgefunden hat.
Der Mechanismus
Blöcke statt Code, Freigabe mit Fingerabdruck
XPressRT dreht das um. Die KI schreibt keinen Code, sie setzt Blöcke – jeder Block ein Satz, den ein Mensch liest. Fehlt ein Block für das, was ein Schritt braucht, hält die KI an und sagt welcher; sie baut sich keinen. XPressRT erzeugt aus den Blöcken den ausführbaren Schritt.
Und die Freigabe trägt einen Fingerabdruck: festgehalten wird, wer welchen Schritt freigegeben hat, mit dem Fingerabdruck der Blöcke und des daraus erzeugten Codes. Ändert sich danach etwas, passt der Abdruck nicht mehr. Eine Unterschrift lässt sich nachträglich nicht erschleichen.
Werkzeugqualifizierung
Einmal die Bausteine, danach nur die Reihenfolge
Weil die Bausteine feststehen und einmal geprüft werden, verschiebt sich die Prüfung: Nicht jeder generierte Testfall muss von Grund auf verifiziert werden, sondern nur seine Zusammensetzung – die Reihenfolge lesbarer Blöcke, die ein Mensch nachvollzieht. Das ist die Grundlage, auf der sich eine Werkzeugqualifizierung führen lässt, statt bei jedem KI-Lauf neu zu beginnen.
Häufige Fragen zu KI-generierten Testfällen
Wer gibt einen KI-generierten Testfall frei?
Ein Mensch – Qualitätssicherung oder Zulassung. In XPressRT liest er die Blöcke (jeder ein Satz, kein Code) und gibt sie frei. Die Freigabe wird mit einem Fingerabdruck der Blöcke und des erzeugten Codes festgehalten.
Wie dokumentiere ich das Review eines KI-Testfalls?
Über die Freigabe je Schritt: wer freigegeben hat, wann, und mit welchem Fingerabdruck. Ändert sich danach etwas am Testfall, passt der Abdruck nicht mehr – die Unterschrift lässt sich nicht nachträglich erschleichen.
Sind KI-generierte Tests mit IEC 62304 vereinbar?
Ja, wenn Prüfung und Freigabe belegt sind. Die Norm verlangt keine bestimmte Erzeugung, aber einen dokumentierten Nachweis, dass der Test das Richtige prüft und freigegeben wurde. Genau den liefert die Mechanik aus lesbaren Blöcken und Freigabe.
Ist das ein weiteres KI-Testtool oder ein Toolvergleich?
Nein. Hier geht es nicht um Testfallgenerierung, Self-Healing oder Prompt-Tipps, sondern um eine Frage: Wie wird ein KI-Testfall lesbar, prüfbar und freigebbar – so, dass er im Audit trägt.
Der prüffähige Weg mit KI
Die Bausteine-und-Freigabe-Mechanik steckt in XPressRT, der Prüfsoftware für Systemtests am Gerät. Im Browser, ohne Installation und ohne Konto – öffnen Sie es und sehen Sie, wie ein KI-Testfall lesbar, prüfbar und freigebbar wird.