Copilot spuckte 40 Tests in acht Minuten aus. 31 kompilieren. 22 bestehen auf CI. Die Zeilen-Coverage stieg von 41% auf 58%. Die Change fail rate in der Produktion hat sich nicht bewegt. Die Assertion in der Hälfte der Dateien ist assertNotNull(result). SAST im selben Pipeline hat 180 Findings, wovon zwölf echte CWE sind. Niemand hat ein Ticket für das Triage.
Das ist kein Problem des Modells. Das ist ein Orakelproblem. Testautomatisierung mit AI ohne Quality Gate sieht aus wie Codequalität. Es ist ein grüner Build auf dem aktuellen Verhalten, einschließlich des Fehlers. LLM weiß nicht, was hätte passieren sollen. Es weiß, was im Repo ist.
Unten ist eine Unterscheidung, die in den Briefings „wir suchen einen Tester mit AI“ fehlt: wann man einen SDET mietet (body leasing QA automation), und wann die Testpyramide und SAST einen Squad erfordern. Die Stundensätze haben wir separat aufgeschlüsselt: was IT body leasing im Jahr 2026 kostet. Hier berechnen wir, warum die Coverage von Copilot der teuerste Weg zu einem ruhigen Dashboard ist.
Ein Satz, der auf der Folie „AI testing“ fehlt
Ein Test, der besteht, beweist nichts. Ein Test, der fehlschlagen kann, beweist etwas. Meta auf Instagram und Facebook hat den LLM-Output nicht in den Main-Branch hochgeladen. Sie haben das hochgeladen, was den Filter bestanden hat: Build, stabiler Pass, messbarer Anstieg der Coverage, Akzeptanz des Ingenieurs. 25% der generierten Klassen erhöhten die Coverage. Der Rest fiel am Quality Gate durch. Das ist ein Produkt. Kein Prompt.
1. Anatomie: grüner Test, totes Orakel
Eine typische Qualitätswoche in einer Bank, einem Telco oder Fintech sieht nicht aus wie ein Playwright-Tutorial. Sie sieht aus wie drei getrennte Schleifen:
- Unit. Entwickler, JUnit oder pytest, Copilot in der IDE. Artefakt: die Datei
*Test.java, die niemand liest, weil sie „durchgeht“. - E2E. QA klickt Staging oder aufgezeichnetes Selenium. Flaky auf CI, daher ist der Job
allow_failure: true. - „Sicherheit”. Sonar / Checkmarx in der Pipeline. Quality gate so eingestellt, dass es den Release nicht blockiert. Findings landen in „won’t fix“.
Drei Anzeichen dafür, dass Sie einen Generator und keine Testautomatisierung haben:
- Orakel aus dem SUT geklont. Der Test ruft denselben helper wie die Produktion auf und vergleicht das Ergebnis mit dem Ergebnis. FX-Rundung, Rabatt, VAT — der Bug ist im helper, der Test kanonisiert ihn.
- Line coverage ohne mutation score. PIT oder Stryker würde einen Mutanten in drei Sekunden töten. Niemand führt es aus. Das Team-KPI ist % der Zeilen, nicht die Anzahl der getöteten Mutanten.
- SAST ohne SLO. Ein kritischer CWE in Zahlungen hängt 120 Tage, weil „false positive last time“. LLM-Tests werden das nicht erfassen: SAST liest ein Muster, der Test liest ein Verhalten. Das sind zwei verschiedene Alarme.
Deshalb ist ein Briefing „Tester, der Copilot beherrscht“ ohne Orakel-Kontext der teuerste Weg zu einem weiteren grünen Build. Die Kompetenzen, die Testautomatisierung tatsächlich ausmachen, finden sich auf den Landingpages: Tester und QA automation, JS/TS (Playwright, Cypress), Java, Python. SAST und Secure SDLC ergänzen cybersecurity / DevSecOps. CI, in dem diese Jobs überhaupt funktionieren: DevOps / SRE.
2. Was Studien sagen, nicht die Decks „AI writes tests”
Sie brauchen keine weitere shift-left Definition. Sie brauchen eine Schwelle, ab der ein generierter Test in main gelangen darf — und das Recht, nicht hineinzukommen, wenn er nur kompiliert.
- 75 / 57 / 25 — und erst dann der Mensch. Alshahwan et al., Automated Unit Test Improvement using Large Language Models at Meta (FSE 2024, arXiv:2402.09171): TestGen-LLM verbessert bestehende, von Menschen geschriebene Tests, es schreibt keine Suite von Grund auf neu. Auf Reels und Stories (Instagram) bauen 75% der generierten Tests, 57% laufen stabil, 25% erhöhen die coverage. Bei Instagram- und Facebook-Test-a-thons verbesserte das Tool 11,5% der Klassen, auf die es angewendet wurde. 73% der Empfehlungen wurden von Meta-Ingenieuren für die Produktion akzeptiert. Der Filter (Kompilierung, keine Flakes, delta coverage) dient dazu, dass eine Halluzination nicht in main gelangt. Die Autoren nennen dies Assured Offline LLMSE: Der Output des Modells ist ein Kandidat, kein Code.
- Die coverage steigt, wenn das LLM eine Lücke erhält, nicht die ganze Datei. Pizzorno und Berger, CoverUp: Effective High Coverage Test Generation for Python (arXiv:2403.16218): coverage-Schleife → prompt für ungedeckten Fragment → Test → Messung. Median line+branch 80% versus 47% bei CodaMosa; versus MuTAP 89% zu 77% insgesamt. Das ist keine GPT-Magie. Das ist feedback aus der Instrumentierung in der Schleife, analog zu PSI im continuous training.
- Reines ChatGPT beschädigt Assertions. Yuan et al., No More Manual Tests? Evaluating and Improving ChatGPT for Unit Test Generation (arXiv:2305.04207): Tests von ChatGPT scheitern bei der Kompilierung und an falschen Assertions. ChatTester (Generator + iterativer Refiner) liefert 34,3% mehr kompilierbare Tests und 18,7% mehr mit korrekter Assertion. Selbst die „self-repair“-Funktion des Modells entbindet den Menschen nicht von der Rolle des Orakels: Der Refiner korrigiert Syntax und assert, nicht die Geschäftsspezifikation.
- Ein neueres Modell ersetzt das quality gate nicht. Konstantinou, Degiovanni und Papadakis (arXiv:2601.09695, 2026) replizieren HITS, SymPrompt, TestSpark und CoverUp auf neueren LLMs: Ein naiver prompt ist manchmal besser bei line coverage (+17,7%), branch coverage (+19,8%) und mutation score (+20,9%) als ältere pipelines. Die operative Schlussfolgerung ist das Gegenteil des Slides „Kauft Copilot“: Ein stärkeres Modell erhöht das volume an Kandidaten. Volume ohne Filter bedeutet mehr grüne Tests zur Überprüfung. Die Überprüfung ist der Engpass, nicht der Token.
Wichtige architektonische Schlussfolgerung
Die Testautomatisierung mit AI beginnt am quality gate, nicht mit der Lizenz. Der Generator schreibt einen Kandidaten. CI prüft: Kompilierung, keine Flakes, delta coverage oder mutation score, kein Orakel-Klon aus dem SUT. SAST separat: Kritische CWE blockiert den merge. Der Mensch (SDET) akzeptiert, was der Filter nicht kann: ob die Assertion den Vertrag oder den heutigen Bug beschreibt. Wenn irgendeine Stufe „aus Copilot einfügen und merge“ ist, haben Sie keine Codequalität. Sie haben Geschwindigkeit.
3. Fallstudie aus der Produktion: coverage 71%, FX-Bug in Produktion
Aus der Ingenieurpraxis: vom Copilot zum mutation score
Zahlungs-API, Java 17 + Spring Boot, E2E mit Playwright, SAST: SonarQube in GitLab CI. Das Team arbeitete wie folgt:
- unit: Entwickler + Copilot, JUnit 5, coverage gate von 60% der Zeilen,
- E2E: QA, aufgezeichnete happy-path-Szenarien, Job als optional markiert,
- SAST: quality gate auf dem Hotfix-Branch deaktiviert „um es rechtzeitig zu schaffen”,
- Sprint-Metrik: % coverage. Keine change fail rate. Keine Anzahl getöteter Mutanten.
Problem: Im Sprint stieg das coverage des Billing-Moduls von 44% auf 71%. Zwei Wochen später unterschritt in Produktion eine FX-Rundung (Cent-Beträge bei Währungsumrechnung) den Betrag. Die Tests riefen FxRounding.round(amount) — denselben helper wie die Produktion — und verglichen mit dem Ergebnis des helpers. Der Bug war im helper. Die Suite bestätigte ihn. Sonar markierte seit vier Monaten duplizierte Logik. Ticket: won’t fix.
Änderung: Ein Gate wie bei Meta, nur auf dem Spring-Stack. Ein neuer Test mit LLM wird integriert, wenn: (1) er kompiliert, (2) er dreimal hintereinander erfolgreich ist, (3) PIT eine positive mutation score Delta auf der Klasse zeigt, (4) die Assertion das SUT nicht als Orakel aufruft — expected ist eine Konstante, eine Falltabelle oder ein separates oracle in den testdata, (5) ein SDET den PR überprüft. SAST: CWE im Paket payments blockiert den Merge, öffnet keinen Slack-Kanal.
Messung: coverage sank auf dem Papier (tautologische Tests wurden entfernt). Der mutation score für Billing stieg. Ein weiterer FX-Hotfix wurde in der CI abgefangen, nicht beim Kunden. PR-Review-Zeit mit Tests: Minuten, nicht „wir akzeptieren, weil es grün ist”. Das ist kein Copilot Enterprise. Das ist der Eigentümer des Orakels.
Die Zahlen aus dem Meta-Paper lassen sich nicht 1:1 auf Ihr Billing übertragen. Übertragbar ist die Mechanik: 75% „erfolgreich gebaut wird” ist noch keine Qualität. 25% mit coverage-Delta und 73% Akzeptanz ist bereits ein Prozess, der vor einer Risikokommission auditiert werden kann — analog zum PSI-Gate in MLOps-Dienstleistungen.
4. Entscheidungstabelle: welche Tests, welche Zusammensetzung
| Ansatz | Komplexität | Qualitätssignal | Kosten CI / Tokens | Overhead für das Team | Wann anwenden |
|---|---|---|---|---|---|
| Manuell / Exploration | Niedrig | Hoch bei UX und Randbereichen, null bei Regression | Niedrig | Hoch bei jedem Release | Neue Oberfläche, kein API-Vertrag, PoC |
| Aufgezeichnetes E2E (Selenium IDE, codegen) | Niedrig | Happy-path; flaky bei CSS | Mittel (Minuten pro Job) | Mittel (Reparatur von Selektoren) | Demo, keine Pyramide; nicht als einziges Gate |
| SDET + Pyramide (unit, API, enges Playwright) | Mittel | Regression, Vertrag, p95 des Jobs | Mittel | Mittel, sinkt, wenn die Suite stabil ist | Produkt mit CI, festes Team, SLA für Release |
| LLM dump (Copilot → commit, gate = coverage) | Niedrig | Falsch: Zeilen wachsen, Mutanten leben | Niedrig–Mittel (Tokens) | Versteckt (Review- und Produktionsschuld) | Niemals als Merge-Gate. Übung, kein Prozess |
| Assured LLMSE (Meta-Filter: build, pass, delta, accept) | Hoch | Coverage-Delta / mutation score + Review | Mittel–Hoch (Schleife + Tokens) | Hoch am Start, sinkt, wenn der Filter stabil ist | Großer Monolith, bestehende Suite, SDET am Gate |
| SAST mit SLO (CWE im Critical Path blockiert) | Mittel | Muster im Code, nicht Verhalten | Niedrig–Mittel | Triage; ohne Eigentümer = null | Zahlungen, IAM, personenbezogene Daten; neben Tests, nicht stattdessen |
QA automation / SDET ist kein „billigerer Entwickler“ und kein Pentest. Stundensätze 2026: Spezialist 110–160 PLN/h, Kunde 160–240 PLN/h, 26–38 Tsd. B2B. Manuelle Tester liegen deutlich darunter. Pentest und GRC sind auf einem anderen Landing. Marge 10–25%. Eine Karte, kein Preisverzeichnis — Details in den Sätzen 2026.
5. Anti-Patterns, die nicht im Copilot-Tutorial stehen
- Coverage als Generator-KPI. Das Team feiert 71% Zeilen. PIT würde 40% Mutanten am Leben lassen. Meta veröffentlicht 25% Klassen mit Delta-Coverage nicht, weil das Modell schwach ist. Sondern weil der Filter den Rest verwirft. Ihr Dashboard ohne diesen Filter lügt in die andere Richtung.
- Expected mit demselben Code wie die Produktion berechnet. Ein Klassiker im Billing, bei Steuern, FX, Rabattallokation. Der Test „dokumentiert“ einen Bug. Das Orakel ist eine Falltabelle, eine Konstante aus der Buchhaltung oder ein separates, reviewtes Oracle. Nicht
service.calc(x)versusservice.calc(x). - SAST dauerhaft im Informationsmodus. 180 findings, null Owner, quality gate für Hotfix deaktiviert. LLM-Tests werden SAST nicht ersetzen: Sie werden CWE-89 in der string concatenation nicht lesen, wenn die Assertion HTTP 200 prüft. Umgekehrt: SAST wird eine falsche Cent-Rundung nicht erkennen. Zwei Alarme. Zwei Eigentümer oder ein SDET mit DoD für beide.
- Briefing „QA mit AI“ für die SDET-Rolle. Sie bekommen jemanden, der klickt und einfügt. Sie bekommen keinen Menschen, der 75% des Modell-Outputs ablehnt. Der Markt ist genauso zerbrochen wie bei MLOps: Der klassische Tester hat Angebot, der SDET mit Orakel und CI nicht. Eine Ausschreibung mit falschem Label sammelt Lebensläufe in 48 h und null Kompetenzen bezüglich mutation score.
- Falsches Qualitätsteam. Manual von Vendor A, „jemand von Cypress“ von B, SAST „zu 10% aus Security“. Drei Onboardings, null gemeinsames Definition of Done für den Merge. Die Anatomie dieses Fehlers haben wir in team leasing vs body leasing 2026 beschrieben. Das ist kein staff augmentation. Das ist eine Integrationssteuer.
6. Playbook: Wen beauftragen und in welcher Reihenfolge
Beginnen Sie nicht mit der Copilot Enterprise-Lizenz. Beginnen Sie mit der Frage, welche Schleife den Release blockiert: Unit, E2E, SAST oder das Fehlen eines Oracle-Owners.
- Eine Lücke in der bestehenden Pyramide. Sie haben JUnit/pytest, Playwright auf dem kritischen Pfad, CI, jemanden, der PRs überprüft. Es fehlt ein LLM-Filter-Owner und SAST-Triage. Das ist klassisches Body Leasing von Testern und SDETs: eine Person, Ihr Stand-up, Ihr DoD. Erste Profile innerhalb von Tagen, nicht in einem Quartal – wir sourcen auf Anfrage, wir verkaufen keine namentliche Bank für morgen früh.
- Der einzige Test ist ein Klick. Es gibt keinen Unit-Test, keinen API-Vertrag, Sonar steht seit einem halben Jahr still. Eine Person wird das nicht zusammenfügen. Team von 3–5: SDET (Pyramide, CI), exploratives QA (was ein Generator nicht erfindet), DevOps, falls Jobs nicht existieren. Das ist näher am team leasing als „wir kaufen Copilot und einen Junior dazu“.
- Testdaten verlassen die VPC nicht. Zahlungs-Fixtures, PESEL, NDA. Auftragnehmer in Ihrem IAM, Ihre Umgebung, T&M-Vertrag mit NDA, Datenverarbeitungsvereinbarung und IP auf Kundenseite. Ein Prod-Dump auf Colab „damit Copilot Tests besser errät“ ist ein Leak. Ein Prompt mit Code unter NDA an eine öffentliche Modell-Cloud – auch.
- Ramp-up. Person für ein bestehendes Team: erste Lebensläufe 24–48 h, Start nach Ihren Gesprächen und Vertrag. Squad von Grund auf: Wochen, kein Sprint, da Sie Berechtigungen, Testdaten und DoD für den Merge zusammenfügen. Die Lüge „drei Senior SDETs ab Montag“ ist ein Lebenslauf oder eine Bank, die wir nicht haben – und wir werden nicht so tun.
Commoditech bietet seit 2012 T&M und Festanstellung aus Warschau an. Über 80 Spezialisten im Netzwerk, keine idle bench. Ein T&M-Brief oder eine Success Fee kann über die IDE via MCP für AI-Agenten eingereicht werden, nicht nur über ein Formular. Beträge für einen spezifischen Stack werden von einem Menschen berechnet; Spannen finden Sie im Artikel über die Tarife, nicht im JSON des Agenten.
FAQ
Wird LLM die Testautomatisierung und QA-Tester ersetzen?
Nein. LLM ist ein Kandidatengenerator. Meta TestGen-LLM: 75% der Tests lassen sich bauen, 57% laufen stabil durch, 25% erhöhen die coverage. 73% der Empfehlungen gingen in Produktion, da der Filter (Kompilierung, pass, delta coverage) und die Ingenieur-Review den Rest aussortierten. Ohne quality gate kaufen Sie grüne Assertions auf dem aktuellen Verhalten, einschließlich Fehlern. ChatTester zeigt, dass selbst die self-repair des Modells die Syntax repariert, nicht die Spezifikation.
Wann mietet man einen SDET und wann ein QA-Team?
Eine Person, wenn die Pyramide steht (unit + API + enge E2E in CI) und ein quality gate owner fehlt: mutation score, triage SAST, Test-Review von Copilot. Ein Team von 3–5 (SDET + explorativer QA + jemand für CI), wenn der einzige Test ein Klick im Staging ist und Sonar seit einem halben Jahr 200 findings in „won’t fix“ hat. Ein SDET allein schreibt keine Business-Orakel für den product owner. Ein manueller Tester allein wird den job in GitLab nicht aufrechterhalten. Wenn Sie niemanden haben, der einen PR von einem Contractor reviewt, kaufen Sie kein body leasing. Kaufen Sie einen Lead plus eine Rolle oder einen squad.
Was kostet body leasing SDET / QA automation in Polen im Jahr 2026?
QA automation / SDET: Spezialist 110–160 PLN/h, Kunde 160–240 PLN/h, 26–38 Tsd. B2B. Ein manueller Tester ist deutlich günstiger; ein SDET nicht. Pentest und NIS2 sind ein anderer Satz und ein anderes landing. Anbietermarge 10–25% — wenn jemand 8% bei einer Vertretung innerhalb von 5 Tagen verspricht, rechnen Sie dies in einer anderen Position ein. Dies ist eine Marktübersicht, kein Angebot. Der Betrag für ein Briefing wird von einem Menschen berechnet. Details finden Sie unter Preise 2026.
Wie unterscheidet sich SAST von durch LLM generierten Tests?
SAST liest Code ohne Ausführung und sucht nach Mustern (SQLi, XSS, Geheimnisse, CWE). LLM schreibt einen Test, der schlechtes Verhalten fehlschlagen lassen soll. SAST ohne Owner ist ein false positive Dashboard. LLM ohne Filter ist coverage vanity. Beide benötigen SLO: ein kritischer CWE darf nicht in „informational“ hängen bleiben, ein Test von Copilot darf nicht ohne delta mutation score eingecheckt werden. Das sind keine Ersatzprodukte. Das sind zwei jobs in einem DoD beim merge.
Quellen
- Alshahwan, N., Chheda, J., Finogenova, A., Gokkaya, B., Harman, M., Harper, I., Marginean, A., Sengupta, S., Wang, E. (2024). Automated Unit Test Improvement using Large Language Models at Meta. FSE 2024. arXiv:2402.09171. arxiv.org/abs/2402.09171
- Pizzorno, J. A., Berger, E. D. (2024). CoverUp: Effective High Coverage Test Generation for Python. arXiv:2403.16218. arxiv.org/abs/2403.16218
- Yuan, Z., Lou, Y., Liu, M., Ding, S., Wang, K., Chen, Y., Peng, X. (2023/2024). No More Manual Tests? Evaluating and Improving ChatGPT for Unit Test Generation. arXiv:2305.04207. arxiv.org/abs/2305.04207
- Konstantinou, M., Degiovanni, R., Papadakis, M. (2026). How well LLM-based test generation techniques perform with newer LLM versions? arXiv:2601.09695. arxiv.org/abs/2601.09695
- DORA / Google Cloud (2024). Accelerate State of DevOps Report.
- Commoditech — Body-Leasing-Preise 2026, team leasing vs body leasing, Anmietung von Testern und SDETs.