Das eigentliche Problem: Testdokumentation als Ressourcenfalle
Ein Team entwickelt eine Steuerungssoftware für ein Medizingerät nach IEC 62304. Die eigentliche Implementierung — Algorithmus, Schnittstellen, Firmware-Integration — dauert vier Monate. Die Testdokumentation: noch einmal zwei Monate. Testfälle ableiten, Akzeptanzkriterien formulieren, Traceability-Matrix pflegen, Testergebnisse in prüffähige Berichte übersetzen. Alles manuell. Alles fehleranfällig. Alles vom Auditor gelesen.
Das gleiche Muster in der Avionik: DO-178C verlangt für DAL-A-Software eine lückenlose Abdeckung jeder Anforderung durch mindestens einen Testfall — mit dokumentiertem Ergebnis, verknüpft mit der Spezifikation, versioniert. Bei 800 Anforderungen bedeutet das in der Praxis Wochen manueller Arbeit vor jeder Zertifizierungsphase. ISO 26262 in der Fahrzeugelektronik ist nicht anders strukturiert.
Testdokumentation ist in regulierten Branchen keine optionale Qualitätssicherung. Sie ist Bestandteil der Zulassungsakte. Fehler oder Lücken dort blockieren den Go-Live — nicht die Bugs in der Software selbst.
Was KI konkret übernimmt
KI liest Anforderungsspezifikationen — in natürlicher Sprache, als strukturiertes Dokument oder direkt aus dem Anforderungsmanagement-Tool — und generiert daraus:
- Vollständige Testfälle mit Vorbedingungen, Eingaben, erwarteten Ergebnissen
- Negativtests und Grenzwertanalysen, die manuell regelmäßig übersehen werden
- Äquivalenzklassen und Partitionierungsanalysen
- Akzeptanzkriterien in einer für Auditoren lesbaren Form
- Traceability-Links: welcher Testfall deckt welche Anforderung ab
Die KI schreibt keinen ausführbaren Testcode — das bleibt Aufgabe des Entwicklungsteams in der jeweiligen Testumgebung. Sie erzeugt die Spezifikation: präzise genug, dass ein Ingenieur die Implementierung in wenigen Minuten abschließen kann.
Wie eine Ausgabe aussieht
Zur Verdeutlichung: Eine Anforderung aus einer medizinischen Softwarespezifikation — "Der Alarmmechanismus muss innerhalb von 500 ms auf einen kritischen Messwert reagieren" — erzeugt folgende Testfall-Struktur:
# Generierter Testfall — UC09 Demo ID: TC-042 Anforderung: REQ-ALM-07 Titel: Alarmauslösung bei kritischem Messwert — Antwortzeit Vorbedingung: - System aktiv, kalibriert, Normalbetrieb - Alarmschwelle konfiguriert auf 120 mmHg (systolisch) Testschritte: 1. Simuliere Messwert: 121 mmHg (über Schwelle) 2. Starte Zeitmessung (t0) 3. Warte auf Alarmausgabe (visuell + akustisch) 4. Stoppe Zeitmessung (t1) Erwartetes Ergebnis: - Alarm ausgelöst innerhalb (t1 - t0) <= 500 ms - Alarmart: CRITICAL, Code ALM-07 - Logeintrag mit Zeitstempel und Messwert erzeugt Negativtest (TC-042b): - Messwert 119 mmHg: kein Alarm erwartet - Messwert 120 mmHg (Grenzwert): Verhalten dokumentieren Traceability: REQ-ALM-07 → TC-042, TC-042b Standard: IEC 62304 §5.7 — Software Integration Testing
Dieser Output entsteht in Sekunden. Für ein Dokument mit 200 Anforderungen dauert der vollständige Durchlauf unter einer Stunde. Ein erfahrener Testingenieur braucht für dasselbe Ergebnis typischerweise zwei bis drei Arbeitstage.
Relevante Normen und was sie konkret fordern
IEC 62304 — Medizinische Software
Klasse B und C verlangen vollständige Softwareverifikation: Testfälle für jede Software-Einheit, Integrationstests für alle Schnittstellen, Systemtests gegen die Anforderungsspezifikation. Die KI liest die Spezifikation und ordnet jeden Testfall automatisch der richtigen Klasse zu.
DO-178C — Avionik
DAL A bis C erfordern strukturelle Abdeckungsanalyse (Statement, Decision, MC/DC Coverage). KI generiert Testfälle, die auf diese Abdeckungsziele ausgerichtet sind — inklusive der häufig vergessenen Deactivated-Code-Nachweise.
ISO 26262 — Funktionale Fahrzeugsicherheit
ASIL-Einstufungen bestimmen den erforderlichen Testaufwand. ASIL D verlangt unabhängige Tests und vollständige MC/DC-Abdeckung. Die KI berücksichtigt die ASIL-Stufe einer Anforderung und passt Tiefe und Art der Testfälle entsprechend an.
KI-gestütztes Code-Review für sicherheitskritische Systeme
Neben der Testfallgenerierung übernimmt KI eine zweite Funktion im QA-Prozess: die strukturierte Überprüfung von Quellcode gegen definierte Codierstandards.
Für sicherheitskritische C- oder Ada-Entwicklung — etwa nach MISRA C:2012 oder JSF++ — analysiert die KI jeden Pull Request und markiert:
- Verstöße gegen MISRA-Regeln mit Regelreferenz und Erklärung
- Uninitialisierte Variablen, implizite Typkonvertierungen, unbegrenzte Rekursion
- Fehlende Fehlerpfade bei sicherheitskritischen Funktionsaufrufen
- Abweichungen vom projekteigenen Coding-Standard
Das Ergebnis ist kein Ersatz für formale statische Analyse-Tools wie Polyspace oder LDRA. Es ist eine erste Filterschicht, die offensichtliche Verstöße herausfiltert, bevor der Review durch erfahrene Ingenieure beginnt. In der Praxis reduziert das die Review-Zeit pro Merge Request um 40 bis 50 Prozent.
Auditfähige Dokumentation als direktes Ergebnis
Was KI nicht nur generiert, sondern strukturiert ausgibt, ist der entscheidende Unterschied zu einfachen Automatisierungsansätzen. Jeder Testfall enthält:
- Die Referenz auf die zugrundeliegende Anforderung (ID, Version, Dokument)
- Den angewandten Testtyp (Blackbox, Grenzwert, Negativtest)
- Den Normenbezug (Paragraph und Anforderungsklasse)
- Das erwartete Ergebnis in prüfbarer, nicht interpretierbarer Formulierung
Die Ausgabe lässt sich direkt in Anforderungsmanagement-Systeme exportieren — Polarion, DOORS, Jama, Confluence — oder als PDF-Testplan für die Zulassungsakte aufbereiten. Der Auditor sieht ein vollständiges, rückverfolgbares Dokument. Nicht ein halbfertiges Spreadsheet aus verschiedenen Quellen.
Deployment: on-premise, keine externe Datenübertragung
Anforderungsspezifikationen in regulierten Branchen sind vertraulich. Sie beschreiben Sicherheitsfunktionen, sicherheitskritische Schwellwerte, proprietäre Algorithmen. Das Material verlässt die eigene Infrastruktur nicht.
AlpiType betreibt KI-Modelle ausschließlich auf der Infrastruktur des Kunden — on-premise, air-gapped-fähig, ohne Verbindung zu US-Cloud-Diensten. Kein API-Call zu OpenAI. Kein Dokument, das den Perimeter verlässt. Für Verteidigung, Luftfahrt und Medizin ist das keine Option — es ist die Voraussetzung.
Die KI-Modelle laufen auf Ihrer Hardware, in Ihrem Rechenzentrum, unter Ihrer Kontrolle. Wir installieren, konfigurieren und übergeben — ohne Abhängigkeit von externen Diensten.
Ergebnis in der Praxis
Ein Team, das bislang drei Wochen für die Testfalldokumentation eines Release-Zyklus aufgewendet hat, schließt denselben Schritt in drei bis vier Tagen ab. Die Testabdeckung steigt — weil KI keine Anforderungen übersieht und Grenzwertfälle konsequent ausleitet. Die Qualität der Dokumentation ist konsistenter, weil kein menschliches Ermüden zu inkonsistenten Formulierungen führt.
Das ist keine Theorie. Es ist das Ergebnis aus Produktionssystemen in regulierten Branchen, die wir aufgebaut und übergeben haben. Die Ingenieure, die vorher Testfälle tippt haben, arbeiten jetzt an der Software.
