AI-native Testing-Tools in regulierten Branchen — warum Keyword-Driven heute nicht ersetzbar ist
von Rainer Haupt
TL;DR: AI-native Testing-Tools wie testRigor, mabl und Virtuoso können Keyword-Driven Frameworks für Compliance-kritische Testausführung in regulierten Branchen heute nicht ersetzen. Das Kernproblem ist strukturell, nicht produktreif: Self-Healing ist nicht-deterministisch und kollidiert mit FDA, ISO 26262, DO-178C, IEC 62304 und DORA. Keyword-Driven Frameworks liefern Determinismus, Reproduzierbarkeit und nachvollziehbares Change Management by Design. Mit ISO/IEC/IEEE 29119-5:2024 als Standard-Vokabular wächst die Lücke weiter, statt sich zu schliessen.
Lesedauer ca. 13 Min · Stand: 2026-04
Die Versprechen der KI-Augmented-Testing-Vendor klingen nach Effizienz: Tests in natürlicher Sprache schreiben, Selektoren heilen sich selbst, das Tool generiert Testfälle aus User Stories. Für nicht-regulierte Web-Anwendungen sind das reale Vorteile. In Branchen, in denen jeder Testlauf rechtlich nachvollziehbar dokumentiert sein muss — Pharma, Medizintechnik, Automotive, Aerospace, Banken — ändert sich die Bewertung fundamental. Diese Analyse vergleicht die drei prominentesten AI-native Tools mit Keyword-Driven Frameworks entlang der konkreten Anforderungen, die FDA, ISO 26262, DO-178C, IEC 62304 und DORA stellen.
Compliance-Claims sind dünn und meist aspirativ
| Tool | Zertifizierungen | FDA-Claim | On-Premise | Regulierte Kunden |
|---|---|---|---|---|
| testRigor | ISO 27001, SOC 2 Type II, HIPAA, GDPR | 21 CFR Part 11 Reporting-Support (nicht selbst validiert) | im Enterprise-Plan | Medrio (eClinical / Pharma) |
| mabl | SOC 2 Type II | keine | nein, Cloud-only | ToS verbietet PHI und PCI-Daten |
| Virtuoso | SOC 2 Type II | erwähnt 21 CFR Part 11 im Marketing, keine Zertifizierung | nein, Cloud-only (AWS EU) | letzte Finanzierung November 2021, Bewertung rund USD 5.1 Mio. |
Drei Befunde liegen quer durch die Tabelle:
- Kein Tool hat eine formale Tool-Qualifizierung nach ISO 26262-8 Clause 11 oder DO-330.
- Kein Tool liefert IQ/OQ/PQ-Validierungspakete für GxP-Umgebungen.
- Kein Tool hält IEC 62304-Compliance-Claims.
Zum Vergleich: deterministische Tools wie Parasoft C/C++test tragen TÜV-SÜD-Zertifizierung für IEC 62304. Diese Zertifizierungslücke ist kein Detail, sondern ein struktureller Unterschied — und sie hat einen technischen Grund.
Self-Healing versus Determinismus — der fundamentale Konflikt
Was die Regulatoren verlangen:
- FDA (Software Validation) — Anforderungen müssen «consistently fulfilled» werden.
- ISO 26262 — Tools müssen «comply with specified requirements» durch Validierungstests nachweisen.
- DO-178C — nachweisbare bidirektionale Traceability an vier Stellen.
- GAMP 5 — Validierung basiert auf Kontrolle, Reproduzierbarkeit, Traceability.
Was die AI-Tools tun:
| Tool | Self-Healing-Ansatz | Problem für Regulierung |
|---|---|---|
| mabl | 30+ Attribute pro UI-Element, GenAI für semantisches Matching (z. B. «Confirm» → «Approve»). Bei Plan-Run automatisch angewendet, ohne User-Approval. | Derselbe Test kann verschiedene Interaktionspfade über Runs hinweg ausführen. |
| Virtuoso | rund 95 % Self-Healing-Accuracy. Eigene Doku: «If your test step can’t be healed with confidence… the test step will fail.» | 5 % Unsicherheitsrate ist inkompatibel mit Safety-Critical Testing. |
| testRigor | löst Elemente aus Endnutzer-Perspektive (sichtbare Labels). Self-Healing optional, markiert mit «fixed-by-ai» Tags, Rollback möglich. | das stabilste der drei — die DOM-Interpretation variiert dennoch dynamisch. |
Die FDA unterscheidet explizit «locked» Algorithmen (selbes Ergebnis jedes Mal) von «adaptive» Algorithmen. Alle drei Tools fallen in die zweite Kategorie. PMC-Forschung zu Pharma-GMP formuliert es nüchtern: «regulatory agencies remain cautious due to the non-deterministic nature of AI/ML algorithms.»
Change Control — wo AI-Tools am kritischsten versagen
Jede Änderung an einem validierten Test muss in regulierten Umgebungen durch formales Change Control: dokumentierter Change Request, Risikobewertung, Genehmigung durch qualifiziertes Personal, Implementierung, Verifizierung. Diese Sequenz ist unter FDA 21 CFR Part 11, GAMP 5, ISO 26262 und DO-178C nicht verhandelbar.
AI-Tools machen das Gegenteil — «change first, review later»:
| Tool | Verhalten | Regulatorisches Problem |
|---|---|---|
| mabl | Auto-Heal plus automatisches Element-Model-Update bei bestandenem Plan-Run. Review nachträglich auf der Insights-Seite. | Kein Approval-Gate, keine Dual-Autorisierung, kein formaler CR-Workflow. |
| Virtuoso | manuelle Akzeptanz von Self-Heals nötig («click of a button»). Revisions-History vorhanden. | Keine formale Change Impact Analysis, keine elektronischen Signaturen. |
| testRigor | «fixed-by-ai»-Tags und Rollback-Möglichkeit. | Sichtbarkeit ja — aber kein Pre-Execution-Approval-Workflow. |
Die FDA-PCCP-Guidance 2025 für AI/ML formuliert es noch schärfer: selbst genehmigte AI-Adaptionen müssen vorab spezifizieren, was sich ändert, wie validiert wird, welche Akzeptanzkriterien gelten und wie der Rollback aussieht. Self-Healing-Tests, die ad hoc adaptieren, erfüllen dieses Framework strukturell nicht.
Standardisierte Keyword-Vokabulare als unangreifbarer Vorteil
ISO/IEC/IEEE 29119-5:2024 (zweite Ausgabe, Dezember 2024) formalisiert Keyword-Driven Testing mit standardisiertem Vokabular, hierarchischen Keyword-Strukturen und einem gemeinsamen Datenaustauschformat für Tool-Interoperabilität. Robot Frameworks keyword-getriebene Architektur deckt sich strukturell mit dem in 29119-5 beschriebenen Modell — eine de-facto-Umsetzung, ohne dass die Robot Framework Foundation einen formellen Konformitäts-Claim erhebt.
Die Traceability-Kette in regulierten Branchen sieht damit so aus:
Requirements → Standardisierte Keywords → Test-Spezifikationen → Execution Logs → Ergebnisse
↑ ↑ ↑ ↑ ↑
Jira / ALM 29119-5-orientiertes .robot-Files output.xml report.html
Vokabular (Git-versioniert) (Step-by-Step) (Audit-ready)Im direkten Vergleich:
| Fähigkeit | Robot Framework | testRigor | mabl | Virtuoso |
|---|---|---|---|---|
| Natives RTM | [Tags] REQ-001 pro Test | nein, nur via TestRail / Jira / Xray | nein | natives Requirements-Feature |
| Execution-Logs | output.xml und log.html mit Step-by-Step-Traces, Timestamps, Screenshots | PDF / Word / CSV-Reports | Screenshots + Schritte | Revisions-History |
| Elektronische Signaturen | nein (über CI/CD-Infrastruktur) | nein | nein | nein |
| Versionskontrolle | .robot = Plain Text → Git-nativ | proprietäre Plattform | Cloud-basiert | Cloud-basiert |
| Change-History / Diff | Standard Git Diff | Audit Trail (seit April 2023) | limitiert | Revisions-History |
Vendor Lock-in als existenzielles Risiko
Produkt-Lebenszyklen in regulierten Branchen sind lang:
- Medizinprodukte: 10–30+ Jahre
- Automotive ECUs: 15–25 Jahre
- Pharma: Test-Evidenz für Produktlebensdauer plus Jahre aufbewahren
- Aerospace: Zertifizierungsdaten für Flugzeug-Lebensdauer (30+ Jahre)
Was passiert, wenn der Tool-Vendor in dieser Zeit verschwindet, gekauft wird oder die Plattform dreht? Die Export-Möglichkeiten der drei Tools:
| Tool | Export | Bewertung |
|---|---|---|
| testRigor | kein Export zu Selenium, Playwright, Cypress oder Standard-Sprachen | totaler Lock-in |
| mabl | Export via CLI zu Playwright (TS), Selenium IDE, JSON, CSV | verlustbehaftet — kein Auto-Heal, keine Visual Tests, keine Flows |
| Virtuoso | behauptet «various formats» ohne Spezifikation | proprietäres NL-Format, schwer portierbar |
| Robot Framework | Plain Text, Apache 2.0, Foundation-backed, kein Vendor | unbegrenzt wartbar |
Für DORA im Finanzsektor bekommt das Konzentrationsrisiko zusätzliche regulatorische Bedeutung. DORA Third-Party Risk Management verlangt von Finanzunternehmen, das Konzentrationsrisiko bei kritischen ICT-Dienstleistern zu bewerten. Die Abhängigkeit von einem einzigen SaaS-Testing-Vendor für Compliance-kritische Testinfrastruktur ist exakt der Risikotyp, den DORA adressiert.
Datenschutz schliesst Cloud-only-Tools für viele Szenarien aus
| Anforderung | testRigor | mabl | Virtuoso |
|---|---|---|---|
| On-Premise | im Enterprise-Plan | nein | nein |
| Air-Gapped Deployment | unklar | nein | nein |
| PHI-Verarbeitung erlaubt | ja (HIPAA) | nein, ToS verbietet es explizit | unklar |
| PCI-Daten erlaubt | unklar | nein, ToS verbietet es explizit | unklar |
| EU-Datenresidenz | unklar | nein | ja (AWS EU) |
mabl und Virtuoso sind damit für Healthcare, Finanz- und Verteidigungsanwendungen architektonisch inkompatibel — unabhängig von der KI-Qualität.
Nuanciertes Fazit
Die klare Aussage zuerst: AI-native Testing-Tools können Keyword-Driven Frameworks für Compliance-kritische Testausführung in regulierten Branchen heute nicht ersetzen. Aber nicht alles in einer regulierten Organisation hat denselben Compliance-Anspruch:
| Szenario | AI-Tools möglich? | Empfehlung |
|---|---|---|
| Safety-Critical Tests (ASIL D, SIL 3/4) | nein | deterministische Keywords, formal qualifiziert |
| GxP-Validierung (IQ / OQ / PQ) | nein | Keyword-Driven mit Audit-Trail |
| Compliance-relevante Regressionstests | nur mit deaktiviertem Self-Healing | testRigor mit AI-Features off + On-Premise — denkbar |
| Low-Risk Smoke- und explorative Tests | möglich | AI-Tools als Ergänzung neben validiertem Kern |
| Nicht-regulierte Subsysteme | ja | AI-Tools für Effizienz sinnvoll |
Unter den drei Tools kommt testRigor architektonisch am nächsten an die Compliance-Anforderungen heran: kein Locator-basiertes Testing, Self-Healing optional und deaktivierbar, On-Premise-Option, HIPAA-zertifiziert. Mit deaktivierten AI-Features ist es allerdings im Wesentlichen ein Natural-Language-Keyword-Layer — was den AI-Mehrwert weitgehend aufhebt.
Die regulatorische Landschaft entwickelt sich. Das FDA-PCCP-Framework, GAMP 5 in der zweiten Auflage und die in Entwicklung befindliche ISO 29119 Part 11 für KI-basierte Systeme erkennen AI/ML als Realität an. Sie fügen aber Anforderungen hinzu, statt Determinismus-Erwartungen zu lockern.
Wenn Organisationen an ISO/IEC/IEEE 29119-5 orientierte standardisierte Keywords einsetzen, entsteht ein Gesamtpaket, das aus regulatorischer Sicht heute nicht ersetzbar ist:
- Jedes Keyword hat definierte Vor- und Nachbedingungen mit dokumentierten Outcomes.
- Keywords sind direkt auf Requirement-IDs mappbar.
- Plain Text wird Git-versionierbar — vollständiges Change Control inklusive.
- Deterministische Ausführung liefert identische Ergebnisse bei identischen Inputs.
- Vendor-unabhängig und über Lebenszyklen von 30+ Jahren wartbar.
- Audit-ready HTML-Reports ohne Zusatztools.
Die ehrliche Form dieser Aussage: AI-Augmented Testing hat seinen Platz in regulierten Branchen — als Ergänzung in den Bereichen, in denen die Compliance-Anforderungen schwächer sind. Als Ersatz für den validierten deterministischen Kern ist es heute keine tragfähige Option.
Quellen
- testRigor — 21 CFR Part 11 Compliance
- testRigor — AI-Based Self-Healing
- mabl — Customer Terms of Service
- mabl — GenAI Test Automation with Self-Healing
- Virtuoso QA — Product Features
- FDA — AI/ML in Software as Medical Device
- FDA — PCCP Guidance 2025 (Ballard Spahr summary)
- ISPE — GAMP 5 Guide, 2nd edition
- ISO/IEC/IEEE 29119-5:2024 — Keyword-Driven Testing
- Siemens — ISO 26262 Tool Qualification
- AFuzion — DO-178C and DO-330
- PMC — Regulatory Perspectives for AI/ML in Pharmaceutical GMP
- DORA — Compliance Overview (Vantagepoint)
- Robot Framework — User Guide
Sie evaluieren Test-Tooling für eine regulierte Umgebung oder bewerten ein bestehendes Setup gegen FDA, ISO 26262, DO-178C, IEC 62304 oder DORA? Im UTAA-Workshop ordnen wir die Compliance-Architektur projektspezifisch ein. Mehr zur Methode oder direkt anfragen.