KI-Nutzung ist weit verbreitet, doch auf die richtige Kennzahl kommt es an
Die Umfrage von Stack Overflow aus dem Jahr 2025 ergab, dass 84 % der Befragten KI-Tools in ihrem Entwicklungsprozess verwendeten oder dies planen; Von den professionellen Entwicklern gaben 51 % an, sie täglich zu nutzen. Die Frage betrifft KI-Tools im Allgemeinen: Sie beweist nicht, dass dieser Prozentsatz Code generiert, und beschreibt auch nicht speziell QA-Teams.
Um einen Blick auf die andere Seite des Stroms zu werfen, veröffentlichte DeviQA im Juli 2026 eine eigene Umfrage unter 300 QS-Experten, SDET- und Testleitern. 52 % gaben an, dass sie eine Zunahme von Fehlern wahrgenommen hätten, seit die Entwicklung mit KI begonnen habe, und 58 % hätten eine höhere Testlast wahrgenommen. Dabei handelt es sich um ein relevantes Signal, das es zu untersuchen gilt, und nicht um eine repräsentative Schätzung des Sektors: Es handelt sich um eine interne Lieferantenstichprobe, die auf selbst gemeldeten Antworten und Erfahrungen basiert.
Die Umfrage von DeviQA fragt nach Veränderungen, die die Teilnehmer zeitlich mit der Einführung von KI in Verbindung bringen. Es vergleicht weder äquivalente Repositories mit und ohne KI, noch kontrolliert es Änderungsgröße, Erfahrung, Bereitstellungsgeschwindigkeit oder Überprüfungsrichtlinien. Es kann auch dazu führen, dass jetzt mehr Mängel erkannt oder gemeldet werden. Daher ist es nicht angebracht, den Schluss zu ziehen, dass KI allein eine allgemeine Zunahme von Fehlern verursacht.
DORA 2025 schlägt vor, KI als Verstärker des bestehenden Arbeitssystems zu verstehen: Schnelles Feedback, interne Plattformen und klare Prioritäten helfen; Auch schwache Prozesse und schwer überprüfbare Veränderungen werden verstärkt. Forschungsergebnisse berichten über Assoziationen, nicht über eine universelle Kausalregel. Die praktische Botschaft besteht darin, den gesamten Fluss zu messen und nicht die Variation einem einzelnen Werkzeug zuzuschreiben.
Was ist zu messen, bevor der Prozess geändert wird?
Zeichnen Sie über mehrere Iterationen hinweg auf, wie viele Änderungen vorgenommen wurden und welchen Umfang sie hatten. Wie viele Mängel treten vor und nach der Veröffentlichung auf? seine Schwere; wie oft ein Fall wiedereröffnet wird; Wie lange dauert es, bis die Qualitätssicherung den Empfang und die Antwort erhält? und wie viel Arbeit wiederholt wird. Separate Änderungen, die mit Hilfe von KI vorgenommen werden, nur dann, wenn das Team sie konsistent und ohne Überwachung jeder einzelnen Person identifizieren kann.
Vergleichen Sie Zeiträume sorgfältig: Verwenden Sie dieselben Definitionen, notieren Sie Produkt- oder Ausrüstungsänderungen und prüfen Sie, was die Tests erkennen und welche Warnungen sich als falsch herausstellen. Wenn mehr Änderungen veröffentlicht werden, kann sich die Gesamtzahl der Fehler erhöhen, obwohl jede Änderung weniger aufweist. Der Vergleich von Fehlern mit der Anzahl und dem Umfang der Änderungen hilft zu verstehen, was passiert ist.
Stellen Sie sich das vor, bevor das Team zehn Änderungen pro Woche veröffentlichte und vier Fehler feststellte; Nachdem er einen Assistenten hinzugefügt hat, veröffentlicht er zwanzig Änderungen und findet sechs. Die Gesamtzahl stieg, die Quote sank jedoch von 0,4 auf 0,3 Fehler pro Änderung. Ohne den Nenner vermischt die Überschrift „Es gibt mehr Fehler“ die Liefermenge mit der Qualität pro Einheit. Die Erkennung kann auch dadurch zunehmen, dass Tests, bessere Protokolle oder eine intensivere Überprüfung hinzugefügt wurden. In diesem Fall zeigt das Erkennen weiterer Ausfälle möglicherweise, dass das System besser funktioniert und nicht, dass das Produkt schlechter geworden ist.
Es ist zweckmäßig, vier Maßnahmen zu unterscheiden: vor der Veröffentlichung festgestellte Mängel; Mängel, die in die Produktion gelangt sind; Schweregrad und Auswirkungen; und die Kosten für deren Untersuchung und Korrektur. Das Auffinden weiterer kleinerer Probleme beim Testen bedeutet nicht, dass es zu mehr Benutzervorfällen kommt. Umgekehrt kann eine stabile Rate ein größeres Risiko bergen, wenn die Zahl der Änderungen zunimmt oder wenn sich Ausfälle auf Zahlungen, Berechtigungen oder Daten konzentrieren. Entscheiden Sie vor dem Vergleich, was Sie erzählen möchten.
Was bringt die Überprüfung des generierten Codes zusätzlich zur Durchführung von Tests?
Nur weil alle Tests bestanden wurden, ist das noch kein Beweis dafür, dass eine Änderung einfach zu verwalten ist, die Projektregeln einhält oder über ausreichende Tests verfügt. In einer Untersuchung im Jahr 2026 bat METR vier Betreuer aus drei Projekten, 296 von Agenten vorbereitete und durch eine automatisierte Bewertung genehmigte Änderungen zu überprüfen. Im Durchschnitt akzeptierten die Verantwortlichen weniger Änderungen als der Bewerter: Die Differenz betrug 24 Prozentpunkte. Die Stichprobe war begrenzt und die Agenten konnten ihre Vorschläge nach Erhalt der Kommentare nicht korrigieren; Das Ergebnis macht einen Unterschied deutlich: „Die Tests wurden bestanden“ und „Das Team ist bereit, die Änderung zu integrieren“ bedeuten nicht dasselbe.
Überprüfen Sie daher nicht nur, ob die Funktion das tut, was erwartet wird, sondern prüfen Sie auch, ob sich die Änderung auf andere Funktionen auswirkt, wie sie mit Fehlern umgeht, ob sie die Sicherheit respektiert und ob die neuen Tests das Problem wirklich erkennen. Ein generierter Test kann denselben Fehler wiederholen, den der Code aufweist. Jeder Test muss sich auf eine Anforderung beziehen und wird überprüft, um sicherzustellen, dass er fehlschlägt, wenn die Funktion, die er schützen sollte, entfernt wird.
Zeichnen Sie vier bis sechs Wochen lang eine Basislinie mit stabilen Definitionen auf und wählen Sie vergleichbare Änderungen nach Größe, Risiko und Komponente aus. Wenn das Team KI verwendet, kennzeichnen Sie die Änderung freiwillig und auf Jobebene, nicht auf Personenebene. Vergleichen Sie Gruppen oder Zeiträume, wenn möglich, notieren Sie gleichzeitige Änderungen – neue Abdeckung, Refaktorierung, Teamfluktuation – und normalisieren Sie sie anhand von Änderungen, geänderten Zeilen oder Exposition. Verwenden Sie nicht einen einzelnen Prozentsatz als Ziel: Dies kann dazu führen, dass Mängel verborgen oder die Abdeckung verringert werden.
Ein nützliches Dashboard zeigt, wie viele Mängel auftreten, wie schwerwiegend sie sind und in welchem Stadium sie erkannt werden; Wie viele erreichen die Produktion oder öffnen wieder? Wie lange dauert es, bis das Team eine Antwort erhält? und wie viele automatisierte Warnungen eine Person bestätigt. Bewahren Sie Beispiele auf, um zu verstehen, woher die Probleme kommen. Wenn das Team zwar schneller arbeitet, es aber in der Produktion zu gravierenden Mängeln kommt oder die Nacharbeit zunimmt, hat sich der Prozess nicht verbessert. Wenn Sie vor der Veröffentlichung mehr erfassen und weniger in die Produktion gelangen, können Sie Probleme jetzt möglicherweise besser finden.
Eine aktuelle Umfrage weist auf mehr QA-Aufwand hin
Eine separate Umfrage von DeviQA, die im September 2026 veröffentlicht und von 4.000 QA-Experten beantwortet wurde, hilft, das andere Ende des Flusses zu beschreiben. 65 % gaben an, dass Funktionen schneller getestet werden; 64 % gaben an, dass mehr Funktionen gleichzeitig eintreffen; 55 % beobachteten einen längeren QA-Schwanz; und 52 % berichteten über mehr Test-Korrektur-Retest-Zyklen. Diese Zahlen sollten nicht mit der vorherigen Befragung von 300 Personen verwechselt werden: Es handelt sich um unterschiedliche Instrumente, Stichproben und Fragen. Sie messen auch keine Fehler pro Änderung und beweisen auch nicht, dass KI die Ursache ist. Sie zeigen eine konkrete Spannung, die ein Team überprüfen kann: Eine schnellere Bereitstellung eliminiert nicht die Überprüfung, Regression oder Koordination und kann die Arbeit, die die Qualitätssicherung erhält, konzentrieren.
Die praktische Konsequenz besteht darin, nicht mehr Blindtests zuzuordnen. Es lohnt sich zu fragen, wo sich die Warteschlange bildet: Warten auf die Umgebung, unvollständige Anforderungen, verspätete Überprüfung, Daten, die schwer aufzubereiten sind, zeitweise Ausfälle oder zu viele unbestätigte Warnungen. Jede Ursache erfordert eine andere Reaktion. Wenn das Team nicht weiß, wann eine Lieferung ankommt oder was sich geändert hat, kann ein zweites KI-Tool für zusätzlichen Lärm sorgen; Wenn Sie den Unterschied, das Risiko und das erwartete Ergebnis kennen, können Sie besser Prioritäten setzen. Es misst die Wartezeit getrennt von der effektiven Testzeit: So unterscheidet man ein Kapazitätsproblem von einem Flussproblem.
Eine absolute Zahl gibt Auskunft darüber, wie viele Mängel gefunden wurden; Es allein gibt keinen Hinweis darauf, ob jede Änderung schlechter ist. Angenommen, ein Team überprüft zehn Änderungen und stellt vier Mängel fest. Anschließend überprüft es zwanzig und stellt sechs fest. Die Summe stieg, aber der Wechselkurs fiel. Selbst dieser Satz kann irreführend sein, wenn die neuen Änderungen größer sind, andere Komponenten betreffen oder mehr Abdeckung erhalten. Verwenden Sie je nach Entscheidung verschiedene Nenner: überarbeitete Änderungen für Triage-Last, Größe und Risiko zum Vergleich der Exposition, Ausführungen für Stabilität und Benutzer oder Transaktionen zur Abschätzung der Auswirkungen. Machen Sie Codezeilen nicht zu einem universellen Qualitätsmaßstab: Sie dienen als Kontext und nicht als Ersatz für Funktionsrisiken.
Außerdem wird zwischen Schweregrad, Zeitpunkt der Erkennung und Kosten unterschieden. Ein vor der Freigabe festgestellter Blockierungsfehler kann ein Zeichen dafür sein, dass die Tests funktionieren. Ein geringfügiger Fehler in der Produktion kann weniger schwerwiegend sein als ein Berechtigungsfehler, obwohl beide als „Fehler“ gelten. Notieren Sie, ob das Problem in den Anforderungen, der Implementierung, der Integration, den Daten oder der Umgebung lag. Diese Klassifizierung dient dazu, den Prozess zu korrigieren und nicht dem Autor oder dem Tool die Schuld zu geben. Bewahren Sie repräsentative Beispiele auf und überprüfen Sie, was sich zwischen den Perioden geändert hat. Eine Metrik ohne Erläuterung des Sachverhalts kann das Team dazu veranlassen, die falsche Zahl zu optimieren.
So bewerten Sie ein Tool anhand von Kriterien, um es zu verwerfen
Bevor Sie KI zum Zyklus hinzufügen, definieren Sie eine Frage, die eine negative Antwort zulässt: zum Beispiel: „Reduzieren storybasierte Tests Auslassungen, ohne die Überprüfungszeit zu verlängern?“ Wählen Sie einen begrenzten Ablauf, legen Sie eine Basislinie fest und vereinbaren Sie, was als Überspringen, Duplikat, gültige Warnung und Überarbeitung gilt. Vergleichen Sie mehrere Iterationen und Änderungen mit ähnlichem Risiko. Wenn möglich, alternative Aufgaben oder Teams; Wenn nicht, beachten Sie die Änderungen in Bezug auf Abdeckung, Personal, Release und Tools, die einen Unterschied erklären könnten. Führen Sie keine Kausalität auf einen Vorher-Nachher-Vergleich zurück, wenn gleichzeitig andere Änderungen stattgefunden haben.
Kontrolliertes Testen erfordert auch eine Stoppregel. Wenn das Tool nicht über ausreichend Kontext verfügt, reale Daten ohne Autorisierung verwendet, eine nicht isolierte Umgebung verändert oder Ergebnisse liefert, die niemand reproduzieren kann, sollte es gestoppt und bis zur Ausführung gewartet werden. Die menschliche Überprüfung konzentriert sich auf relevante Risiken und akzeptiert nicht alles, was das Modell generiert. Zum Abschluss werden die Ergebnisse zusammen mit den Probengrenzen, Fehlalarmen, entgangenen Fehlern und den Zeitkosten für die Überprüfung angezeigt. Wenn die Daten keine Schlussfolgerung stützen, handelt es sich um eine gültige Schlussfolgerung: Der nächste Schritt besteht darin, die Messung zu verbessern und nicht darin, einen Erfolg zu verkünden.
Eine automatische Warnung ist eine Beobachtung, die noch klassifiziert werden muss. Es kann auf einen neuen Fehler, eine bekannte Regression, einen nicht beeinträchtigenden visuellen Unterschied, ein Umweltproblem oder einen Test hinweisen, der nicht mehr das erwartete Verhalten widerspiegelt. Wenn das Dashboard alles als „Fehler“ auflistet, scheint das Tool mehr Probleme zu finden, obwohl es sich bei den meisten davon um Duplikate oder Rauschen handelt. Behält unterschiedliche Status für erhaltene, überprüfte, reproduzierbare, bestätigte, duplizierte und verworfene Ergebnisse bei; Außerdem wird der Grund für die Verwerfung erfasst. Auf diese Weise kann das Team die Genauigkeit und Kosten der Triage messen, ohne ein gültiges Signal unter einem Durchschnitt zu verbergen.
Die Analyse muss auch die Zeit berücksichtigen. Ein in wenigen Minuten erkannter Fehler verursacht nicht die gleichen Kosten wie ein Bericht, der am Ende einer nächtlichen Suite erscheint; Auch eine korrekte Warnung, die erst nach der Veröffentlichung jemand sieht, verbessert die Prävention nicht. Beachten Sie, wie lange es gedauert hat, bis das System einen Bericht erstellt hat, wann jemand es überprüft hat und wann es geschlossen wurde. Wenn die reine Anzahl der Warnungen zunimmt, der bestätigte Prozentsatz jedoch sinkt und die Überprüfungszeit zunimmt, sollte das nächste Experiment die Auswahl und den Kontext verbessern und nicht noch mehr Fälle generieren. Wenn die Früherkennung relevanter Mängel zunimmt und die Nacharbeit abnimmt, ist das Signal der Nützlichkeit stärker.