Kleine Teams und automatisierte QA: Wie KI-Agenten deine Checklisten abarbeiten

Freitag, 12:30 Uhr. Bernd (fiktiver Name) sitzt in einem Softwareteam mit sechs Leuten. Heute ist Release-Tag. Die Tickets sind abgearbeitet, die Features gemergt. Was fehlt: ein systematischer Test. Aber wer soll das machen? Eine QA-Abteilung gibt es nicht. Die unausgesprochene Regel lautet: Wer den Code geschrieben hat, klickt einmal durch. Happy Path. Sieht gut aus. Release.

Am Montag meldet sich ein Kunde. Das Bestellformular akzeptiert negative Stückzahlen. Bestellt jemand „minus fünf“, geht die Bestellung trotzdem raus. Peinlich. Vermeidbar. Und teuer: Hotfix am Montagmorgen, Kundenkommunikation, Vertrauensschaden. Ein Bug, den eine einzige Prüfung auf Eingabevalidierung gefunden hätte.

Warum QA in kleinen Teams oft ausfällt

In kleinen Teams gibt es kein dediziertes QA-Personal. Kein Budget, keine Rolle, kein Prozess. Testen passiert nebenbei, und „nebenbei“ heißt in der Praxis: jeder testet den Happy Path seiner eigenen Änderung.

Was dabei auf der Strecke bleibt, ist vorhersehbar: Edge Cases, Error Handling, responsive Checks, Validierung von Grenzwerten. Nicht, weil das Wissen fehlt. Sondern weil die Kapazität fehlt. Sechs Entwickler, die Features bauen, Bugs fixen und Kunden betreuen, haben schlicht nicht die Zeit, jede Maske systematisch auf 30 Fehlerszenarien zu prüfen.

Das Ergebnis kennt jeder, der in so einem Team gearbeitet hat: Bugs in Produktion, die vermeidbar gewesen wären. Nicht die subtilen, architektonischen Probleme. Sondern die offensichtlichen: ein Formularfeld, das negative Zahlen akzeptiert, ein Button, der auf Mobile nicht erreichbar ist, eine Fehlermeldung, die „Error 500“ sagt, statt dem Nutzer zu erklären, was passiert ist.

KI-Agenten können testen

In meinem Artikel „Von Prompts zu Agenten“ beschreibe ich, wie sich KI-Sprachmodelle vom Chatbot zum eigenständig handelnden Agenten entwickelt haben. Ein zentraler Punkt dabei: Agenten haben Werkzeuge. Sie können nicht nur Text generieren, sondern mit der realen Welt interagieren.

Für QA bedeutet das konkret: KI-Agenten haben Browser-Zugang. Sie können Seiten aufrufen, Formulare ausfüllen, Buttons klicken, Screenshots machen und die Ergebnisse bewerten. Und das Entscheidende: Man kann ihnen strukturierte Checklisten mitgeben. Nicht „teste mal die App“, sondern „prüfe jedes Formular auf diese 50 Punkte und dokumentiere jedes Finding mit Schweregrad und Screenshot.“

Das Ergebnis ist kein vager Bericht, sondern eine strukturierte Liste von Findings, die ein Entwickler direkt abarbeiten kann.

Was ist anders als Playwright und Cypress?

Automatisierte UI-Tests gibt es seit Jahren. Playwright, Cypress, Selenium: bewährte Frameworks für End-to-End-Tests. Wer sie einsetzt, hat bereits einen großen Schritt gemacht. Aber diese Tests haben eine systembedingte Grenze: Sie sind deterministisch. Sie führen exakt die geschriebenen Schritte aus. click('#submit'), expect(page).toHaveURL('/success'). Was nicht im Testskript steht, wird nicht geprüft.

Das bedeutet: Wer eine neue Maske baut, muss neue Tests schreiben. Wer einen Edge Case nicht bedacht hat, wird ihn auch nicht testen. Und die Anzahl der Tests, die ein kleines Team pflegen kann, ist begrenzt.

KI-Agenten arbeiten anders. Ein Agent versteht, was ein Formular ist. Er erkennt Eingabefelder, versteht deren Zweck (Name, E-Mail, Stückzahl) und leitet eigenständig ab, welche Eingaben sinnvoll, grenzwertig oder bösartig wären. Er braucht kein Testskript pro Maske, sondern eine Blaupause: „Prüfe jedes Formular auf diese 50 Angriffsvektoren.“

Der Unterschied in der Praxis: Playwright sagt dir „Button X führt zu Seite Y.“ Ein KI-Agent sagt dir „Das Feld Stückzahl akzeptiert -5, und das Formular wird trotzdem abgeschickt. Das ist ein Business-Logik-Fehler mit Schweregrad Hoch.“ Das ist eine komplett andere Aussagequalität.

Klassische End-to-End-Tests bleiben wertvoll. Für Regressionstests und die CI-Pipeline sind sie unverzichtbar. Aber KI-Agenten ergänzen sie um eine Dimension, die vorher nur manuellen Testern vorbehalten war: kontextbewusstes, exploratives Testen.

QA ist kein Luxus, sondern eine Checkliste

Wenn man sich anschaut, was QA im Alltag bedeutet, fällt auf: Ein großer Teil der Arbeit ist systematisches Abarbeiten bekannter Prüfpunkte. Nicht kreatives Problemlösen, sondern strukturiertes Durchgehen von Listen.

• Formulare: Pflichtfelder leer lassen, zu lange Eingaben, Sonderzeichen, Injection-Versuche
• Responsive: Mobile, Tablet, Desktop, verschiedene Bildschirmgrößen
• Error Handling: Netzwerkfehler, fehlende Daten, Timeouts
• Business-Logik: Negative Mengen, Rabatte über 100 %, Grenzwerte, Nullwerte

All das lässt sich als Checkliste formulieren. Und genau diese Grundarbeit kann automatisiert werden.

Das heißt nicht, dass QA-Arbeit simpel ist. Es heißt, dass die systematische Basisarbeit automatisiert werden kann, damit sich die Entwickler (die im kleinen Team den QA-Hut aufhaben) auf die wirklich kniffligen Fälle konzentrieren können: unerwartete Nutzungsszenarien, domänenspezifische Grenzfälle, UX-Intuition.

Spannend ist dabei: Gerade weil KI-Agenten stur und vollständig jede Checkliste auf jeder Maske durcharbeiten, finden sie durch Kombination auch Dinge, die im manuellen Test untergehen. Eine Blaupause von 50 Prüfpunkten, konsequent auf 30 Formulare angewandt, deckt Fehler auf, die niemand findet, weil niemand die Geduld hat, Prüfpunkt 47 auf Formular 28 zu testen.

Das Ergebnis ist kein Entweder-Oder. Automatisierung und menschliche Expertise zusammen sind stärker als jede Seite allein. Es ist Unterstützung, nicht Ersetzung.

Zwei Agenten, zwei Perspektiven

In der Praxis hat sich ein Muster bewährt: Statt eines einzelnen „Test alles“-Agenten arbeite ich mit zwei komplementären Rollen. Jede Rolle hat eine andere Perspektive auf die Anwendung, und zusammen decken sie ein breites Spektrum ab.

Der Adversarial Tester: Dinge kaputt machen

Die erste Rolle ist der Angreifer. Dieser Agent bekommt einen klaren Auftrag: Versuche, die Anwendung zu brechen. Finde Schwachstellen, die ein böswilliger Nutzer oder ein unaufmerksamer Bediener ausnutzen könnte.

Seine Checkliste umfasst typischerweise:

• Eingabemissbrauch: XSS-Versuche, SQL-Injection, extreme Zeichenlängen, Sonderzeichen in jedem Feld
• Zustandsmanipulation: Parallele Tabs mit derselben Session, Vor-/Zurück-Navigation mitten im Prozess, Session-Ablauf während einer Eingabe
• Autorisierungsumgehung: URL-Manipulation, direkte API-Aufrufe ohne Login, Zugriff auf fremde Ressourcen durch ID-Raten
• Visuelle Brüche: Extremdaten (sehr lange Namen, leere Felder, tausende Einträge), Darstellung bei unterschiedlichen Schriftgrößen
• Business-Logik-Missbrauch: Negative Werte, Boundary-Conditions (0, Maximum + 1), Rabatte über 100 %, doppeltes Absenden

Das Ergebnis ist ein strukturierter Bericht: Jedes Finding mit Schweregrad (Kritisch, Hoch, Mittel, Niedrig), Reproduktionsschritten und, wenn möglich, einem Screenshot.

Der Explorative Tester: Wie ein neuer Nutzer

Die zweite Rolle ist das Gegenteil: ein Agent, der die Anwendung zum ersten Mal nutzt. Kein Vorwissen, keine Annahmen. Sein Auftrag: Geh durch die App wie jemand, der sie gerade zum ersten Mal öffnet, und dokumentiere alles, was unklar, kaputt oder frustrierend ist.

Seine Checkliste umfasst:

• Navigation: Sind alle Links korrekt? Gibt es Sackgassen? Findet man zurück?
• Erste Nutzung: Ist klar, was man tun soll? Sind Formulare beschriftet? Gibt es Hilfestellungen?
• Fehlerverhalten: Was passiert bei Fehlern? Sind die Meldungen hilfreich oder kryptisch?
• Responsiveness: Funktioniert alles auf Mobile? Sind Buttons erreichbar? Bricht das Layout?

Das Ergebnis ist ein Usability-Report: weniger technisch, stärker auf das Nutzererlebnis fokussiert. Genau die Art von Feedback, die im Alltag oft untergeht, weil die Entwickler ihre eigene App zu gut kennen, um sie mit frischen Augen zu sehen.

Wie ein Report aussieht

Ein typisches Finding aus dem Adversarial Test könnte so aussehen:

Finding: Negative Stückzahl im Bestellformular

Schweregrad: Hoch

Seite: /bestellung

Beschreibung: Das Feld „Stückzahl“ akzeptiert negative Werte. Bei Eingabe von „-5“ wird das Formular ohne Fehlermeldung abgeschickt. Die Bestellung erscheint im System mit einer negativen Menge.

Reproduktion: 1. Bestellformular öffnen. 2. Produkt auswählen. 3. Im Feld Stückzahl „-5“ eingeben. 4. Auf „Bestellen“ klicken. 5. Formular wird abgeschickt.

Empfehlung: Clientseitige und serverseitige Validierung: Stückzahl muss eine positive Ganzzahl sein (mindestens 1).

Genau dieser Bug aus Bernds Freitagsrelease. Eine systematische Checkliste, die Grenzwerte auf Eingabefeldern prüft, hätte ihn in Sekunden gefunden. Bevor er beim Kunden landete.

Von der Checkliste zum Bericht: Der Workflow

Der praktische Ablauf lässt sich in vier Schritte zusammenfassen:

1. Qualitätskriterien als Checkliste definieren. Was soll geprüft werden? Eingabevalidierung, Responsiveness, Error Handling, Business-Logik. Die Checkliste muss nicht perfekt sein, sie muss nur existieren.
2. Checkliste dem Agenten als strukturierte Anweisung geben. Der Agent bekommt die Checkliste zusammen mit der URL der Anwendung und arbeitet sie Punkt für Punkt ab.
3. Agent arbeitet ab und dokumentiert Findings. Jedes Finding wird mit Schweregrad, Beschreibung und Reproduktionsschritten dokumentiert. Der Bericht ist sofort verwertbar.
4. Mensch reviewed, priorisiert und entscheidet. Der Agent findet, der Mensch bewertet. Nicht jedes Finding ist ein Bug. Nicht jeder Bug muss sofort gefixt werden. Die Entscheidung bleibt beim Team.

Der wichtigste Punkt dabei: Der Mensch bleibt in der Entscheidungsschleife. Der Agent ist ein Werkzeug, das systematisch prüft und dokumentiert. Die Bewertung, Priorisierung und Entscheidung, was wann gefixt wird, liegt beim Team.

In meinem Artikel „KI-gestützte Softwareentwicklung“ beschreibe ich den breiteren Kontext, wie KI-Werkzeuge den Entwicklungsalltag verändern. QA ist dabei ein besonders dankbarer Anwendungsfall, weil die Ergebnisse sofort messbar sind: weniger Bugs in Produktion, weniger Hotfixes am Montagmorgen.

Was sich ändert, wenn QA kein Engpass mehr ist

Wenn systematische QA nicht mehr davon abhängt, dass jemand manuell durch jede Maske klickt, verändert sich etwas Grundlegendes im Team: Vertrauen in den Release.

Teams, die vor jedem Release wissen, dass die Grundabsicherung automatisch gelaufen ist, shippen schneller. Nicht, weil sie nachlässiger werden, sondern weil die Angst vor dem unentdeckten Bug kleiner wird. QA wandelt sich von „macht keiner“ zu „läuft im Hintergrund.“

Ein konkreter erster Schritt: Nimm dir die drei häufigsten Fehlerquellen der letzten Monate vor. Fehlende Eingabevalidierung, kaputtes Layout auf Mobile, kryptische Fehlermeldungen. Was auch immer in deinem Projekt am häufigsten durchgerutscht ist. Und frag dich: Hätte eine einfache Checkliste das gefunden?

Die Antwort ist erfahrungsgemäß fast immer: ja. Und genau diese Checkliste lässt sich heute automatisieren.

Wenn du herausfinden möchtest, wie du KI-Agenten für QA und andere Entwicklungs-Workflows in deinem Team einsetzen kannst, kann ein KI-Coaching der richtige Startpunkt sein. Und wer sich das Thema KI-gestützte Produktivität generell erschließen will, findet in meinem Artikel „ChatGPT richtig nutzen“ einen praxisnahen Einstieg.

Alle in diesem Artikel verwendeten Namen von Personen und Unternehmen sind frei erfunden. Ähnlichkeiten mit real existierenden Personen oder Unternehmen sind rein zufällig und nicht beabsichtigt. Die Beispiele dienen ausschließlich der Veranschaulichung.