So führen Sie QA-Agenten bei jedem Pull Request mit QA.tech aus (ohne ein einziges Testszenario zu schreiben)
Wenn Ihr Team KI-Programmierwerkzeuge eingeführt hat, kennen Sie die unangenehme Rechnung bereits. Entwicklungsteams, die zuvor eine Handvoll Pull Requests pro Woche veröffentlicht haben, veröffentlichen jetzt fünfzig, hundert, manchmal noch mehr – vieles davon wurde von Programmieragenten geschrieben, von Code-Review-Agenten geprüft und in einem Tempo zusammengeführt, für das kein manueller QA-Prozess ausgelegt war. Ein Team, mit dem wir kürzlich gesprochen haben, hatte gerade seine ersten fünfzig vollständig von Agenten geschriebenen PRs abgeschlossen und stellte uns die naheliegende Frage: Was überprüft das alles?
Die traditionelle Antwort – mehr Testskripte schreiben – hält diesem PR-Volumen nicht stand. Das Erstellen und Pflegen von Skripten dauert länger, als agentengeschriebener Code für seine Erstellung benötigt, sodass die Testsuite bereits am ersten Tag hinterherhinkt und nie wieder aufholt.
Dieser Leitfaden zeigt die Alternative, die wir bei QA.tech entwickelt haben: die Verbindung unserer QA-Agenten mit Ihrem Repository, sodass jeder Pull Request zielbasierte Tests auslöst, die sich selbst aus den Änderungen ableiten. Kein Testcode, keine Selektoren, keine Warteschlange für die Pflege. So richten Sie das Ganze ein und damit können Sie bei jedem Schritt rechnen.
Schritt 1: Lassen Sie den Agenten zunächst Ihre Anwendung kennenlernen
Bevor die PR-Integration etwas Sinnvolles leisten kann, muss der Agent Ihr Produkt kennen. Wenn Sie QA.tech mit Ihrer Staging- oder Sandbox-Umgebung verbinden, führt es einen ersten Crawl durch: Es erkundet die Anwendung wie ein gewissenhafter neuer Mitarbeiter, folgt jedem auffindbaren Pfad und jeder möglichen Aktion und erstellt daraus einen Wissensgraphen darüber, wie Ihr Produkt strukturiert ist.
Zwei praktische Hinweise aus Hunderten von Einführungen. Erstens: Wenn sich Ihre Anwendung hinter einer Anmeldung befindet, richten Sie den Anmeldevorgang als vorausgesetzten Testfall ein – der Agent führt ihn zuerst aus und durchsucht anschließend alles dahinter. Zweitens bestimmen Sie die Crawling-Tiefe. Ein flacher Crawl (ein oder zwei Schritte tief in jede Benutzerreise) ist schnell und reicht normalerweise für den Anfang aus; für die wichtigsten Abläufe können Sie die Tiefe erhöhen, anstatt zunächst alles vollständig abzubilden.
Dieser Schritt ist der eigentliche Grund, warum die PR-Integration funktioniert. Weil der Agent jede Ecke der Anwendung kennt, kann er überlegen, welche Auswirkungen eine bestimmte Änderung haben könnte – genau das Urteilsvermögen, das ein guter QA-Ingenieur anwendet, wenn er entscheidet, was vor einer Veröffentlichung überprüft werden muss.
Schritt 2: Verbinden Sie das Repository
Die GitHub-Integration ist in wenigen Minuten eingerichtet: Autorisieren Sie die App, wählen Sie die Repositories aus und legen Sie fest, wann Tests ausgelöst werden sollen – typischerweise bei der Erstellung oder Aktualisierung eines Pull Requests. GitLab-Merge Requests funktionieren nach demselben Prinzip. Von diesem Zeitpunkt an ist das Testen Bestandteil Ihrer Pipeline und keine Phase mehr, die danach stattfindet.
ist in wenigen Minuten eingerichtet: Autorisieren Sie die App, wählen Sie die Repositories aus und legen Sie fest, wann Tests ausgelöst werden sollen – typischerweise bei der Erstellung oder Aktualisierung eines Pull Requests. GitLab-Merge Requests funktionieren nach demselben Prinzip. Von diesem Zeitpunkt an ist das Testen Bestandteil Ihrer Pipeline und keine Phase mehr, die danach stattfindet.Schritt 3: Öffnen Sie einen Pull Request und beobachten Sie, was passiert
Wenn ein PR geöffnet wird, liest der Agent, was hinzugefügt und geändert wurde, gleicht dies mit seinem Wissensgraphen ab und erstellt die Testfälle, die durch die Änderung gerechtfertigt sind – bei einem gewöhnlichen PR typischerweise vier oder fünf, bei Änderungen an gemeinsam genutzten Abläufen mehr. Anschließend führt er sie sofort in einem echten Browser aus und interagiert visuell mit dem aktualisierten Build, genau wie ein Benutzer.
Das ist der Teil, der Teams überrascht, die an durch CI ausgelöste Testsuiten mit Skripten gewöhnt sind: Niemand hat diese Testfälle erstellt. Sie wurden aus der Änderung selbst abgeleitet, im Kontext all dessen, was der Agent bereits über Ihr Produkt weiß. Wenn Sie einen neuen Filter in Ihrem Dashboard veröffentlichen, testet der Agent den Filter und die Dashboard-Abläufe, in die er eingebettet ist. Niemand musste daran denken, eine Testabdeckung hinzuzufügen.
Schritt 4: Lesen Sie die Ergebnisse dort, wo Ihre Ingenieure bereits arbeiten
Bestanden oder fehlgeschlagen – das Ergebnis erscheint direkt im PR. Für jeden Durchlauf erstellt der Agent einen Bewertungsbericht: das Ziel, das erwartete Ergebnis, was tatsächlich passiert ist, ein Video des Durchlaufs, Screenshots zu jedem Schritt sowie die darunterliegenden Konsolen- und Netzwerkprotokolle. Ein Fehlschlag ist kein rotes X, dessen Ursache erst mühsam rekonstruiert werden muss – es ist eine schriftliche Erklärung dessen, was der Agent zu sehen erwartete und was er stattdessen gesehen hat.
Da der Agent über die Benutzeroberfläche testet, meldet er Fehler auf Produktebene – er teilt Ihnen mit, dass der Rabattcode beim Bezahlvorgang nicht mehr angewendet wird, und fügt die entsprechenden Belege an. Dieser Kontext auf Produktebene ist genau das, was Ihre Ingenieure – oder Ihre Programmieragenten – benötigen, um die Ursache zu finden und zu beheben. Teams, die agentenbasierte Entwicklungszyklen einsetzen, geben unsere Bewertungsberichte direkt als Fehlerkontext für die Behebung an ihre Programmieragenten zurück – und mit der MCP-Integration können diese Programmieragenten selbst Testläufe auslösen, während sie arbeiten.
Schritt 5: Regressionstests zusätzlich zu PR-Tests durchführen
Durch PR ausgelöste Tests überprüfen die Änderung. Regressionspläne überprüfen alles andere. In QA.tech gruppierst du Testfälle in Pläne – eine Rauchtestsuite für jede Bereitstellung, eine vollständige Regression vor wichtigen Releases – und führst sie in dem Rhythmus aus, der zu deinem Release-Prozess passt.
Da die Tests parallel ausgeführt werden, beträgt die tatsächliche Zeit nur einen Bruchteil dessen, was dieselbe Abdeckung manuell kosten würde. Ein kürzlich von uns ausgeführter vollständiger Regressionsplan umfasste ein Testvolumen, das einen manuellen Tester ein oder zwei Tage beschäftigt hätte; er war in etwa zwanzig Minuten abgeschlossen. Dieser Unterschied macht aus „die vollständige Regression bei jedem Release ausführen“ eine tatsächliche Richtlinie statt eines bloßen Anspruchs.
Schritt 6: Frage den Agenten, wo deine Abdeckung Lücken aufweist
Da der Wissensgraph jeden vom Crawl entdeckten Ablauf abbildet, kennt die Plattform den Unterschied zwischen dem, was dein Produkt enthält, und dem, was deine Tests abdecken. Du kannst direkt im Chat fragen: „Welche Abläufe mit dem höchsten Wert werden derzeit nicht von unseren Tests abgedeckt?“ Der Agent antwortet auf Grundlage seiner Karte deines Produkts und kann die fehlenden Tests sofort erstellen.
Damit wird die übliche Dynamik der Testabdeckung umgekehrt. Statt dass die Abdeckung einfach aus dem besteht, was sich über Jahre durch das Schreiben von ticketgesteuerten Tests angesammelt hat, wird sie zu einer Frage, die du noch am selben Nachmittag stellen und auf die du reagieren kannst.
So sieht es nach einem Monat aus
Das Muster, das wir bei Teams beobachten, ist einheitlich. In der ersten Woche gibt es etwas Hin und Her – der Agent stellt Fragen, benötigt gelegentlich Kontext zu den Besonderheiten deines Produkts, und du korrigierst sein Verständnis. In der zweiten Woche sind Fragen selten. In der dritten Woche sind sie größtenteils verschwunden, weil der Wissensgraph verstanden hat, wie dein Produkt funktioniert. Danach laufen die Tests im Tempo deiner Pull-Requests, und die beteiligten Menschen überprüfen die Ergebnisse, statt Skripte zu pflegen. Wenn du die vollständige Einführungssequenz möchtest – vom Machbarkeitsnachweis bis zur Ablösung deiner bisherigen Testsuiten – haben wir sie als Praxisleitfaden veröffentlicht: Agentenbasiertes Testen einführen: Der Leitfaden.
Für Teams, die den Schritt zu von Agenten geschriebenem Code gemacht haben, schließt dies die bisher fehlende Verbindung: Codegenerierung, Codeprüfung und Verifizierung laufen alle im Maschinentempo, wobei deine Ingenieure das System steuern, anstatt es mit Eingaben zu versorgen.
FAQ
Wie viele Testfälle generiert QA.tech pro Pull-Request?
Ein gewöhnlicher PR erzeugt typischerweise vier bis fünf Testfälle, abgeleitet aus den vorgenommenen Änderungen. Größere Änderungen, die gemeinsam genutzte Abläufe berühren, erzeugen mehr.
Erfordern PR-Tests vorhandene Testfälle?
Nein. Der Agent generiert Testfälle aus der Änderung und seinem Wissen über deine Anwendung. Teams, die mit einer Testabdeckung von null beginnen, können auf PR-Ebene starten und im Laufe der Zeit Regressionspläne aufbauen.
Was passiert, wenn sich die Benutzeroberfläche in einem Pull-Request ändert?
Der Agent arbeitet mit Zielen und visueller Analyse statt mit Selektoren. Daher führt er den Test gegen die neue Oberfläche aus und meldet nur dann einen Fehler, wenn das Verhalten selbst fehlerhaft ist.
Welche CI/CD-Setups unterstützt die PR-Integration von QA.tech?
GitHub-Pull-Requests und GitLab-Merge-Requests sind die wichtigsten Integrationspunkte. Die Ergebnisse werden als Prüfung wieder in den PR zurückgemeldet.
Sieh dir an, was QA-Agenten für deinen nächsten Pull-Request generieren – verbinde ein Repository mit QA.tech und führe den ersten Test in wenigen Minuten aus.
