Qualität gehört denen, die liefern

Eine Null-Bug-Politik macht Schluss mit der Verwaltung von Defektbeständen.

Aber sie reicht nicht.

Wenn das Team Bugs schneller behebt, ohne die Art der Produktion zu ändern, bleibt es in einer Reparaturschleife. Das Backlog schrumpft, wächst dann wieder. Notfälle verschwinden, kehren dann zurück. Der Support atmet auf, läuft dann wieder voll.

Das eigentliche Thema liegt vorher.

Wie lässt sich die Anzahl der Bugs von vornherein reduzieren?

Bugs reduziert man nicht allein durch bessere Triage-Organisation. Man reduziert sie, indem man die Verantwortung bei denen verankert, die liefern, indem man zu vage Spezifikationen ablehnt, früher testet und QA eine Rolle als Qualitätspolitik statt als Sicherheitsnetz gibt.

Qualität ist nichts, das man nachträglich delegiert.

Qualität gehört denen, die liefern.

Bugs anderer beheben verwässert die Verantwortung

In vielen Teams sieht die Organisation so aus.

Ein Entwickler arbeitet an einer Feature. Er liefert. Er wechselt zum nächsten Thema. Bugs tauchen auf. Da er schon beschäftigt ist, übernimmt jemand anderes. Ein verfügbarer Entwickler. Eine Rotationsperson. Ein technisches Support-Team. Manchmal ein Team, das ausschließlich für Bugs zuständig ist.

Auf dem Papier wirkt das effizient. Man optimiert die Verfügbarkeit.

In Wirklichkeit verwässert man die Verantwortung.

Wer den Defekt eingeführt hat, sieht nicht immer die Kosten dessen, was er geliefert hat. Wer behebt, muss einen Kontext verstehen, den er nicht geschaffen hat. Der verlorene Aufwand wird kollektiv — und damit weniger sichtbar. Und jeder kann sich hinter einem klassischen Satz schützen: „Ich war schon beim nächsten Thema."

Dieses System sendet ein falsches Signal.

Es sagt implizit: Du kannst liefern — und wenn etwas bricht, fängt es jemand anderes auf.

Auch wenn niemand es so formuliert, der Effekt ist real.

Wer den Bug erzeugt, behebt ihn

Die gesündeste Regel ist einfach: Wer den Bug erzeugt, behebt ihn.

Nicht um zu bestrafen.

Nicht um zu beschämen.

Sondern weil die Verantwortung für die Korrektur mit der Verantwortung für die Produktion verbunden bleiben muss.

Wenn ein Entwickler weiß, dass seine Bugs direkt zu ihm zurückkommen, liefert er anders. Er testet mehr. Er überprüft sorgfältiger. Er vermeidet es, eine fragile Änderung nur wegen eines Termins einzuspielen. Er akzeptiert es weniger leicht, bei starker Unklarheit zu produzieren.

Das ist keine Garantie. Aber es ist ein gesunder Anreiz.

Natürlich gibt es Ausnahmen.

Der Entwickler kann abwesend sein. Der Bug kann aus mehreren Beiträgen stammen. Das Problem kann im Legacy-Code liegen. Die Verantwortung kann geteilt sein. Eine andere Person kann manchmal besser positioniert sein, um zu korrigieren.

Diese Fälle gibt es.

Aber sie dürfen nicht zur Ausrede werden, die allgemeine Regel aufzugeben.

In den meisten Fällen muss ein Entwickler, der den Defekt erzeugt hat, ihn beheben. Auch wenn er schon an einem wichtigen Thema arbeitet. Auch wenn das die Planung stört. Auch wenn das die nächste Feature verlangsamt.

Qualität kostet Kapazität. Sie zu verstecken macht sie nicht kostenlos.

Verantwortung ist nicht Schuld

Hier muss man zwischen Verantwortung und einer Kultur der Schuldzuweisung unterscheiden.

Verantwortung zu verankern bedeutet nicht, einen Schuldigen zu suchen. Es bedeutet nicht, öffentlich zeigen, wer etwas kaputtgemacht hat. Es bedeutet nicht, Angst vor dem Liefern zu erzeugen.

Eine Kultur der Schuldzuweisung zerstört die Qualität. Probleme werden versteckt, Defekte minimiert, Risiken gemieden, Dokumentation als Selbstschutz produziert — und das Team lernt langsamer.

Nützliche Verantwortung ist anders.

Sie sagt: Du bist Eigentümer dessen, was du lieferst — du beteiligst dich also an der Korrektur, dem Lernen und der Verbesserung.

Es geht nicht ums Bestrafen. Es geht darum, den Kreislauf zu schließen.

Der Entwickler, der seinen eigenen Bug behebt, versteht besser, was schiefgegangen ist. Er sieht, wo sein Verständnis unzureichend war. Er sieht, ob der Test fehlte. Er sieht, ob die Spec unklar war. Er sieht, ob die Architektur den Fehler wahrscheinlich machte.

Genau dieser Kreislauf erzeugt Qualität.

Entwickler sind keine Ausführenden

Diese Verantwortung setzt eine weitere Idee voraus: Entwickler sind keine Ausführenden.

Sie sind nicht dazu da, „Code zu schaufeln".

Sie sind Wertschöpfer.

Der Product Manager ist verantwortlich für Produktentscheidungen: warum dieses Thema, für welche Zielgruppe, mit welchem Impact, mit welcher Priorität. Aber die Entwickler sind verantwortlich für die technische Qualität, die Codebasis und das, was sie liefern.

Jeder hat seinen Verantwortungsbereich.

Wenn der Product Manager eine schlechte Produktentscheidung trifft, muss er sie verantworten.

Wenn Entwickler fragilen, wenig getesteten, schlecht verstandenen oder schwer wartbaren Code liefern, müssen sie das ebenfalls verantworten.

Das bedeutet nicht, dass die Verantwortlichkeiten isoliert sind. Sie stehen im Dialog. Ein gutes Produkt entsteht im Gespräch zwischen Produktentscheidungen, Machbarkeit, Nutzung, Qualität und technischen Einschränkungen.

Aber der Dialog darf nicht dazu dienen, Verantwortung aufzulösen.

Eine zu vage Spezifikation muss abgelehnt werden

Ein Defekt kommt nicht immer aus schlechtem Code.

Er kann aus einer unvollständigen Spezifikation stammen, aus einer mehrdeutigen Produktentscheidung, aus einem nicht bedachten Fall, aus einem schlecht verstandenen Ablauf.

Aber das bedeutet nicht, dass niemand verantwortlich ist.

Wenn eine Spec zu vage ist, müssen Entwickler die Umsetzung ablehnen können.

Ablehnen heißt nicht blockieren. Es heißt: Der Rahmen ist nicht klar genug, um korrekt zu liefern.

Es ist besser, vor dem Codieren eine Klärung einzufordern, als eine wackelige Funktionalität zu bauen, die später Bugs, Support, Rework und endlose Diskussionen erzeugt.

Ein verantwortungsvoller Entwickler führt keinen mehrdeutigen Auftrag einfach aus. Er versucht zu verstehen: Was ist das erwartete Verhalten? Was sind die Grenzfälle? Was sind die Abnahmekriterien, die Risiken, die Daten, die Abhängigkeiten?

Wenn er nicht versteht, was er liefern soll, kann er die Qualität des Gelieferten nicht gewährleisten.

Produktverantwortung und technische Verantwortung treffen sich hier: Der Product Manager muss die Produktentscheidung klären; die Entwickler müssen ablehnen, eine starke Mehrdeutigkeit in fragilen Code zu verwandeln.

TDD: das Was vor dem Wie

TDD, Test Driven Development, ist eine konkrete Antwort auf diese Logik.

Statt zuerst den Code zu schreiben und danach zu prüfen, ob er funktioniert, schreibt man zuerst den Test.

Der Test beschreibt das Was.

Der Code implementiert das Wie.

Das ist ein wichtiger Unterschied. Der Test formalisiert einen Teil der Spezifikation: Das ist das erwartete Verhalten, das ist, was wahr bleiben muss, das ist, was nicht brechen darf.

Danach kann der Code weiterentwickelt werden. Er kann refaktoriert werden. Er kann mit neuen Daten interagieren. Andere Funktionalitäten können darum herum entstehen. Aber wenn das erwartete Verhalten bricht, schlägt der Test fehl.

Im Idealfall wird das Problem beim Entwickler oder in der Qualifizierung erkannt — nicht in der Produktion.

TDD beseitigt nicht alle Bugs. Es ersetzt kein Produktdenken. Es verwandelt keine schlechte Spec in ein gutes Produkt.

Aber es ändert etwas Wesentliches: Es zwingt dazu, einen Teil der Qualität vor der Implementierung überprüfbar zu machen.

In einer Organisation, die weniger Bugs will, zählt diese Disziplin.

QA ist kein Sicherheitsnetz

QA darf nicht der Ort sein, an dem Entwickler ihre Qualitätsverantwortung abgeben.

Wenn QA nur ein Sicherheitsnetz am Ende der Kette ist, kommt sie zu spät. Sie testet, was hätte gedacht, geklärt, automatisiert oder früher vermieden werden müssen. Sie wird zum letzten Damm vor der Produktion — also zum Ort, an dem die Organisation ihre Defekte auslagert.

Das reicht nicht.

QA kann eine viel strategischere Rolle spielen.

Sie kann Qualitätskriterien definieren. Testrichtlinien. Lieferstandards. Akzeptable Regressionsschwellen. Zu deckende Risiken. Zu sichernde Produktbereiche. Zu automatisierende Tests. Signale, die zeigen, ob ein Team besser oder schlechter liefert.

Mit Künstlicher Intelligenz und Automatisierung wird diese Rolle noch wichtiger.

Wie in vielen Berufen ermöglicht die KI, einen Teil der repetitiven operativen Arbeit zu reduzieren, um sich stärker auf die Strategie zu konzentrieren. Für QA bedeutet das: weniger manuelle Wiederholungstests, weniger Regressionen, die Bildschirm für Bildschirm durchgespielt werden — und mehr Nachdenken über das Qualitätssystem.

Der Wert von QA verschiebt sich.

Weniger: dieselben Prüfungen mechanisch wiederholen.

Mehr: definieren, was zu prüfen ist, warum, mit welchem Automatisierungsgrad, auf welche Risiken hin, mit welchen Kriterien.

QA ersetzt nicht die Verantwortung der Entwickler. Sie baut den Rahmen, in dem diese Verantwortung praktikabel, messbar und dauerhaft wird.

Metriken müssen der Qualität dienen

Messen kann nützlich sein.

Rework kann zum Beispiel zeigen, dass ein Team zu häufig auf dieselben Themen zurückkommt. Cycle Time kann zeigen, dass Nacharbeiten die Lieferung stark verlangsamen. Regressionen können zeigen, dass bestimmte Produktbereiche zu oft brechen.

Diese Signale sind nützlich, wenn sie dazu dienen, das System zu verbessern.

Sie werden toxisch, wenn sie eine administrative Obsession neu erschaffen.

Es nützt nichts, unendlich viel Zeit damit zu verbringen, zu klären, ob ein Defekt ein Bug, eine Feature, eine Verbesserung, eine Nacharbeit, eine QA-Anomalie oder etwas anderes ist — wenn diese Klassifizierung die Entscheidung nicht ändert.

Messung soll erhellen.

Sie darf das Urteil nicht ersetzen.

Das Ziel bleibt einfach: das Wichtige schnell liefern, mit einem akzeptablen Qualitätsniveau — und den echten Schmerz reduzieren.

Das Legacy von morgen

Legacy existiert.

Alle Teams müssen irgendwann mit altem Code arbeiten, vergangenen Entscheidungen, fragilen Architekturen, schlecht dokumentierten Abhängigkeiten, Entscheidungen, die gestern vielleicht Sinn ergaben und heute alles erschweren.

Das bestehende Legacy lässt sich nicht immer vermeiden.

Aber man kann vermeiden, das Legacy von morgen zu bauen.

Ein Bug, der an jemand anderen weitergegeben wird; eine vage Spec, die ohne Diskussion akzeptiert wird; ein nie geschriebener Test; eine manuelle Regression, die ohne Automatisierung wiederholt wird; eine QA, die als letztes Netz verwendet wird; Code, der schnell aber schlecht verstanden geliefert wird — all das wird zum künftigen Legacy.

Die Verantwortung bei Entwicklern zu verankern löst nicht alles. Aber es ändert die Entwicklung.

Wenn derjenige, der liefert, die Qualität des Gelieferten besitzt, produziert er anders. Wenn er eine zu mehrdeutige Spec ablehnen kann, vermeidet er, Unklarheit in Komplexität zu verwandeln. Wenn TDD einen Teil der Spezifikation formalisiert, wird das Produkt robuster. Wenn QA eine Qualitätspolitik definiert, wird das gesamte System klarer.

Das Legacy von morgen ist keine Schicksalsfrage.

Es ist oft das Ergebnis falsch angesiedelter Verantwortlichkeiten von heute.

Fazit

Ein Team, das weniger Bugs will, darf nicht nur besser klassifizieren.

Es muss Qualität undelegierbar machen.

Die Null-Bug-Politik behandelt den Bestand bekannter Defekte. Aber die Lieferqualität verhindert, dass dieser Bestand neu entsteht. Dafür muss jeder seine Verantwortung tragen.

Der Product Manager besitzt die Produktentscheidung.

Die Entwickler besitzen die technische Qualität dessen, was sie liefern.

QA baut den Qualitätsrahmen: Kriterien, Standards, Risiken, Tests, Automatisierung.

Und das Team muss als Ganzes Strukturen ablehnen, in denen Bugs immer das Problem von jemand anderem werden.

Verantwortung bedeutet nicht Schuld. Es bedeutet Ownership.

Qualität gehört denen, die liefern — weil sie es sind, die sie zum günstigsten Zeitpunkt aufbauen können: bevor der Bug existiert.

Mehr dazu

Zero Bugs: Hör auf, Defekt-Bestände zu verwalten Code centric