Testerzeugung und QA-Automatisierung

Die meisten Teams wissen, dass ihre Testsuiten zu dünn, zu langsam oder zu fragil sind, aber das Schreiben und Pflegen von Tests ist undankbare Arbeit, die gegen die Lieferung neuer Funktionen verliert. LLMs lesen Code und Anforderungen, schreiben Unit-, API- und End-to-End-Tests, führen sie aus, verwerfen, was nicht kompiliert oder keinen Mehrwert bringt, und reparieren Tests, wenn sich die Anwendung ändert. Der Gewinn sind nicht „Tests umsonst“, sondern ein günstigerer Weg zu einem Sicherheitsnetz, vorausgesetzt, jeder erzeugte Test wird durch Ausführung verifiziert und Menschen prüfen, was er tatsächlich behauptet.

Problem & Nutzen

• Heute: Entwickler schreiben Unit-Tests von Hand, QA-Ingenieure skripten UI-Tests (Selenium, Playwright, Cypress) und führen vor Releases Regressionsprüfungen manuell durch. Altsysteme haben oft gar keine Tests, was Refactoring und Modernisierung blockiert (CODE-005, CODE-021). UI-Tests brechen bei jeder Änderung am Layout, und die Wartung verschlingt einen großen Teil der QA-Kapazität.
• KI-Nutzen: Testabdeckung für ungetesteten Code anstoßen, Randfälle erzeugen, die Menschen übersehen, aus Anforderungen oder aufgezeichneten Nutzerabläufen ausführbare Tests machen, Locators selbst reparieren, instabile Fehlschläge sichten und explorative Tests mit Agenten durchführen.
• Belege: Die TestGen-LLM-Studie von Meta berichtete, dass in der Auswertung bei Instagram und Facebook ein Teil der erzeugten Testklassen die Abdeckung verbesserte und dass Ingenieure die Mehrheit der ihnen im Produktivbetrieb gezeigten Tests akzeptierten; die zentrale Entwurfsidee war eine automatisierte Filterkette (baut, besteht, besteht zuverlässig, erhöht die Abdeckung) [1]. Benchmarks wie SWT-Bench zeigen, dass die Erzeugung von Reproduktionstests (zuerst fehlschlagend, nach der Korrektur bestehend) für reale Issues machbar, aber bei Weitem nicht gelöst ist [2]. Betrachten Sie Produktivitätsversprechen der Anbieter als ungeprüft, bis Sie sie am eigenen Code gemessen haben.

Varianten

• Erzeugung von Unit-Tests für vorhandenen Code (JVM, .NET, Python, TypeScript), oft in der IDE oder per PR-Bot.
• Testgetriebene Agenten: Coding-Agenten (CODE-002) schreiben zuerst den fehlschlagenden Test, dann die Korrektur.
• End-to-End-/UI-Tests: Browser-Tests in natürlicher Sprache oder agentengesteuert, selbstreparierende Locators, visuelle Regression mit VLMs; Testautomatisierung für Mobilgeräte.
• Testwartung & Sichtung instabiler Tests: Reparatur defekter Selektoren, Gruppierung von CI-Fehlern nach Ursache.

So funktioniert es

1. trigger (PR / nightly / requirements change)
2. context build (diff, covered/uncovered lines, related tests, specs, repo conventions)
3. LLM / agent proposes tests (unit, API, E2E)
4. automatic filter chain: compiles
5. runs
6. passes repeatedly (flakiness)
7. adds coverage
8. kills new mutants (mutation testing)
9. matches style/lint
10. failures fed back to the LLM for repair (bounded loop)
11. PR comment or commit with tests + coverage/mutation delta
12. human review (assertions meaningful? spec-conformant?)
13. merge

• Erzeugung: ein codefähiges LLM mit Repository-Kontext; agentische Varianten führen den Test-Runner aus und iterieren. UI-Agenten nutzen den Accessibility-Baum von Playwright (und optional Screenshots über ein VLM) statt fragiler Pixelkoordinaten.
• Die Verifikation ist der Kern: Abdeckung allein ist ein schwaches Signal; Mutationstests (Stryker, PIT, mutmut) prüfen, ob Tests eingebrachte Fehler tatsächlich erkennen. Ohne sie neigen LLMs dazu, Tests zu schreiben, die behaupten, was der aktuelle (möglicherweise fehlerhafte) Code tut.
• Mensch-in-der-Schleife (Human-in-the-Loop): Prüfende entscheiden, ob Zusicherungen das beabsichtigte Verhalten abbilden, geben Merges frei und verantworten das Test-Orakel. Tests, die aus dem zu testenden Code abgeleitet sind, können eine falsche Spezifikation nicht finden.

Datenaufbereitung

Die Testerzeugung stützt sich auf Quellcode, vorhandene Tests und Abdeckungsberichte, Anforderungen oder User Stories (Jira, Confluence, Word), OpenAPI-Spezifikationen und CI-Protokolle. Typische Lücken: Anforderungen, die nur als Fließtext oder in den Köpfen existieren, veraltete API-Spezifikationen, keine Messung der Abdeckung, instabile Tests, Testumgebungen, die sich von der Produktion unterscheiden, und aus der Produktion kopierte Testdaten mit echten Kunden- oder Mitarbeiterdatensätzen.

Vorbereitungsschritte: (1) OpenAPI-Spezifikationen erzeugen oder aktualisieren und unter Versionskontrolle stellen; (2) die Ausgangsabdeckung und den Mutation Score messen, damit Fortschritt sichtbar wird; (3) zentrale Anforderungen als testbare Abnahmekriterien neu formulieren, siehe PREP-014; (4) synthetische oder pseudonymisierte Testdaten aufbauen, niemals rohe Produktivdaten, siehe PREP-022; (5) eine Testumgebung mit vorbelegten Daten und stabilen Selektoren (Test-IDs) für UI-Tests stabilisieren; (6) gute vorhandene Tests als Beispiele und Vorlagen sammeln, siehe PREP-016, sowie eine Menge bekannter Fehler als Evaluierungsfälle (PREP-018). Frühere Fehlerberichte sind eine Quelle für Labels (PREP-020).

Aufwandsanteil: mittel, etwa 25 bis 35 Prozent, überwiegend Arbeit an Testdaten und Umgebung.

Umsetzungswege

Welcher Weg für wen

• KMU: B - Tests müssen zur eigenen Codebasis, zum Test-Framework und zur CI passen; Coding-Assistenten (siehe CODE-001) plus ein API-basiertes Erzeugungsskript decken dies günstiger ab als QA-Nischenprodukte.
• Großunternehmen: B - Cloud-APIs in EU-Regionen in Kombination mit der vorhandenen Testplattform und CI geben bei großen Suiten Kontrolle über Testdaten, Kontingente und Nachvollziehbarkeit.
• Entwickler: C - Coder-Modelle mit offenen Gewichten mit Playwright und einem lokalen Agenten erzeugen und reparieren Tests offline ohne Kosten pro Token.

Weg A — Kaufen (Standardsoftware)

• Unit-/PR-Ebene: Diffblue Cover (UK; Java, nutzt Reinforcement Learning statt nur Prompting eines LLM, Tests werden nur behalten, wenn sie kompilieren und bestehen), Qodo (Israel; Testerzeugung in IDE und PR, Open-Source-Variante Qodo Cover), GitHub Copilot, JetBrains AI Assistant (tschechischer Anbieter), Cursor, Amazon Q Developer.
• End-to-End-/QA-Plattformen: mabl, Tricentis (Testim, Tosca; in Österreich gegründet), Katalon, testRigor, Functionize, SmartBear, KI-Funktionen von BrowserStack und Sauce Labs, Applitools (visuelle KI). Prüfen: EU-Datenresidenz, wie Testartefakte und Screenshots (können personenbezogene Daten enthalten) gespeichert werden, CI-Integration, exportierbare Tests (Abhängigkeit von proprietären Formaten vermeiden).
• A wählen, wenn: einem Team die Kapazität fehlt, eigene Werkzeuge zu bauen, und der Stack zu den Stärken eines Anbieters passt.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlene Standardwahl)

• Modelle: führende Coding-Modelle (Claude, GPT, Gemini) oder Mistrals Codestral/Devstral (EU-Anbieter) über Endpunkte in EU-Regionen; für knifflige Randfälle Reasoning-Modelle nutzen.
• Agenten: Die offiziellen Test Agents von Playwright und der Playwright-MCP-Server (Planer, Generator, Reparierer) lassen einen Agenten eine Anwendung erkunden und Playwright-Tests ausgeben [3]; Coding-Agenten wie Claude Code oder der Agentenmodus von Copilot führen Testbefehle in CI-Sandboxes aus.
• Pipeline: Job in GitHub Actions / GitLab CI, der das Modell aufruft, die obige Filterkette ausführt und JaCoCo/coverage.py/Istanbul für die Abdeckung sowie Stryker/PIT für den Mutation Score nutzt [4].
• B wählen, wenn: Sie Kontrolle über Prompts, Filter und Repository-Konventionen zu moderaten Kosten wollen.

Weg C — Selbst betreiben (Open Source)

• Modelle: Code-Modelle mit offenen Gewichten, z. B. Qwen3-Coder, Devstral, DeepSeek-Coder-V2 und Modelle der Codestral- Klasse über vLLM oder Ollama; HW2 betreibt quantisierte Modelle bis 30B für Unit-Tests, HW3 größeres agentisches Coding.
• Werkzeuge: Qodo Cover (Open Source, Schleife im Stil von TestGen-LLM) [5], Playwright, Pynguin/EvoSuite (suchbasierte Testerzeugung, kein LLM nötig), Schemathesis und RESTler (API-Fuzzing), Stryker, PIT, mutmut, SonarQube Community für Qualitätsschranken.
• C wählen, wenn: der Quellcode die eigenen Räumlichkeiten nicht verlassen darf (Rüstungszulieferer, Finanzwesen, Gesundheitswesen).

Weg D — Eigenes Training

Selten gerechtfertigt. Feintuning auf den eigenen Testkonventionen des Unternehmens und früher akzeptierten Tests kann die Stilpassung verbessern und Nacharbeit verringern; RL gegen Belohnungen aus Testausführung/Mutation ist eine Forschungsfront. Erfordert Tausende geprüfter (Code, Test)-Paare und eine strenge Evaluierungsdisziplin.

Stand der Technik (2026)

• Agentisches Schreiben von Tests ist Standard: Agenten führen den Code aus, lesen Fehlschläge und iterieren; die native Agentenunterstützung in Playwright und IDE-Agenten machte die E2E-Erzeugung in natürlicher Sprache praxistauglich [3].
• Erst filtern, dann akzeptieren (Muster von TestGen-LLM) ist der bewährte Weg, mit halluzinierten Tests umzugehen [1]; der Mutation Score wird zunehmend statt der Zeilenabdeckung als Akzeptanzkriterium verwendet.
• Tests zur Reproduktion von Issues (SWT-Bench) wurden zu einem Standardbestandteil von Coding-Agenten-Pipelines, weil ein erst fehlschlagender, dann bestehender Test der beste Beleg dafür ist, dass eine Korrektur funktioniert [2].
• Grenzen und Fehlerbilder: tautologische Zusicherungen, übermäßiges Mocking, Tests, die Fehler festschreiben, instabile erzeugte Tests (Timing, Reihenfolge), aufgeblähte Abdeckung, schwache Leistung bei komplexer Fachlogik, Nebenläufigkeit und nicht deterministischen Oberflächen; ohne Spezifikation kein Test-Orakel; Kosten der Agentenschleifen in der CI.

Gemeinsame Bausteine & Kombinationen

• Gleicher Technologie-Stack (llm-code + agent-framework): CODE-001 IDE-Assistenten, CODE-002 Coding-Agenten (Tests als Verifikation), CODE-003 KI-Code-Review, CODE-014 Fehlerreproduktion und -behebung, CODE-021 Aktualisierung von Abhängigkeiten und Refactoring (Tests als Sicherheitsnetz), CODE-005 Modernisierung von Altsystemen (Charakterisierungstests).
• Browser-Agenten (Computer-Use): CODE-017 Test der Barrierefreiheit, CODE-024 Playtesting von Spielen.
• Evaluierung von KI-Anwendungen: CODE-018 für Evaluierungen von LLM-Anwendungen; SEC-014 für adversariale Tests von KI-Systemen.
• Sicherheitskritisch: CODE-020, CODE-019 (Testbenches und Verifikation) erfordern qualifizierte Werkzeugketten.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; SaaS-Preise pro Arbeitsplatz oder pro Testlauf (auf den Anbieterseiten prüfen).
• Weg B: 2–6 Wochen für eine CI-Pipeline mit Filtern und Berichten; die Token-Kosten wachsen mit dem Repository- Kontext und der Zahl der Reparaturiterationen.
• Kennzahlen: Zweigabdeckung (Branch Coverage) und Mutation Score bei geändertem Code, Anteil der von Prüfenden akzeptierten erzeugten Tests, Rate instabiler Tests, Stunden für Testwartung, durchgerutschte Fehler, CI-Dauer, Kosten je akzeptiertem Test, Zeit bis zur Reproduktion eines gemeldeten Fehlers.

Menschen & Veränderung

Beziehen Sie die QA-Leitung oder Entwicklungsleitung als Prozessverantwortliche, Entwickler und Tester als tägliche Nutzer, die IT für Testumgebungen und CI, die Informationssicherheit und die oder den Datenschutzbeauftragte(n) ein, weil Testdaten und aufgezeichnete UI-Sitzungen personenbezogene Daten enthalten können, sowie die Geschäftsführung für das Ziel (Abdeckung, Release-Geschwindigkeit). Fachabteilungen liefern Abnahmekriterien; Datenverantwortliche geben Testdaten frei (GUIDE-003).

Betriebsrat: in der Regel nein, weil die Werkzeuge Code und Testergebnisse analysieren, nicht Personen. Relevant wird es, wenn die Produktivität von Testern je Person berichtet wird oder wenn Sitzungsaufzeichnungen Beschäftigte erfassen; dann greift § 87 Abs. 1 Nr. 6 BetrVG. Informieren Sie den Betriebsrat trotzdem rechtzeitig nach § 90 Abs. 1 Nr. 3, weil sich die Arbeitsabläufe beim Testen ändern. Öffentlicher Dienst: Personalrat.

KI-Kompetenz: Fördern Sie die Beschäftigten nach Art. 4 KI-Verordnung (AI Act) mit Schulungen zur Prüfung erzeugter Tests (behaupten sie das richtige Verhalten oder spiegeln sie nur den Code?) und zu den Grenzen agentischer UI-Tests (GUIDE-006). Führen Sie einen Pilot für einen Dienst oder einen UI-Ablauf über vier bis sechs Wochen durch und vergleichen Sie gefundene Fehler, Wartungsaufwand und Abdeckung (GUIDE-009). Häufige Sorgen: Manuelle Tester fürchten um ihre Arbeitsplätze, Entwickler misstrauen trivialen Tests. Positionieren Sie Tester als Prüfende und Strategen, halten Sie Menschen für die Teststrategie und Release-Entscheidungen verantwortlich und prüfen Sie erzeugte Tests wie normalen Code (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko für Entwicklerwerkzeuge; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Nicht nach Art. 5 verboten. Ist die getestete Software selbst ein Hochrisiko-System oder ein Medizinprodukt (Anhang III / MDR), entbinden KI-erzeugte Tests nicht von den Pflichten zu Konformität, Validierung und Dokumentation; bewahren Sie qualifizierte Verifikationsnachweise auf.
• DSGVO: Speisen Sie keine Produktivdaten in Prompts oder Testdaten ein; verwenden Sie synthetische oder anonymisierte Daten. Screenshots und Traces aus E2E-Läufen können personenbezogene Daten enthalten; das Senden von Code an APIs in Drittländern erfordert einen AVV und eine Grundlage für die Übermittlung. Bevorzugen Sie EU-Regionen oder den eigenen Betrieb.
• Sicherheit und geistiges Eigentum: Geheimnisse in Repositories, Prompt Injection über Code-Kommentare oder von UI-Agenten besuchte Webseiten, Lizenzverunreinigung; Agenten in Sandboxes mit minimalen Rechten und ohne Produktiv-Zugangsdaten ausführen.
• Gegenmaßnahmen: ausführungsbasierte Filter, Mutationstests, verpflichtendes Review, Richtlinie für Testdaten, Audit-Log.

Erste Schritte

1. Ausgangsbasis: Abdeckung, Mutation Score (für ein Modul), Rate instabiler Tests und QA-Stunden je Release.
2. Ein IDE-/PR-Werkzeug (Weg A oder B) an einem Modul mit einigen Tests pilotieren; verlangen, dass jeder akzeptierte Test kompiliert, zuverlässig besteht und neue Mutanten erkennt.
3. Vor jedem Refactoring oder jeder Migration von Altsystemen Charakterisierungstests ergänzen.
4. Playwright-Agenten für 5–10 kritische Nutzerabläufe pilotieren und reinen Playwright-Code unter Versionskontrolle exportieren.
5. Eine Prüfcheckliste definieren (Bedeutung der Zusicherungen, Mocking, Datenschutz) und die Kennzahlen monatlich verfolgen.

Quellen

1. Alshahwan et al., Meta — Automated Unit Test Improvement using Large Language Models at Meta (TestGen-LLM) — https://arxiv.org/abs/2402.09171
2. Mündler et al. — SWT-Bench: Testing and Validating Real-World Bug-Fixes with Code Agents — https://arxiv.org/abs/2406.12952
3. Playwright — Test Agents documentation — https://playwright.dev/docs/test-agents
4. Stryker Mutator — mutation testing documentation — https://stryker-mutator.io/docs/
5. Qodo Cover (open source) — https://github.com/qodo-ai/qodo-cover
6. Diffblue Cover documentation — https://docs.diffblue.com/
7. PIT mutation testing for Java — https://pitest.org/
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj