Das KI-Digitalisierungs-Fax Warum testen wir noch wie 2005? Wie KI die V&V entlastet

Anbieter zum Thema

M&M Software GmbH

KUMAVISION AG

Metecon GmbH

HMS Technology Center GmbH

Anforderungen prüfen, Testfälle schreiben, Traceability pflegen: In der Software-Entwicklung für Medizinprodukte fließt ein Großteil der Verifizierungsarbeit nicht direkt ins Testen, sondern in die Handarbeit drumherum. Im dritten Teil der Kolumne „Das KI-Digitalisierungs-Fax“ geht es darum, wo KI hier echte Zeit sparen kann – und wo sie regulatorisch zum Problem wird.

Es ist Donnerstagabend, zwei Wochen vor dem geplanten Release. Ein Change Request ist gerade genehmigt worden: Drei Software-Anforderungen ändern sich, eine davon ist mit einer Risikobeherrschungsmaßnahme verknüpft. Der Testmanager öffnet die Traceability-Matrix – eine Excel-Datei mit 14 Reitern und einer letzten Änderung vor sechs Wochen. Seine Frage ist einfach: Welche der rund 1.800 Testfälle sind betroffen? Die Antwort ist es nicht.

Die Verlinkungen sind teilweise veraltet, einige Testfälle referenzieren Anforderungen, die es in dieser Form nicht mehr gibt, und bei der Risikobeherrschungsmaßnahme weiß niemand genau, welcher Systemtest ihre Wirksamkeit eigentlich nachweist. Das Team trifft die Entscheidung, die in solchen Situationen immer getroffen wird: Wir fahren sicherheitshalber die komplette Regression. Manuell. Drei Wochen. Der Release verschiebt sich.

Niemand in diesem Team arbeitet schlecht. Die Tests sind gründlich, die Dokumentation ist auditfest. Das Problem ist ein anderes: Die Verifizierung und Validierung (V&V) wird 2026 in vielen Unternehmen immer noch so organisiert wie zu der Zeit, als die IEC 62304 geschrieben wurde. Die Werkzeuge (Tools) sind elektronisch geworden – die Arbeitsweise ist es nicht.

Das Problem ist nicht das Testen. Es ist alles drumherum.

Wer in einem Medtech-Softwareprojekt erfasst, wohin die V&V-Aufwände tatsächlich fließen, erlebt meist eine Überraschung. Die eigentliche Testdurchführung ist oft der kleinere Teil. Den größeren Teil verschlingen Tätigkeiten, die mit Testen wenig zu tun haben:

• Anforderungen werden erst beim Schreiben der Testspezifikation als gar nicht oder nicht eindeutig testbar erkannt und gehen zurück in das Requirements Engineering.
• Testfälle werden von Hand aus Anforderungen abgeleitet, formuliert, reviewt und formal freigegeben.
• Traceability wird manuell gepflegt: Anforderung zu Architektur, zu Testfall, zu Testergebnis, zur Risikobeherrschungsmaßnahme.
• Bei jeder Änderung wird eine Impact-Analyse erstellt, die im Zweifel zu „alles nochmal“ führt.

Genau das sind die Tätigkeiten, bei denen KI heute realistisch helfen kann. Nicht, weil sie besser testet als ein erfahrener Testingenieur. Sondern weil sie die strukturierte Fleißarbeit abnimmt, die zwischen Anforderung und Nachweis liegt.

Was die Norm verlangt – und was sie nicht verlangt

Bevor es um Tools geht, lohnt ein nüchterner Blick in die IEC 62304. Die Norm verlangt verifizierbare Software-Anforderungen, geplante, spezifizierte und dokumentierte Tests, je nach Software-Sicherheitsklasse auf Unit-, Integrations- und Systemebene, nachvollziehbare Ergebnisse und eine lückenlose Rückverfolgbarkeit zwischen Gefährdungen, Ursachen, Risikobeherrschungsmaßnahmen und deren Verifizierung. Sie verlangt nicht, dass Testfälle von Menschen formuliert werden. Sie schreibt nicht vor, wie eine Impact-Analyse zustande kommt.

Die Norm ist also methodenoffen. Das ist die gute Nachricht. Die weniger gute: Sie enthält auch keine eigene Anforderung an die Qualifizierung von Entwicklungs- und Test-Tools. Diese Lücke füllt – wie in der zweiten Ausgabe dieser Kolumne beschrieben – die ISO 13485 mit Abschnitt 4.1.6: Software, die in QM-relevanten Prozessen eingesetzt wird, ist risikobasiert zu validieren. Ein KI-Tool, das Testfälle für ein Medizinprodukt erzeugt, fällt eindeutig darunter.

Hilfreich als Denkmodell ist ein Blick über den Tellerrand in die funktionale Sicherheit. Die IEC 61508-3:2010 unterscheidet Entwicklungs-Tools danach, wie sich ein Tool-Fehler auf die ausführbare Software auswirken kann:

• Tools, deren Output weder direkt noch indirekt in den ausführbaren Code eingeht (Klasse T1, etwa Editoren oder Anforderungstools);
• Tools für Test und Verifikation, deren Fehler dazu führen können, dass Defekte unentdeckt bleiben, die aber selbst keine Fehler in den Code einbringen (T2, etwa Testtools oder statische Analyse); und
• Tools, deren Output direkt oder indirekt in den ausführbaren Code eingeht (T3, etwa Compiler oder Codegeneratoren).

Diese Einteilung ist für die Medizintechnik nicht verbindlich, aber sie beantwortet die wichtigste Frage sehr klar: Ein KI-Tool, das Tests vorschlägt, kann im schlimmsten Fall eine Lücke übersehen. Ein KI-Tool, das Produktcode schreibt, kann eine Lücke erzeugen. Das ist ein fundamentaler Unterschied im Prozessrisiko – und damit im Nachweisaufwand.

Übrigens: Die seit Jahren erwartete zweite Ausgabe der IEC 62304 wird an diesem Befund voraussichtlich nichts ändern. Sie wird zwar erstmals Anforderungen an KI-Entwicklungsprozesse enthalten, allerdings für KI im Produkt, nicht für KI als Entwicklungs-Tool. Und bis sie veröffentlicht und harmonisiert ist, gilt ohnehin die bestehende Fassung.

Vier Felder, in denen KI die V&V verändert

1. Automatisierte Anforderungsprüfung: Fehler finden, bevor sie Tests kosten

Die IEC 62304 fordert, Software-Anforderungen zu verifizieren: auf Widerspruchsfreiheit, Testbarkeit, eindeutige Identifizierbarkeit und Rückverfolgbarkeit. In der Praxis passiert das in einem Review, das unter Zeitdruck oft auf die Vollständigkeit der Felder reduziert wird.

Genau hier ist KI besonders stark – und besonders risikoarm. Ein Sprachmodell erkennt zuverlässig Formulierungen, wie „Das System soll schnell reagieren“, fehlende Einheiten, unklare Bedingungen, widersprüchliche Anforderungen in unterschiedlichen Kapiteln oder Anforderungen, die eigentlich zwei Anforderungen sind. Es entscheidet nichts. Es markiert. Der Mensch bewertet.

Der Vorteil ist enorm, weil jeder Fehler, der hier gefunden wird, später nicht als Rückfrage beim Testdesign, als fehlgeschlagener Test oder als Befund im Audit auftaucht. Wer mit KI in der V&V beginnen will, sollte genau hier beginnen.

2. Testfallgenerierung: Schneller zur Spezifikation – mit einer entscheidenden Falle

KI kann aus einer sauber formulierten Anforderung in Sekunden einen Satz von Testfällen ableiten: Normalfall, Grenzwerte, Äquivalenzklassen, Negativtests, Fehleingaben. Das ist echte Zeitersparnis, gerade bei umfangreichen Parameter- und Schnittstellenanforderungen, bei denen Menschen systematisch Grenzfälle vergessen.

Die Falle liegt in der Frage, woher das erwartete Ergebnis kommt: in der Testtheorie das sogenannte Testorakel-Problem. Ein Testfall ist nur so gut wie die Instanz, die festlegt, was richtig ist. Leitet die KI Testfälle aus der Anforderung ab, prüft der Test die Spezifikation. Leitet sie Testfälle aus dem Quellcode ab – was viele Codeassistenten standardmäßig tun –, prüft der Test nur noch, ob der Code tut, was er tut.

Eine KI, die Testfälle aus dem Code ableitet, prüft, was die Software tut – nicht, was sie tun soll.

Solche Tests sind nicht wertlos; als Regressionsschutz sind sie sogar sehr nützlich. Aber sie sind kein Verifizierungsnachweis im Sinne der Norm. Wer mit KI-generierten Unit-Tests eine hohe Code-Coverage für ein Software-System der Klasse C belegen will, sollte sehr genau erklären können, gegen welche Anforderung diese Tests eigentlich prüfen.

3. Traceability-Analyse: Vom Pflegen zum Prüfen

In der ersten Ausgabe dieser Kolumne war von Copy-Paste-Traceability die Rede: Rückverfolgbarkeit, die als Momentaufnahme existiert und mit dem nächsten Change Request veraltet. KI kann hier eine Rolle übernehmen, die bisher niemand hatte: die des permanenten Prüfers.

Konkret heißt das: verwaiste Anforderungen ohne Test erkennen, Tests ohne Anforderung identifizieren, verdächtige Links markieren, bei denen der Testfall inhaltlich gar nicht zur verknüpften Anforderung passt, und bei Änderungen eine begründete Vorauswahl der betroffenen Testfälle liefern. Die Szene vom Anfang dieses Beitrags – die komplette Regression „sicherheitshalber“ – wird dann durch eine gezielte, nachvollziehbar begründete Regressionsauswahl ersetzt, die ein Mensch prüft und freigibt.

Aber: Diese Analyse funktioniert nur, wenn Anforderungen, Tests und Risiken als strukturierte, verknüpfbare Datenobjekte vorliegen. In 14 Excel-Reitern mit Freitextverweisen findet auch die beste KI nur das, was sie ohnehin schon rät. Es gilt die Gleichung aus der ersten Ausgabe: Medienbruch x KI = automatisierter Datenmüll.

4. Risiko-Identifikation: Mehr Perspektiven, nicht weniger Verantwortung

Die ISO 14971 verlangt, Gefährdungen und Gefährdungssituationen systematisch zu identifizieren und die Umsetzung sowie die Wirksamkeit von Risikobeherrschungsmaßnahmen zu verifizieren. KI kann dabei auf zwei Wegen helfen.

Erstens als Ideengeber: Aus Reklamationsdaten, früheren FMEAs vergleichbarer Produkte, Literatur und Vigilanzdatenbanken lassen sich Gefährdungskandidaten vorschlagen, an die das Team im Workshop nicht gedacht hätte.

Zweitens als Konsistenzprüfer: Ist jede Risikobeherrschungsmaßnahme mit einer Anforderung verknüpft? Hat jede dieser Anforderungen einen Test, der die Wirksamkeit und nicht nur die Umsetzung nachweist?

Das Risiko liegt hier in der Vollständigkeitsillusion. Eine KI-generierte Gefährdungsliste wirkt strukturiert, umfassend und souverän – und genau deshalb wird sie seltener hinterfragt als eine lückenhafte Liste aus dem Workshop. Die Verantwortung für die Vollständigkeit der Risikoanalyse bleibt beim Hersteller. KI erweitert das Suchfeld. Sie schließt es nicht ab.

Wo KI echte Zeit spart – und wo sie regulatorisch problematisch wird

Echte Zeitersparnis:

• Anforderungsreview vor der Baseline. Mehrdeutigkeiten, Widersprüche und fehlende Testbarkeit werden früh sichtbar.
• Erstentwürfe von Testspezifikationen aus freigegebenen Anforderungen, inklusive Grenzwert- und Negativfällen.
• Impact-Analyse bei Change Requests. Begründete Vorauswahl betroffener Testfälle statt Vollregression.
• Laufende Traceability-Prüfung. Lücken und verdächtige Links werden gemeldet, bevor das Audit sie findet.
• Auswertung von Testprotokollen. Clustering fehlgeschlagener Tests nach wahrscheinlicher Ursache.

Regulatorisch problematisch:

• KI als Testorakel. Wenn die KI festlegt, was das erwartete Ergebnis ist, und gleichzeitig das Ergebnis bewertet, fehlt die unabhängige Instanz.
• Automatische Pass-/Fail-Bewertung von Systemtests ohne menschliche Prüfung, insbesondere bei Tests, die Risikobeherrschungsmaßnahmen verifizieren.
• „Selbstheilende“ Tests, die sich stillschweigend an geändertes Softwareverhalten anpassen. Was im Web-Frontend praktisch ist, kaschiert in der Medizintechnik unter Umständen genau die Regression, die der Test finden sollte.
• Nicht eingefrorene Testsuiten. Wird eine Testspezifikation bei jedem Durchlauf neu generiert, ist sie nicht reproduzierbar. KI-generierte Testfälle müssen nach der Freigabe als Artefakt unter Konfigurationsmanagement stehen, wie jeder andere Testfall auch.
• Quellcode und Anforderungen in offenen Tools. Die Datenregel aus der zweiten Ausgabe gilt hier umso mehr: Produktcode ist Betriebsgeheimnis, und Anforderungen verraten oft mehr über die Zweckbestimmung, als man in einem externen Tool sehen möchte.

Mini-Case: 30 Prozent weniger manuelle Testarbeit – und woher sie wirklich kommen

Ein mittelständischer Hersteller entwickelt die Software für ein Medizinprodukt der Klasse IIa: rund 900 Software-Anforderungen, knapp 2.000 Testfälle, davon ein Großteil manuell. Jeder Release bindet das Testteam über Wochen – der größte Teil davon in Regressionstests und in der Überarbeitung von Testspezifikationen nach Anforderungsänderungen.

Eingeführt wurden vier Maßnahmen, keine davon spektakulär:

1. Jede Anforderung durchläuft vor der Baseline eine KI-gestützte Prüfung auf Mehrdeutigkeit und Testbarkeit; die Befunde bewertet der Requirements Engineer.
2. Testspezifikationen für neue und geänderte Anforderungen werden als KI-Entwurf erstellt, von einem Testingenieur überarbeitet und regulär freigegeben.
3. Bei jedem Change Request liefert die KI eine begründete Vorauswahl der betroffenen Testfälle; der Testmanager entscheidet und dokumentiert die Regressionsstrategie.
4. Der Tool-Einsatz wurde nach dem CSA-Gedanken abgesichert: Nachweisgegenstand ist nicht das Modell, sondern die Wirksamkeit der menschlichen Kontrolle in jedem der drei Schritte.

Das Ergebnis nach drei Releases: rund 30 Prozent weniger manueller Aufwand in Testspezifikation und Regression. Interessanter ist, woher diese Einsparung kommt. Nicht aus der Testdurchführung, die blieb weitgehend gleich. Sondern zu etwa gleichen Teilen aus weniger Klärungsschleifen, weil Anforderungen früher sauber waren, und aus gezielter statt vollständiger Regression.

Genauso aufschlussreich ist, wo nichts gewonnen wurde: bei Systemtests mit realer Hardware, bei der Usability-Validierung nach IEC 62366-1 und beim ersten Release, der durch Einrichtung, Tool-Bewertung und Schulung zunächst mehr Aufwand verursachte als zuvor. Wer KI in der V&V einführt, investiert zuerst und spart danach.

Fazit: KI ersetzt keine Entwickler – sie nimmt ihnen die falsche Arbeit ab

Die Frage „Warum testen wir noch wie 2005?“ hat eine unbequeme Antwort: weil die Aufwände in der V&V selten dort liegen, wo man sie vermutet. Nicht die Testdurchführung ist der Engpass, sondern die manuelle Übersetzungsarbeit zwischen Anforderung, Test, Risiko und Nachweis. Genau dort kann KI helfen – mit einem regulatorischen Risiko, das beherrschbar ist, solange drei Prinzipien gelten:

1. Das Orakel bleibt beim Menschen. Was richtig ist, bestimmt die freigegebene Anforderung, nicht das Modell.
2. Was generiert wird, wird eingefroren. Ein freigegebener KI-Testfall ist ein Artefakt wie jedes andere: versioniert, reviewt, rückverfolgbar.
3. Die Kontrolle wird nachgewiesen, nicht das Modell. Validiert wird der Prozess, in dem die KI einen Beitrag leistet.

KI ersetzt keine Entwickler und keine Testingenieure. Sie entlastet sie von der Arbeit, die ihre Qualifikation am wenigsten braucht, und schafft Zeit für die Arbeit, die sie am meisten braucht: das kritische Hinterfragen. Die Voraussetzung bleibt dieselbe wie in den ersten beiden Ausgaben dieser Kolumne: erst Struktur, dann Daten, dann KI. Eine Traceability, die in Excel-Reitern lebt, wird durch KI nicht intelligenter, sondern nur schneller unzuverlässig.

In der nächsten Ausgabe wechseln wir die Perspektive: vom KI-Tool im Entwicklungsprozess zur KI im Medizinprodukt selbst. Dann geht es um die Frage, ob Ihr KI-Produkt wirklich AI-Act-ready ist – und warum die Schnittstelle zwischen ISO 14971 und Artikel 9 der KI-Verordnung komplizierter ist, als sie aussieht.