Qualität funktioniert am besten wenn sie Teil der Ausführung ist. Nicht ein Gate danach.

Ein Bug der in der Produktion gefunden wird hat bereits eine Reise hinter sich. Code wurde geschrieben. Reviews wurden gemacht. Tests wurden durchgeführt. Ein Release wurde gebaut. Ein Deployment hat stattgefunden. Und dann findet ihn der Kunde. Zu diesem Zeitpunkt hat das Problem nicht nur Zeit und Geld gekostet. Es hat auch das Vertrauen des Kunden in Anspruch genommen. Und die nächsten Schritte – Support, Hotfix, Kundenkommunikation, Postmortem – sind bereits in Bewegung bevor irgendjemand die eigentliche Frage gestellt hat: Warum wurde das nicht früher gefunden? Qualitätssicherung die nur am Ende des Prozesses sitzt schützt nicht. Sie bestätigt was bereits passiert ist. Was in der Softwareentwicklung wirklich schützt ist Qualität die nah an der Arbeit sitzt. Code Reviews die wirklich gelesen werden – nicht abgenickt. Unit Tests die unmittelbar nach dem Schreiben laufen – nicht als letzter Schritt vor dem Merge. Statische Codeanalyse die direkt in der IDE warnt – nicht erst in der Pipeline. Definition of Done die jeder im Team kennt und anwendet – nicht als Dokument das beim letzten Sprint-Review erstellt wurde. Die Fragen die sich jedes Entwicklungsteam stellen sollte sind konkret: Wer hat die Befugnis einen Merge zu stoppen wenn etwas nicht stimmt? Wo im Prozess entsteht der Fehler typischerweise – und wo wird er gefunden? Und was müsste sich ändern damit diese beiden Punkte näher beieinander liegen? Ein Fehler der im Code Review gefunden wird kostet dreißig Minuten. Derselbe Fehler beim Kunden kostet – wie wir bereits nachgerechnet haben – ein Vielfaches davon. Der Unterschied liegt nicht in der Schwere des Fehlers. Er liegt darin wo im Prozess jemand hingeschaut hat. Qualität funktioniert am besten wenn sie Teil der Ausführung ist. Nicht ein Gate danach.