Warum fehlerfreier Code das falsche Ziel ist
Jedes System enthält Fehler, auf die noch niemand gestoßen ist, und die Kosten, den nächsten zu finden, steigen steil an, sobald die offensichtlichen beseitigt sind. Ab einem bestimmten Punkt ist eine zusätzliche Stunde Fehlersuche weniger wert als dieselbe Stunde, investiert darin, Fehlschläge billig auffindbar und behebbar zu machen.
Das zweite Problem ist kultureller Natur. Wenn Fehlerfreiheit das erklärte Ziel ist, wird ein Bug zu einem Versagen, das erklärt werden muss, statt zu einer Information, auf die man reagiert – und im Team wird es stiller um diese Bugs.
Drei Ziele, die funktionieren
Keine Wiederholungen
Ein bestimmter Bug tritt genau einmal auf. Jede Behebung hinterlässt eine Prüfung.
Erreichbar – und mit kumulativer Wirkung.
Vor den Nutzern gefunden
Verlagern Sie die Erkennung aus der Produktion in den Pull Request.
Messbar: welcher Anteil intern abgefangen wurde.
Günstig zu beheben
Die Zeit vom Fehlschlag bis zur Behebung – sie hängt vor allem von der Qualität des Fehlerberichts ab.
Warum das erste am wichtigsten ist
Ein Team, das denselben Bug nie zweimal ausliefert, wird schon konstruktionsbedingt jeden Monat besser. Dafür braucht es genau eine Gewohnheit: Wenn Sie etwas beheben, hinterlassen Sie eine Prüfung. Die meisten Teams beheben den Bug, schließen das Ticket und halten nirgends fest, dass dieses Verhalten je abgesichert werden musste.
Die Messung
Verfolgen Sie den Anteil der vor dem Release gefundenen Defekte und die Zeit vom Fehlschlag bis zur Behebung. Beide verändern sich, wenn sich tatsächlich etwas verbessert, und keine der beiden Kennzahlen lässt sich durch das Schreiben weiterer Tests schönen – genau das macht sie brauchbar. Testanzahl und Coverage-Prozentsatz lassen sich dagegen jederzeit nach Belieben steigern und sagen fast nichts aus.
Warum Teams ihm trotzdem hinterherjagen
Zu wissen, dass das Ziel falsch ist, hält niemanden davon ab, es trotzdem anzupeilen. Der Grund dafür lohnt das Verständnis, weil er strukturell ist und nicht naiv.
Bugs sind ablesbar, Prävention ist es nicht. Ein Defekt, der einen Kunden erreicht hat, hat ein Ticket, einen Namen und einen Verantwortlichen. Die zwölf, die vor dem Release abgefangen wurden, haben nichts davon, weil nichts passiert ist. Die sichtbare Bilanz eines Quartals ist damit eine Liste von Fehlschlägen – und die natürliche Reaktion auf eine Liste von Fehlschlägen ist die Forderung, es sollten weniger sein.
Das Gegenmittel besteht darin, auch die Prävention sichtbar zu machen. Berichten Sie, wie viele Defekte vor dem Release abgefangen wurden, neben der Zahl derer, die durchgerutscht sind. Die erste Zahl ist in der Regel deutlich größer, und sie zu sehen verschiebt die Diskussion von „Warum haben wir ständig Bugs?" hin zu „Bewegt sich das Verhältnis?" – und das ist die Frage, auf die es eine brauchbare Antwort gibt.
Wie das in der Praxis aussieht
Jeder Bug bekommt eine Prüfung. Prüfungen laufen bei jeder Änderung, nicht erst vor Releases. Fehlschläge kommen in einer Form an, mit der die Person, die sie behebt, direkt arbeiten kann, ohne den Hergang erneut rekonstruieren zu müssen.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Das Dashboard deckt dasselbe ab – für alle, die keine lokale Installation möchten –, und der vollständige Befehlsumfang liegt im CLI-Repository.
Der Auslöser ist wichtiger als der Mechanismus. Wenn Sie ihn an Ihr Deployment-Ereignis koppeln, wird jede Änderung geprüft, ohne dass es jemand entscheiden muss; die GitHub App übernimmt das vom Dashboard aus, und ein Schritt mit GitHub Actions erledigt es innerhalb Ihres Workflows.
Wie TestSprite die drei Ziele unterstützt
„Keine Wiederholungen" wird am unmittelbarsten bedient. Der Testfall, der einen Bug reproduziert hat, bleibt im Projekt und läuft bei jeder Änderung mit. So hinterlässt die Behebung eine Prüfung, ohne dass jemand daran denken muss, eine zu schreiben.
„Vor den Nutzern gefunden" ist eine Frage der Taktung. Die Abdeckung wird aus Ihrem Produkt heraus erzeugt und läuft im Pull Request. Damit wandert die Erkennung aus der Produktion zurück zu der Änderung, die den Fehler verursacht hat.
„Günstig zu beheben" hängt am Fehlerbericht. Ein Lauf kommt als das zurück, was versucht wurde, was die Anwendung getan hat und an welcher Stelle beides auseinanderging. Wer den Fehler behebt – zunehmend ein Coding-Agent –, startet damit von Belegen aus, statt den Hergang zu rekonstruieren.
Ist Fehlerfreiheit überhaupt erreichbar?
Bei kleinen, formal spezifizierten Systemen annähernd – zu Kosten, die fast niemand rechtfertigen kann. Bei einem gewöhnlichen Produkt nicht.
Was ist eine vernünftige Fehlerrate?
Vergleichen Sie mit Ihrem eigenen Trend statt mit einem Branchenwert. Die Richtung zählt mehr als das Niveau.
Bedeuten mehr Tests weniger Bugs?
Bis zu einem gewissen Punkt. Danach erzeugen zusätzliche Tests Wartungsaufwand, ohne Erkenntnis hinzuzufügen – vor allem, wenn sie doppeln, was Sie bereits abdecken.
Sollten wir Bug-Zahlen verfolgen?
Verfolgen Sie durchgerutschte Defekte und die Zeit bis zur Behebung. Reine Zählwerte steigen schon dann, wenn sich die Meldedisziplin verbessert – das macht sie zu einem schlechten Signal.
Welche einzelne Gewohnheit hat die größte Hebelwirkung?
Hinterlassen Sie jedes Mal eine Prüfung, wenn Sie etwas beheben. Es ist die einzige Gewohnheit mit kumulativer Wirkung.
Zielen Sie auf keine Wiederholungen, nicht auf null.
Fehlerfreier Code ist nicht erreichbar und verzerrt die Prioritäten. Zielen Sie auf keine Wiederholungen, auf vor den Nutzern gefunden und auf günstig zu beheben. Hinterlassen Sie nach jeder Behebung eine Prüfung und messen Sie durchgerutschte Defekte statt Testzahlen.