Vor drei Monaten hätte ich gesagt, mein Job ist, Code zu prüfen. Tests schreiben, Edge Cases abdecken, am Ende der Pipeline sitzen und entscheiden: durch oder zurück. Heute ist das nicht mehr mein Job. Und das ist keine Klage — es ist ein Befund.

Das klassische QA-Modell funktioniert, solange der Output deterministisch ist: Du gibst eine Eingabe rein, erwartest eine definierte Ausgabe, testest darauf. Aber wenn das System, das du testest, ein Agent ist — ein LLM-gestützter Workflow, der bei jedem Lauf leicht unterschiedliche Ergebnisse produziert — dann ist `assert output == "expected"` nicht mehr dein Werkzeug. Du testest nicht mehr ein Ergebnis. Du testest ein System, das Ergebnisse produziert.

QA ist tot. Lang lebe QA.

Das ist die provokative These: Die traditionelle QA-Rolle, die am Ende der Linie sitzt und qua Approval-Gate funktioniert, ist tot. Sie funktioniert nicht mehr, weil der Output nicht-deterministisch ist und die Pipeline nicht mehr linear. Was an ihre Stelle tritt, ist etwas anderes, etwas Größeres. Nicht die Architektin selbst — aber die Wächterin der Architektur.

Die Frage verschiebt sich. Nicht mehr: Ist der Output korrekt? Sondern: Ist dieser Workflow überhaupt geeignet, Qualität zu garantieren? Das ist eine strukturelle Frage, keine Ergebnisfrage. Und sie wird beantwortet, bevor die erste Zeile Code geschrieben wird.

Die Wächterin des Prozesses

Das ist der Punkt, an dem QA von der Testerin zur Hüterin des Prozesses wird. Sie entwirft die Phasen *mit*, definiert die Gates, formuliert die Anweisungen, die den Prozess regieren — nicht allein, sondern als Teil des Teams. QA ist nicht die Alleinarchitektin. QA ist die Instanz, die wachsam bleibt, ob die gemeinsam gebaute Architektur auch trägt.

In einem typischen agentischen Workflow gibt es vier Phasen: Plan → Implement → Code Review → QS → Done. Jede Phase hat ein Quality Gate. QA hat nicht nur Phase 4 besetzt — QA hat den gesamten Flow von Tag 0 an mitgestaltet.

Die Prozessanweisungen zum Beispiel — das ist kein Dev-Dokument. Das ist ein QA-Dokument. Es definiert, wie gearbeitet wird, nicht was herauskommen soll.

QA sitzt nicht mehr am Quality Gate. QA wacht über die Architektur.

Workflow-Design als Qualitätsversprechen

Der Workflow ist das Produkt. Nicht der Code, der durch ihn entsteht, sondern der Prozess, der ihn produziert. Wenn der Prozess gut ist, ist der Code gut. Wenn der Prozess schlecht ist, ist der Code Glückssache.

Das klingt abstrakt, ist aber in der Praxis brutal konkret. In einer Workflow-Chain hat jeder Task vier Phasen. Plan definiert, was gebaut wird. Implement baut es. Code Review prüft es. QS gibt frei. Ist eine Phase schwach — Plan unklar, Review nur Grünfärbung — dann fällt der Output durch. Jedes Mal.

Was passiert, wenn man Gates weglässt? Ich habe es gesehen. Wenn Implement ohne Plan arbeitet, baut jemand schnell das Falsche. Wenn Review übersprungen wird, landet Code im main, den niemand gelesen hat. Wenn QS fehlt, geht halbfertiges Zeug live. Das ist keine Theorie — das ist gelebte Erfahrung.

Benchmarks für Prozesse, nicht für Output

Der Shift, der hier passiert: QA vergleicht nicht mehr Outputs, sondern Prozesse. Flow A — drei Phasen, keine Review — produziert viermal so viele Reverts wie Flow B — vier Phasen mit Review. Das ist eine messbare Aussage, und sie hilft, den nächsten Prozess besser zu designen.

Metriken, die zählen:

In einem gut instrumentierten Workflow-System liegen diese Daten in den Run-Metadaten. Die Frage ist nicht, ob ein Worker gut arbeitet, sondern ob der Workflow, in dem er arbeitet, gut designed ist.

Workflow-Integrität überwachen

Wurde der definierte Workflow eingehalten? Phase 3 übersprungen? Gemerged ohne QS-Freigabe? Das sind Qualitätsvorfälle, keine Prozess-Kosmetik. Das Workflow-System trackt diese Abweichungen als Events — und die Events sind die Datenbasis für kontinuierliche Prozessverbesserung.

Wenn ein Worker den Review übersprungen hat, ist das nicht „nur eine Abweichung“ — das ist ein Signal. Entweder der Review-Prozess ist zu schwerfällig (dann redesign), oder der Worker hat die Disziplin nicht (dann Coaching, nicht Pragmatismus). Die Integritätsfrage ist nicht „war das Ergebnis ok?“, sondern „wurde der Weg dorthin eingehalten?“. Beides ist Quality. Letzteres ist vorausschauend.

Shift-Left bis ins Design

Shift-Left heißt nicht „früher testen“, sondern „früher mitdesignen“. QA sitzt am Anfang, nicht am Ende. Beim Aufsetzen eines neuen Projekts ist der erste Schritt: Wie wollen wir hier Qualität sicherstellen? Nicht: Was testen wir am Ende? Die Antwort auf diese Frage ist der Workflow selbst.

Diese Frage zu stellen, bevor Code existiert, ist der Moment, in dem QA zur Co-Designerin wird. Sie entwirft das Qualitätssicherungssystem *mit*, nicht nur seinen Endpunkt. Die Workflow-Spezifikation ist ein Tag-0-Artefakt — geschrieben, bevor der erste Commit landet.

QA 2.0

Das ist die Transformation: von der Testerin zur Wächterin, von der Gatekeeperin zur Hüterin der Architektur. Die QA-Rolle verschwindet nicht — sie wird strategischer. Sie wandert nach links in die Design-Phase und nach oben in die Leadership. QA in Support-Rollen ist verschwendetes Potenzial.

Fangt an, Workflows zu designen, nicht nur Ergebnisse zu prüfen. Setzt QA in die Planungsphase, nicht ans Release-Gate. Schreibt Prozessanweisungen und behandelt sie als das, was sie sind: QA-Dokumente.

QA ist tot. Lang lebe QA.