##  Pfadnavigation

1. [ Startseite ](/)
2. [ Software Testing &amp; Qualität - Testautomatisierung, KI &amp; Agilität ](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)
3. KI-gestützte Testfallgenerierung in regulierten Umfeldern sicher nutzen

# KI-gestützte Testfallgenerierung in regulierten Umfeldern sicher nutzen

            **Podcast:**

   [Software Testing &amp; Qualität - Testautomatisierung, KI &amp; Agilität](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)

              **Erscheinungsdatum:**

   24. Februar 2026

            **Länge:**

   00:23:51

    [         Link zur Episode (extern)   ](https://www.richard-seidl.com/de/podcast/ki-generierte-testfaelle)

 ![KI‑generierte Testfälle im regulierten Umfeld - Alexander Frenzel](https://www.botcaster.de/sites/default/files/styles/podcast_n_episode_metadata_image_1x/public/2026-08/5caa6916-2e96-4191-96ea-cdda2da80c4e.jpg.webp?itok=fDeG9YRG)

###   KI‑generierte Testfälle im regulierten Umfeld - Alexander Frenzel

   24. Februar 2026 · [Software Testing &amp; Qualität - Testautomatisierung, KI &amp; Agilität](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)

Stell dir vor, du arbeitest in der Medizintechnik, wo jeder Softwarefehler fatale Folgen haben kann. Die regulatorischen Hürden sind extrem hoch, die Prozesse langwierig und die Dokumentation erdrückend. Wie passt in dieses Umfeld die Idee, Testfälle von einer generativen KI erstellen zu lassen - einer Technologie, die für ihre Kreativität, aber auch für ihre Unberechenbarkeit bekannt ist? Genau diese Herausforderung beleuchtet Richard Seidl in einer Episode seines Podcasts *Software Testing &amp; Qualität*. Sein Gast, Alexander Frenzel von Fresenius Medical Care, gibt faszinierende Einblicke in einen Proof of Concept, der zeigt, wie KI als wertvoller Assistent im Testprozess dienen kann, ohne die strengen Sicherheits- und Nachweispflichten zu verletzen. Diese Episode ist ein Muss für alle, die an der Schnittstelle von KI, Softwarequalität und stark regulierten Branchen arbeiten und verstehen wollen, wie man Innovation sicher und nachvollziehbar gestaltet.

## Das Wichtigste auf einen Blick

- **KI als Assistenzsystem, nicht als autonomer Entscheider:** Der zentrale Ansatz ist, die KI nicht als Ersatz, sondern als hochentwickelten Assistenten für Tester:innen zu sehen. Das Man in the Middle-Prinzip stellt sicher, dass jede von der KI generierte Ausgabe von einem Menschen überprüft, angepasst und formal freigegeben wird.
- **Architektur für Nachvollziehbarkeit:** Statt eines einfachen Chatbots wurde eine komplexe Systemarchitektur entwickelt. Ein zentrales Element ist ein Retrieval-Augmented-Generation-System (RAG), das auf unternehmensinternen Dokumenten basiert und sicherstellt, dass die KI keine Informationen halluziniert, sondern sich strikt an die vorgegebene Wissensbasis hält.
- **Intelligente Prompt-Erstellung:** Um die Bedienung zu vereinfachen und die Qualität der Ergebnisse zu maximieren, generiert ein vorgeschaltetes KI-System die optimalen Prompts für das eigentliche testfallerzeugende System. Anwender:innen benötigen so keine speziellen Prompting-Kenntnisse.
- **Der Trick bei der Tool-Validierung:** Im regulierten Umfeld ist die Validierung von Werkzeugen eine große Hürde. Der vorgestellte Ansatz umgeht dieses Problem geschickt: Da der von der KI erstellte Testfall nur ein Entwurf (Draft) ist, der menschlich geprüft und freigegeben wird, liegt die Verantwortung beim Menschen. Das KI-System selbst muss somit nicht als qualitätsentscheidendes Werkzeug validiert werden.
- **Fokus auf Software-Tests:** Der Proof of Concept zeigte, dass die KI-gestützte Testfallgenerierung besonders gut für reine Software-Komponenten funktioniert. Bei komplexen physikalischen Abhängigkeiten, wie sie in den Schlauchsystemen einer Dialysemaschine auftreten, stößt der Ansatz an seine Grenzen, da die Modellierung der Realität zu aufwendig wäre.

## Der Spagat zwischen Innovation und regulatorischer Sicherheit

Alexander Frenzel arbeitet bei Fresenius Medical Care an der Entwicklung von Hämodialyse-Maschinen - Geräten, an denen buchstäblich Menschenleben hängen. Die Dialyse ist ein Blutwäscheverfahren, bei dem der Blutkreislauf eines Patienten direkt an die Maschine angeschlossen wird. In einem solchen Umfeld, so erklärt Alexander, ist das Motto gut ist nicht gut genug. Jede Neuerung, jede Softwareänderung muss extrem rigoros geprüft und validiert werden. Gleichzeitig ist der Druck zur Innovation hoch, um den Patient:innen nicht nur ein Überleben, sondern ein lebenswertes Leben zu ermöglichen.

Die Testfallerstellung ist in diesem Kontext ein enorm zeitaufwendiger Prozess. Für einen einzigen komplexen Testfall können inklusive Analyse und Validierung bis zu fünf Tage vergehen. Hinzu kommen Herausforderungen wie Legacy-Systeme mit veralteter Dokumentation, die teilweise noch in Word-Dokumenten aus den frühen 2000er-Jahren vorliegt, und physikalische Abhängigkeiten zwischen Software, Elektronik und Hardware. Um diesen Prozess zu beschleunigen und die Tester:innen zu entlasten, startete sein Team einen Proof of Concept für einen KI-gestützten Testfallgenerator.

## Die Architektur des KI-Testfallgenerators: Mehr als nur ein Chatbot

Die entwickelte Lösung ist weit mehr als ein einfacher Wrapper um ein großes Sprachmodell (LLM). Das Team erkannte früh, dass ein normaler Chatbot-Ansatz für ihre Zwecke ungeeignet wäre. Das Ziel war ein One-Click-Generator: Eine Testerin oder ein Tester wählt ein Requirement aus und erhält auf Knopfdruck einen fundierten Testfallentwurf. Um das zu erreichen, wurde eine mehrstufige Architektur entworfen.

Ein Kernstück ist ein sogenanntes **Retrieval-Augmented-Generation (RAG)**-System. Alle relevanten Dokumentationen - von modernen ALM-Einträgen bis hin zu alten Word-Dateien - werden in einer zentralen Vektordatenbank gesammelt. Die KI greift ausschließlich auf diese verifizierte Wissensbasis zu, was verhindert, dass sie Fakten erfindet oder auf externes, ungesichertes Wissen zurückgreift. Um die richtigen Informationen in den hunderttausenden Seiten zu finden, nutzt das System das sogenannte **Hyde-Prinzip** (Hypothetical Document Embeddings). Statt eine offene Frage zu stellen (z.B. Welche Testfälle gibt es für Feature X?), formuliert die KI eine Behauptung (z.B. Hier ist ein relevanter Testfall für Feature X) und sucht dann in der Datenbank nach den Dokumenten-Ausschnitten, die dieser Behauptung am ähnlichsten sind. Dieser Ansatz, so Alexander, ist für eine KI deutlich einfacher und liefert präzisere Ergebnisse.

Die gesamte Architektur ist modular aufgebaut. So können die zugrundeliegenden LLMs (im PoC wurden unter anderem Llama und Claude getestet) jederzeit ausgetauscht werden, um von den neuesten technologischen Fortschritten zu profitieren, ohne das Gesamtsystem neu entwerfen zu müssen.

## Der Mensch im Mittelpunkt: Warum KI nur ein Assistent bleibt

Ein zentrales Credo des Projekts war von Anfang an, dass die KI ein Werkzeug zur Unterstützung und nicht zum Ersatz von menschlicher Expertise ist. In jedem Schritt des Generierungsprozesses ist ein menschlicher Eingriff möglich und vorgesehen - das Man in the Middle-Prinzip. Der generierte Testfall ist explizit als Entwurf zu verstehen. Eine erfahrene Testerin muss diesen Entwurf prüfen, die abgeleiteten Grenzwerte und Äquivalenzklassen validieren und bei Bedarf anpassen.

Diese Nachvollziehbarkeit ist entscheidend. Das System dokumentiert genau, aus welchen Text-Abschnitten der Quelldokumente es zum Beispiel ein bestimmtes erwartetes Ergebnis (Expected Result) abgeleitet hat. Alexander berichtet, dass dies ein unerwartet positiver Nebeneffekt war: Tester:innen stießen auf Dokumente, die sie gar nicht kannten, was den Wissenstransfer im Team verbesserte. Erst nach der sorgfältigen Prüfung und formalen Freigabe durch eine Person (z.B. per E-Signatur) wird der Testfall für die formale Testdurchführung verwendet.

## Die überraschende Lösung für die Tool-Validierung

In der Medizintechnik muss jedes Werkzeug, das die Qualität des Endprodukts beeinflusst, einem aufwendigen Validierungsprozess unterzogen werden. Wie validiert man aber ein nicht-deterministisches, generatives KI-System? Nach langen Diskussionen kam das Team zu einer einfachen, aber genialen Erkenntnis: Es ist gar nicht nötig. Da die KI lediglich einen Entwurf erstellt und die endgültige Verantwortung für den Inhalt und die Korrektheit des Testfalls beim prüfenden Menschen liegt, wird das KI-System nicht als qualitätssicherndes, sondern als unterstützendes Werkzeug klassifiziert. Die nachvollziehbare Kette von der Anforderung über die Quelldokumente bis zum Testfallentwurf liefert den nötigen Audit-Trail, ohne das KI-Modell selbst validieren zu müssen.

## Erkenntnisse aus dem Proof of Concept und die nächsten Schritte

Der über ein Dreivierteljahr laufende Proof of Concept wurde von den beteiligten Tester:innen euphorisch aufgenommen. Die Zeitersparnis und die hohe Qualität der Entwürfe überzeugten. Gleichzeitig wurden die Grenzen klar: Während die Methode für Software-Logik hervorragend funktionierte, waren Tests mit komplexen physikalischen Wechselwirkungen (z.B. Druckaufbau in Flüssigkeiten) kaum abbildbar. Dies würde eine aufwendige physikalische Modellierung erfordern, die den Rahmen sprengen würde.

Die nächsten Schritte sind ambitioniert: Das System soll direkt in die bestehenden ALM- (z.B. Jira) und PLM-Systeme integriert werden. Darauf aufbauend soll die KI nicht nur Testbeschreibungen, sondern direkt ausführbare Test-Skripte im Keyword-Driven-Ansatz erstellen. Diese könnten dann automatisch in einer CI/CD-Pipeline auf Simulationsumgebungen (Software-in-the-Loop) ausgeführt werden. Eine weitere Vision ist, dass die KI ihre eigenen Skripte analysiert und optimiert (LLM as a judge). Doch auch in dieser Zukunftsvision bleibt eine Konstante, wie Alexander betont: Der Mensch als letzte Instanz der Freigabe und Kontrolle.

## Praktische Schritte: Ein KI-Testsystem im regulierten Umfeld aufbauen

Aus den Erfahrungen von Alexander und seinem Team lassen sich konkrete Handlungsempfehlungen für andere ableiten, die ähnliche Projekte planen:

1. **Definiere den Business Case klar:** Beginne nicht mit der Technologie, sondern mit dem Problem. Welcher manuelle, zeitaufwendige Prozess soll unterstützt werden? Bei Fresenius war es die Reduzierung der manuellen Testfallerstellungszeit.
2. **Setze auf eine modulare Architektur:** Die KI-Welt entwickelt sich rasant. Baue dein System so, dass du die zugrundeliegenden LLMs einfach austauschen kannst, ohne alles neu entwickeln zu müssen.
3. **Schaffe eine eigene Wissensbasis (RAG):** Verlasse dich niemals auf das allgemeine Wissen eines öffentlichen LLM. Sammle deine eigene, verifizierte Dokumentation in einem RAG-System, um Halluzinationen zu vermeiden und die Ergebnisse auf deine Domäne zuzuschneiden.
4. **Stelle Nachvollziehbarkeit sicher:** Protokolliere jeden Schritt des Generierungsprozesses. Es muss jederzeit klar sein, auf welcher Datenbasis die KI ihre Schlussfolgerungen zieht. Dies ist nicht nur für die Regulatorik, sondern auch für das Vertrauen der Nutzer:innen entscheidend.
5. **Implementiere das Man in the Middle-Prinzip:** Definiere von Anfang an, dass die KI ein Assistent ist. Etabliere einen klaren Review- und Freigabeprozess, bei dem die menschliche Expertise die letzte Instanz ist. Dies ist der Schlüssel zur Umgehung der komplexen Tool-Validierung.
6. **Starte mit einem Proof of Concept:** Beginne klein und sammle Feedback von echten Anwender:innen. Ein PoC hilft dabei, die technischen Hürden und die Akzeptanz im Team frühzeitig zu erkennen und die Lösung iterativ zu verbessern.

---

 version="1.0" encoding="UTF-8"?
      .st0 {
        fill: #010101;
      }

      .st1 {
        fill: #b0c0b3;
      }

      .st2 {
        fill: #3b3a3b;
      }

      .st3 {
        fill: #3a3a3a;
      }

      .st4 {
        fill: #5e7185;
      }

      .st5 {
        fill: #f9eddd;
      }

      .st6 {
        fill: #000100;
      }

      .st7 {
        fill: #aebeb3;
      }

      .st8 {
        fill: #fefefe;
      }

      .st9 {
        fill: #7f93a8;
      }

      .st10 {
        fill: #f8f0df;
      }

      .st11 {
        fill: #fbf0df;
      }

      .st12 {
        fill: #afbfb2;
      }

      .st13 {
        fill: #f7eedd;
      }

      .st14 {
        fill: #fdfdfd;
      }
                                                                                   Botcaster

  **Zusammengefasst von Anja Schirwinski**

Ich beschäftige mich beruflich wie privat mit Künstlicher Intelligenz - von konkreten Tools im Arbeitsalltag bis zu den größeren Fragen, die dabei aufkommen. Viele der Themen, die in Podcasts besprochen werden, begegnen mir in Projekten immer wieder. Deshalb fasse ich hier die für mich interessantesten Podcastfolgen zusammen und ordne sie aus der Praxis ein.

[Mehr über das Projekt Botcaster](/ueber-uns)

##  Themen

 - [  Testen und Qualität  ](/podcasts/themen/testen-qualitaet)
- [  Regulierung und Datenschutz  ](/podcasts/themen/regulierung-datenschutz)

**Hinweis:** *Diese Zusammenfassung wurde mit Hilfe von KI aus dem Transkript der Podcast-Episode generiert.*

Alle Inhalte auf Botcaster beruhen auf öffentlich zugänglichen Podcasts rund um Künstliche Intelligenz. Wir fassen die Episoden nach bestem Wissen zusammen, übernehmen jedoch keine Gewähr für Vollständigkeit, Aktualität oder Richtigkeit der Inhalte. Die Rechte an den Original-Podcasts und -Inhalten liegen ausschließlich bei den jeweiligen Urheber:innen.

         ## Shownotes

   In dieser Episode spreche ich mit Alexander Frenzel über KI-gestützte Testfallerzeugung im streng regulierten Umfeld. Klingt nach Widerspruch. Ist es nicht. Alex zeigt, wie ein Assistenzsystem mit One-Click-Generator, modularen Modellen und einem RAG-System Tests aus Requirements ableitet. Statt Fragen zu stellen, nutzt er das Hyde-Prinzip: Behauptung aufstellen, Belege aus der eigenen Dokumentation finden. So bleiben Nachvollziehbarkeit, Logging und der Human in the Loop erhalten.