--- title: "Agentisches Testen vs. Testautomatisierung 2026" canonical: https://wavect.io/de/blog/agentic-testing-vs-test-automation-2026/ language: de description: "Agentisches Testen im Vergleich: 30-Tage-Pilot, Kostenmodell, Guardrails und Scorecard für die Entscheidung über KI-Testagenten." image: "https://wavect.io/img/blog/headers/header_agentic-testing-vs-test-automation-2026.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min Lesezeit · 11. August 2026 Zuletzt geprüft 11. August 2026 [**Weiter**](/de/blog/muse-glimmer-30b-local-agent-guide/) # Agentisches Testen vs. Testautomatisierung: Praxisleitfaden für 2026 TL;DR Beim agentischen Testen erhält ein KI-Agent ein Ziel und plant, erzeugt, startet und verändert Tests selbstständig. Klassische Testautomatisierung führt dagegen vorab definierte Skripte aus. Setze Agenten für Exploration, erste Testentwürfe und Fehlertriage ein, aber halte fachliche Assertions, Release-Gates und destruktive Aktionen deterministisch oder menschlich freigegeben. Prüfe einen kritischen Ablauf in einem 30-Tage-Pilot und miss bestätigte Fehler, Fehlalarme, Review-Zeit, Wartungszeit, Ausführungskosten und entkommene Defekte. Skaliere nur, wenn die akzeptierte Evidenz zu geringeren Gesamtkosten pro brauchbarem Fund steigt. Beim agentischen Testen entscheidet ein KI-Agent, wie er ein Testziel verfolgt, beobachtet die Anwendung, passt seine Aktionen an und schlägt Evidenz vor. Klassische Testautomatisierung führt dagegen einen vorab definierten Ablauf mit festen Assertions aus. Das sinnvolle Muster für 2026 verbindet beides: Agenten entdecken und entwerfen, deterministische Prüfungen und verantwortliche Menschen entscheiden, ob die Software bestanden hat. Dieser Einkaufsleitfaden richtet sich an Product Leads, CTOs und QA-Teams, die einen Pilot mit KI-Testagenten erwägen. Hier wird nicht die KI in einem Produkt getestet. Dieses andere Problem behandeln wir in [QA für KI-generierten Code](/de/blog/qa-for-ai-generated-code/). Hier ist der Agent der Tester, während die geprüfte Anwendung eine normale Web-, Mobile- oder API-Software sein kann. ## Was ist agentisches Testen? **Agentisches Testen ist ein Ansatz, bei dem ein KI-Agent Aktionen für ein Testziel plant und ausführt, Beobachtungen bewertet und den nächsten Schritt anpasst.** Der Agent kann eine Oberfläche erkunden, einen Testplan entwerfen, ausführbaren Code erzeugen, ihn starten, einen Fehler untersuchen oder eine Reparatur vorschlagen. Autonomie ist ein Spektrum, kein Ein-Aus-Schalter. | Ansatz | Wer bestimmt die nächste Aktion? | Geeignet für | Hauptrisiko | | --- | --- | --- | --- | | Manuelles exploratives Testen | Ein menschlicher Tester | Unbekannte Risiken und Produkturteil | Begrenzte Wiederholbarkeit | | Klassische Testautomatisierung | Ein vordefiniertes Skript | Stabile Regressionstests und Release-Gates | Wartung bei Änderungen | | KI-gestütztes Testen | Ein Mensch mit KI-Vorschlägen | Schnellere Entwürfe für Fälle, Daten und Code | Plausible, aber schwache Assertions | | Agentisches Testen | Ein Agent innerhalb eines Ziel- und Berechtigungsrahmens | Exploration, Generierung, Anpassung und Triage | Nichtdeterminismus und falsche Sicherheit | Der Unterschied liegt im geschlossenen Regelkreis. Ein Recorder zeichnet auf, was ein Tester bereits getan hat. Ein Codegenerator schreibt einmalig ein Skript. Ein Testagent beobachtet das Ergebnis, bewertet es und wählt eine weitere Aktion. Genau dieser zusätzliche Regelkreis erzeugt den möglichen Wert und das neue Assurance-Problem. ## Was hat sich beim agentischen Testen 2026 verändert? Playwright dokumentiert heute einen Ablauf mit drei Agenten: Ein Planner erkundet die Anwendung und erstellt einen Markdown-Plan, ein Generator macht daraus ausführbare Tests und ein Healer startet und repariert fehlgeschlagene Tests. Die Dateien bleiben sichtbar im Repository. Dadurch ist der Ablauf überprüfbar, statt hinter einem Dashboard zu verschwinden. Siehe die offizielle [Dokumentation zu Playwright Test Agents](https://playwright.dev/docs/test-agents). Für Android nimmt der App-Testing-Agent in der Firebase-Vorschau Ziele, Schritte, Hinweise und Assertions für den Endbildschirm in natürlicher Sprache an und führt sie auf ausgewählten Geräten aus. Google dokumentiert auch Grenzen: Läufe können unterschiedliche Aktionen wählen, KI-gesteuerte Tests haben ein Zeitlimit von fünf Minuten und komplexe Aufgaben funktionieren besser in kleineren Schritten. Lies die [Vorschaudokumentation zum Firebase App Testing Agent](https://firebase.google.com/docs/app-distribution/android/app-testing-agent). Die Forschung steht am Anfang. Eine Arbeit vom Januar 2026 beschreibt einen Multi-Agenten-Kreislauf für Generierung, Ausführung, Analyse und Review. In der eigenen Microservice-Auswertung meldet sie gegenüber ihren Single-Model-Baselines bis zu 60% weniger ungültige Tests und 30% mehr Coverage. Diese Zahlen gehören zu genau diesem Experiment, nicht zu deinem Backlog. Behandle die [Arbeit zum agentischen Testframework](https://arxiv.org/abs/2601.02454) als Mechanismus, den dein Pilot im eigenen System erst bestätigen muss. ## Wo sollten Agenten Skripte ergänzen und wo nicht? | Testaufgabe | Empfohlener Owner | Warum? | | --- | --- | --- | | Einen unbekannten Ablauf erkunden | Agent plus Tester | Der Agent erweitert Pfade, der Tester liefert Risiko- und Produktkontext. | | Testpläne und Fälle entwerfen | Agent, menschlich geprüft | Generierung ist günstig, ein schwaches Orakel ist teuer. | | Summen, Berechtigungen und Zustand prüfen | Deterministische Assertion | Geld, Zugriff und Datenintegrität brauchen wiederholbare Evidenz. | | Einen Selektor reparieren | Agentenvorschlag plus Code-Review | Der Locator darf sich ändern, die fachliche Absicht nicht. | | Erwartungswert ändern oder Test überspringen | Menschliche Freigabe | Eine Änderung am Orakel kann eine echte Regression verdecken. | | Release oder Rollback | Policy-Gate und verantwortlicher Owner | Die Folge ist größer als der Evidenzrahmen des Agenten. | Eine Studie aus 2026 zu Pull Requests autonomer Coding-Agenten fand, dass PRs mit Tests häufiger wurden. Ihre Merge-Raten blieben aber weitgehend ähnlich wie bei PRs ohne Tests, und die Praxis unterschied sich je nach Agent. Das ist beschreibende Evidenz, kein Sicherheitsbeweis. Die [Studie zu Tests in agentischen Pull Requests](https://arxiv.org/abs/2601.03556) stützt eine einfache Regel: Zähle akzeptierte Evidenz und gefundene Fehler, nicht erzeugte Dateien. ## Die sichere Architektur für einen Agentic-Testing-Pilot Ein glaubwürdiger Pilot hat sieben Grenzen. „Agent mit Staging verbinden und testen lassen“ reicht nicht. 1. **Ein begrenzter Ablauf.** Wähle einen wirtschaftlich wichtigen Flow wie Registrierung, Angebotsanfrage oder Checkout. 2. **Wegwerfbare Testdaten.** Nutze vorbereitete Konten und Datensätze, die zurückgesetzt werden können, nie Kundendaten. 3. **Minimale Rechte.** Browseraktionen, schreibgeschützte Logs und eine enge Testdaten-API sind sicherer als offene Shell oder Produktivzugriff. 4. **Versionierte Intent-Spezifikation.** Speichere Ziel, Vorbedingungen, erlaubte Aktionen und erwartetes Ergebnis neben dem Code. 5. **Unabhängige Orakel.** Prüfe wichtige Resultate über APIs, Datenbankstatus, Events oder feste Assertions außerhalb des Modells. 6. **Vollständige Audit-Spur.** Bewahre Plan, Aktionen, Screenshots, Traces, Diff, Versionen, Kosten und Review-Entscheidung auf. 7. **Menschlich kontrollierte Änderungen.** Ein Mensch genehmigt Assertion-Änderungen, Skips, Schreibrechte und Release-Folgen. Das unabhängige Orakel ist das Zentrum. Wenn dasselbe Modell den Pfad auswählt, den Bildschirm interpretiert und Erfolg erklärt, hast du eine Meinung dreimal wiederholt. Ein Zahlungstest sollte Betrag und Status über eine deterministische Systemgrenze bestätigen. Ein Berechtigungstest muss beweisen, dass eine verbotene Anfrage am Server scheitert, nicht nur, dass ein Button verborgen ist. ## Warum Self-Healing falsche Sicherheit schaffen kann Self-Healing ist wertvoll, wenn es Implementierungsdetails repariert, ohne die Absicht zu ändern. Ein veralteter Selektor darf durch die richtige barrierefreie Rolle ersetzt werden. Wird dagegen „Bestellsumme ist 120 €“ zu „eine Bestellsumme ist sichtbar“, wurde der Test zerstört und gleichzeitig grün gemacht. Ein aktuelles Positionspapier argumentiert, dass Output von Testagenten ohne ausreichende Prüfung als Assurance akzeptiert werden kann, besonders wenn Erklärungen glaubwürdig klingen. Die [Arbeit zur Überabhängigkeit von Testagenten](https://arxiv.org/abs/2607.17927) ist kein Wirksamkeits-Benchmark. Sie stellt aber die richtige Frage: Kann ein Reviewer rekonstruieren, warum dieser Test als Evidenz gilt? - **Automatisch akzeptieren:** Formatierung, Imports oder gleichwertiger Locator, solange Assertion und Ziel unverändert bleiben. - **Review erforderlich:** Wartezeiten, Navigation, Fixtures oder Daten-Setup. - **Nie automatisch heilen:** Erwartungswerte, Berechtigungsergebnisse, finanzielle Berechnungen, Skips und Release-Schwellen. ## Was kostet agentisches Testen? Es gibt keinen belastbaren Universalpreis. Vergleiche monatliche Gesamtkosten, nicht nur die Modellrechnung: **Kosten = Setup + Plattform- oder Modellnutzung + Testinfrastruktur + menschliches Review + Fehlalarm-Triage + Wartung + Governance** **Kosten pro brauchbarem Fund = gesamte Pilotkosten / bestätigte Fehler oder wesentliche Coverage-Lücken, die das Team akzeptiert** Miss auch Wartungsminuten pro akzeptiertem Test und Review-Minuten pro Lauf. 500 erzeugte Fälle sind keine 500 Werteinheiten, wenn ihre Prüfung 40 Stunden braucht. ## Ein 30-Tage-Plan für den Pilot | Woche | Arbeit | Exit-Evidenz | | --- | --- | --- | | 1: Baseline | Ablauf wählen, Fehler, Coverage, Laufzeit, Flakes und Wartung erfassen. Stop-Kriterien festlegen. | Intent, Baseline, vorbereitete Umgebung und Berechtigungskarte. | | 2: Shadow | Agent planen und ausführen lassen, ohne Suite oder Releases zu ändern. Alles prüfen. | Bestätigte Funde, Fehlalarme, verpasste bekannte Fehler und Review-Minuten. | | 3: Kontrollierter Beitrag | PRs für neue Tests und risikoarme Locator-Reparaturen erlauben. Assertions bleiben reviewpflichtig. | Akzeptanzrate, Erkennung vorbereiteter Fehler, Wartungszeit und stabile Wiederholungen. | | 4: Entscheidung | Parallel zum bestehenden Prozess laufen lassen und Gesamtkosten berechnen. | Scale-, Revise- oder Stop-Entscheidung mit Ownern und Rollback. | Baue bekannte Fehler oder Mutationen ein und behalte ein Holdout-Set, das nicht im Prompt vorkam. So misst du relevante Fehlererkennung statt Aktivität oder Erinnerung an Beispiele. ## Welche KPIs entscheiden über die Skalierung? - **Präzision:** bestätigte Funde geteilt durch alle gemeldeten Funde. - **Erkennung vorbereiteter Fehler:** bekannte relevante Fehler, die der Agent ohne Hinweis findet. - **Akzeptanzrate:** nach Review gemergte Tests geteilt durch eingereichte generierte Tests. - **Review- und Wartungszeit:** menschliche Minuten pro Lauf, akzeptiertem Test und Produktänderung. - **Wiederholbarkeit:** konsistente Ergebnisse bei gleichen Startbedingungen. - **Kosten pro brauchbarem Fund:** die vollständige Formel, nicht nur Tokens. - **Escape-Veränderung:** ob vergleichbare Fehler nach dem Pilot weiter Produktion erreichen. ## Scorecard für die Bereitschaft | Frage | Gutes Pilotsignal | Zuerst vorbereiten | | --- | --- | --- | | Ist der Ablauf wirtschaftlich wichtig? | Ein Fehler verändert Umsatz, Risiko oder Release-Vertrauen. | Die Demo wurde nur gewählt, weil sie einfach ist. | | Kann die Umgebung zurückgesetzt werden? | Konten und Daten sind vorbereitet und wegwerfbar. | Tests hängen von gemeinsamen oder produktiven Daten ab. | | Kann Erfolg unabhängig geprüft werden? | APIs, Events oder Datenbankstatus liefern ein Orakel. | Nur das visuelle Urteil des Agenten zählt. | | Gibt es eine Baseline? | Kennzahlen für Fehler, Flakes, Aufwand und Escapes existieren. | Es gibt keinen glaubwürdigen Vergleich. | | Sind Rechte eng begrenzt? | Der Agent erhält reine Testidentitäten und enge Tools. | Er braucht Adminrechte, Produktivzugriff oder offene Shell. | | Gibt es Review-Kapazität? | Ein QA- oder Engineering-Owner ist verantwortlich. | Autonomie soll jede Aufsicht abschaffen. | Stehen vier oder mehr Zeilen rechts, verbessere zuerst das Testsystem. Dieselbe Arbeit hilft auch klassischer Automatisierung. ## Was muss ein Anbieter oder Partner liefern? - Ein klares Autonomiemodell für Beobachten, Ändern und Genehmigen. - Exportierbare, versionierte Tests und Intent-Spezifikationen. - Modell-, Tool- und Promptversion für jeden Lauf. - Evidenz aus deterministischen Assertions, nicht nur Agentenzusammenfassungen. - Aufgeschlüsselte Kosten für Plattform, Inferenz, Geräte, Speicher und Review. - Kontrollen für Testzugänge, Aufbewahrung, Datenregion und Löschung. - Einen Rückweg zu normalen ausführbaren Tests ohne Lock-in. - Eine Entscheidung auf Basis deiner Baseline, auch wenn sie „nicht ausrollen“ lautet. OWASP empfiehlt, Werkzeuge und Berechtigungen zu minimieren und folgenreiche Aktionen menschlich freigeben zu lassen. Das gilt auch, wenn der Agent „nur testet“, denn Browser- oder API-Tests können Bestellungen anlegen, Nachrichten senden oder Daten ändern. Nutze die [OWASP-Kontrollen gegen Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) als Einkaufsliste. ## Kann agentisches Testen QA Engineers ersetzen? Nein. Es kann Teile der Pfaderstellung, Ausführung und ersten Triage übernehmen. QA Engineers definieren Risiken, entwerfen unabhängige Orakel, untersuchen Mehrdeutigkeit und entscheiden, welche Evidenz für ein Release reicht. Der Beruf verschiebt sich zur Gestaltung und Aufsicht eines vertrauenswürdigen Testsystems. ## Darf ein Testagent in Produktion laufen? Nur mit einem getrennten, stark begrenzten Design. Starte in einer zurücksetzbaren Nicht-Produktivumgebung. Produktivchecks brauchen synthetische Identitäten, erlaubte Aktionen, harte Ausgaben- und Ratenlimits, Datenbereinigung und sofortige Kill-Controls. ## Wie Wavect einen Pilot absteckt Wir beginnen beim bestehenden Delivery-System, nicht bei einer Tool-Demo. Unsere [Software-Quality-Assurance-Leistung](/de/services/software-quality-assurance/) erfasst Ablauf, Baseline und Evidenzrahmen. Die [Software-QA-Checkliste vor dem Launch](/de/software-development-guide/software-qa-checklist-before-launch/) liefert deterministische Release-Prüfungen. Die [IKB-Fallstudie zur Infrastruktur](/de/case-studies/ikb/) zeigt Integrationsdisziplin über echte Systemgrenzen. Das Ergebnis ist ein Pilot-Branch, ein Evidenzbericht und eine Scale-or-Stop-Entscheidung. Wenn der Agent Lärm erzeugt, ist Stoppen ein erfolgreicher Ausgang. Wenn relevante Coverage bei geringeren Kosten pro akzeptiertem Fund wächst, folgt ein kontrollierter Rollout. [Buche ein Gespräch zur QA-Pilotplanung](/de/contact/). ## Quellen und methodische Grenze Playwright und Firebase dokumentieren Funktionen, beweisen aber keinen ROI für dein Team. Die zitierten Studien untersuchen bestimmte Datensätze oder schlagen Frameworks vor. Sie liefern keine universelle Erkennungsrate. Kostenformeln und Scorecard sind Entscheidungshilfen, keine Branchenbenchmarks. Prüfe Verfügbarkeit, Vorschaubedingungen und Datenverarbeitung vor dem Einkauf erneut. ## Fazit Agentisches Testen ersetzt deterministische Testautomatisierung nicht. Es ergänzt Exploration, Generierung, Reparatur und Triage um eine adaptive Schicht. Eine wertvolle Architektur gibt dem Agenten Raum zur Suche und hält die fachliche Wahrheit außerhalb des Modells. Führe einen 30-Tage-Pilot durch und zähle akzeptierte Evidenz statt erzeugter Aktivität. Skaliere nur, wenn bestätigte Funde steigen, das Review bezahlbar bleibt und der Agent nicht still verändern kann, was bestanden bedeutet. ## Das könnte dich auch interessieren.. [**Externer QA-Benchmark: Die ersten 30 Tage** Bestätigte Funde, Discovery Lift und Produktions-Escapes ohne erfundene Universalquote messen.](/de/blog/external-qa-benchmark-first-30-days/) [**QA für KI-generierten Code** Das umgekehrte Problem: Was kaputtgeht, wenn KI Anwendungscode schreibt, und wie du ihn vor dem Launch härtest.](/de/blog/qa-for-ai-generated-code/) QA und Produktionsreife ## In diesem Cluster weiterlesen [Mit dem Grundlagenartikel starten**QA für KI-generierten Code**](/de/blog/qa-for-ai-generated-code/) - [Externer QA-Benchmark: Was wir in den ersten 30 Tagen finden](/de/blog/external-qa-benchmark-first-30-days/) - [Was Software-Wartung nach dem Launch kostet: Ein DACH-SaaS-Benchmark](/de/blog/software-maintenance-cost-benchmark-dach-saas/) - [Agile De-Engineering](/de/blog/agile-de-engineering/) - [Due Diligence für Lovable-, Bolt- und Replit-Apps](/de/blog/lovable-bolt-replit-app-due-diligence/) - [Die Vibe-Code-Production-Readiness-Checkliste](/de/blog/vibe-code-production-readiness-checklist/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min Lesezeit · 11. August 2026 Zuletzt geprüft 11. August 2026 [**Weiter**](/de/blog/muse-glimmer-30b-local-agent-guide/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/agentic-testing-vs-test-automation-2026/#webpage", "@type": "WebPage", "dateModified": "2026-08-11", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-11", "url": "https://wavect.io/de/blog/agentic-testing-vs-test-automation-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Beim agentischen Testen erhält ein KI-Agent ein Ziel und plant, erzeugt, startet und verändert Tests selbstständig. Klassische Testautomatisierung führt dagegen vorab definierte Skripte aus. Setze Agenten für Exploration, erste Testentwürfe und Fehlertriage ein, aber halte fachliche Assertions, Release-Gates und destruktive Aktionen deterministisch oder menschlich freigegeben. Prüfe einen kritischen Ablauf in einem 30-Tage-Pilot und miss bestätigte Fehler, Fehlalarme, Review-Zeit, Wartungszeit, Ausführungskosten und entkommene Defekte. Skaliere nur, wenn die akzeptierte Evidenz zu geringeren Gesamtkosten pro brauchbarem Fund steigt.", "articleBody": " Blog-Übersicht/Delivery und QA/QA und Produktionsreife Agentisches Testen vs. Testautomatisierung: Praxisleitfaden für 2026 TL;DR Beim agentischen Testen erhält ein KI-Agent ein Ziel und plant, erzeugt, startet und verändert Tests selbstständig. Klassische Testautomatisierung führt dagegen vorab definierte Skripte aus. Setze Agenten für Exploration, erste Testentwürfe und Fehlertriage ein, aber halte fachliche Assertions, Release-Gates und destruktive Aktionen deterministisch oder menschlich freigegeben. Prüfe einen kritischen Ablauf in einem 30-Tage-Pilot und miss bestätigte Fehler, Fehlalarme, Review-Zeit, Wartungszeit, Ausführungskosten und entkommene Defekte. Skaliere nur, wenn die akzeptierte Evidenz zu geringeren Gesamtkosten pro brauchbarem Fund steigt. Beim agentischen Testen entscheidet ein KI-Agent, wie er ein Testziel verfolgt, beobachtet die Anwendung, passt seine Aktionen an und schlägt Evidenz vor. Klassische Testautomatisierung führt dagegen einen vorab definierten Ablauf mit festen Assertions aus. Das sinnvolle Muster für 2026 verbindet beides: Agenten entdecken und entwerfen, deterministische Prüfungen und verantwortliche Menschen entscheiden, ob die Software bestanden hat. Dieser Einkaufsleitfaden richtet sich an Product Leads, CTOs und QA-Teams, die einen Pilot mit KI-Testagenten erwägen. Hier wird nicht die KI in einem Produkt getestet. Dieses andere Problem behandeln wir in QA für KI-generierten Code. Hier ist der Agent der Tester, während die geprüfte Anwendung eine normale Web-, Mobile- oder API-Software sein kann. Was ist agentisches Testen? Agentisches Testen ist ein Ansatz, bei dem ein KI-Agent Aktionen für ein Testziel plant und ausführt, Beobachtungen bewertet und den nächsten Schritt anpasst. Der Agent kann eine Oberfläche erkunden, einen Testplan entwerfen, ausführbaren Code erzeugen, ihn starten, einen Fehler untersuchen oder eine Reparatur vorschlagen. Autonomie ist ein Spektrum, kein Ein-Aus-Schalter. AnsatzWer bestimmt die nächste Aktion?Geeignet fürHauptrisiko Manuelles exploratives TestenEin menschlicher TesterUnbekannte Risiken und ProdukturteilBegrenzte Wiederholbarkeit Klassische TestautomatisierungEin vordefiniertes SkriptStabile Regressionstests und Release-GatesWartung bei Änderungen KI-gestütztes TestenEin Mensch mit KI-VorschlägenSchnellere Entwürfe für Fälle, Daten und CodePlausible, aber schwache Assertions Agentisches TestenEin Agent innerhalb eines Ziel- und BerechtigungsrahmensExploration, Generierung, Anpassung und TriageNichtdeterminismus und falsche Sicherheit Der Unterschied liegt im geschlossenen Regelkreis. Ein Recorder zeichnet auf, was ein Tester bereits getan hat. Ein Codegenerator schreibt einmalig ein Skript. Ein Testagent beobachtet das Ergebnis, bewertet es und wählt eine weitere Aktion. Genau dieser zusätzliche Regelkreis erzeugt den möglichen Wert und das neue Assurance-Problem. Was hat sich beim agentischen Testen 2026 verändert? Playwright dokumentiert heute einen Ablauf mit drei Agenten: Ein Planner erkundet die Anwendung und erstellt einen Markdown-Plan, ein Generator macht daraus ausführbare Tests und ein Healer startet und repariert fehlgeschlagene Tests. Die Dateien bleiben sichtbar im Repository. Dadurch ist der Ablauf überprüfbar, statt hinter einem Dashboard zu verschwinden. Siehe die offizielle Dokumentation zu Playwright Test Agents. Für Android nimmt der App-Testing-Agent in der Firebase-Vorschau Ziele, Schritte, Hinweise und Assertions für den Endbildschirm in natürlicher Sprache an und führt sie auf ausgewählten Geräten aus. Google dokumentiert auch Grenzen: Läufe können unterschiedliche Aktionen wählen, KI-gesteuerte Tests haben ein Zeitlimit von fünf Minuten und komplexe Aufgaben funktionieren besser in kleineren Schritten. Lies die Vorschaudokumentation zum Firebase App Testing Agent. Die Forschung steht am Anfang. Eine Arbeit vom Januar 2026 beschreibt einen Multi-Agenten-Kreislauf für Generierung, Ausführung, Analyse und Review. In der eigenen Microservice-Auswertung meldet sie gegenüber ihren Single-Model-Baselines bis zu 60% weniger ungültige Tests und 30% mehr Coverage. Diese Zahlen gehören zu genau diesem Experiment, nicht zu deinem Backlog. Behandle die Arbeit zum agentischen Testframework als Mechanismus, den dein Pilot im eigenen System erst bestätigen muss. Wo sollten Agenten Skripte ergänzen und wo nicht? TestaufgabeEmpfohlener OwnerWarum? Einen unbekannten Ablauf erkundenAgent plus TesterDer Agent erweitert Pfade, der Tester liefert Risiko- und Produktkontext. Testpläne und Fälle entwerfenAgent, menschlich geprüftGenerierung ist günstig, ein schwaches Orakel ist teuer. Summen, Berechtigungen und Zustand prüfenDeterministische AssertionGeld, Zugriff und Datenintegrität brauchen wiederholbare Evidenz. Einen Selektor reparierenAgentenvorschlag plus Code-ReviewDer Locator darf sich ändern, die fachliche Absicht nicht. Erwartungswert ändern oder Test überspringenMenschliche FreigabeEine Änderung am Orakel kann eine", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Dokumentation zu Playwright Test Agents", "url": "https://playwright.dev/docs/test-agents" }, { "@type": "WebPage", "name": "Vorschaudokumentation zum Firebase App Testing Agent", "url": "https://firebase.google.com/docs/app-distribution/android/app-testing-agent" }, { "@type": "WebPage", "name": "Arbeit zum agentischen Testframework", "url": "https://arxiv.org/abs/2601.02454" }, { "@type": "WebPage", "name": "Studie zu Tests in agentischen Pull Requests", "url": "https://arxiv.org/abs/2601.03556" }, { "@type": "WebPage", "name": "Arbeit zur Überabhängigkeit von Testagenten", "url": "https://arxiv.org/abs/2607.17927" }, { "@type": "WebPage", "name": "OWASP-Kontrollen gegen Excessive Agency", "url": "https://genai.owasp.org/llmrisk/llm062025-excessive-agency/" } ], "dateModified": "2026-08-11", "datePublished": "2026-08-11", "description": "Beim agentischen Testen erhält ein KI-Agent ein Ziel und plant, erzeugt, startet und verändert Tests selbstständig. Klassische Testautomatisierung führt dagegen vorab definierte Skripte aus. Setze Agenten für Exploration, erste Testentwürfe und Fehlertriage ein, aber halte fachliche Assertions, Release-Gates und destruktive Aktionen deterministisch oder menschlich freigegeben. Prüfe einen kritischen Ablauf in einem 30-Tage-Pilot und miss bestätigte Fehler, Fehlalarme, Review-Zeit, Wartungszeit, Ausführungskosten und entkommene Defekte. Skaliere nur, wenn die akzeptierte Evidenz zu geringeren Gesamtkosten pro brauchbarem Fund steigt.", "headline": "Agentisches Testen vs. Testautomatisierung: Pilotleitfaden 2026", "image": "https://wavect.io/img/blog/headers/header_agentic-testing-vs-test-automation-2026.svg", "inLanguage": "de", "keywords": "Softwaretests, KI-Agenten", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/agentic-testing-vs-test-automation-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/agentic-testing-vs-test-automation-2026/", "wordCount": 1952 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/delivery-qa/", "name": "Delivery und QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/qa-production/", "name": "QA und Produktionsreife", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/agentic-testing-vs-test-automation-2026/", "name": "Agentisches Testen vs. Testautomatisierung 2026 | ", "position": 5 } ] } ```