Qualitätsmetriken für Softwareteams sind messbare Indikatoren, die zeigen, ob eine Änderung oder ein Verbesserungsprojekt tatsächlich funktioniert. Eine einzelne Metrik braucht fast immer eine gepaarte Gegenmetrik: Zum Beispiel sollte die durchschnittliche Zeit zur Lösung eines Problems in der Produktion gegen die Wiedereröffnungsrate und die Rate der bestandenen Tests gegen die Rate der entgangenen Fehler abgewogen werden. Teams sollten nicht mehr als drei oder vier Metriken auf einmal besitzen, und jede Metrik muss regelmäßig überprüft und bearbeitet werden, damit sie einen Wert hat.
Das Wichtigste in Kürze
- Jeder KPI braucht eine Metrik, die ihm entgegenwirkt: Die Messung der durchschnittlichen Zeit bis zur Fehlerbehebung, ohne auch die Wiedereröffnungsrate zu erfassen, lädt Teams dazu ein, Tickets zu schließen, ohne das eigentliche Problem zu beheben.
- Teams sollten nicht mehr als drei oder vier KPIs auf einmal besitzen, denn ein fokussierter Satz gibt die Richtung vor, während eine lange Liste Lärm erzeugt und die Zurechenbarkeit erschwert.
- Eine Metrik, nach der niemand handelt, ist eine nutzlose Metrik: Eigenverantwortung und regelmäßiges Review unterscheiden einen aussagekräftigen KPI von einer Zahl, die ein Dashboard schmückt.
- Das ist der Unterschied zwischen Ingenieuren, die mit einer Zahl spielen, und Ingenieuren, denen es wichtig ist, was sie misst.
- Eine hohe Testabdeckung kann mit Fehlern in der Produktion koexistieren, so dass die Rate der entgangenen Fehler ein notwendiges Gegengewicht zu jeder Metrik für die Bestehensrate oder die prozentuale Abdeckung darstellt.
Warum eine einzelne Metrik nie die Wahrheit sagt
Eine Metrik verdient nur dann ihren Platz, wenn sie mit einem Gegenstück versehen ist. Die Anzahl der geschriebenen Tests oder die prozentuale Überdeckung der Unit-Tests zu zählen, sieht zwar ordentlich aus, führt aber dazu, dass die Leute mit den Zahlen spielen, anstatt das Produkt zu verbessern.
Wenn ein Tester nur daran gemessen wird, wie viele Tests er in einem bestimmten Zeitraum schreibt, wird er Tests schreiben, um das Ziel zu erreichen und den Bonus zu kassieren. Die Metrik beschreibt dann den Aufwand, nicht die Qualität. Deshalb sollten Metriken immer paarweise eingesetzt werden.
Ein Paar hält die Zahl ehrlich. Die durchschnittliche Zeit zur Behebung eines Fehlers liest sich gut auf einem Dashboard, aber für sich genommen verleitet sie die Teams dazu, Tickets schnell zu schließen. Wenn du sie mit der Wiedereröffnungsrate kombinierst, ändert sich das Bild: Das Schließen eines Tickets zählt nur, wenn das Problem geschlossen bleibt. Die gleiche Logik gilt für die Bestehensquote von Tests. Eine hohe Bestehensrate sieht beruhigend aus, bis du die Rate der entgangenen Fehler oder der fehlerhaften Tests daneben setzt. Dann kannst du sehen, ob grüne Tests tatsächlich etwas auffangen.
Überdeckung von 90 Prozent liefert immer noch Fehlerzustände
Eine hohe Überdeckung ist kein Beweis für Qualität. Du kannst eine neunzigprozentige Überdeckung der Tests erreichen und trotzdem Fehlerzustände in der Produktion haben, denn die Überdeckung misst, wie viel des Codes deine Tests berühren, und nicht, wie gut sie das Wesentliche abfangen.
Jani Grönman weist auf eine Lücke hin, die viele Ingenieure aus ihren Anfangsjahren mitbringen: den Glauben, dass mehr Überdeckung gleichbedeutend mit weniger Fehlern ist. Das fehlende Stück ist die Leitplanke. Ohne ein Gegenstück, das darauf achtet, was an den Tests vorbeiläuft, wird die Überdeckung zu einer bequemen Zahl.
Ich kann eine Überdeckung der Tests von 90% haben und trotzdem Fehlerzustände in der Produktion haben. Wie kann das sein? Wir sind doch perfekt.” Jani Grönman
Die ehrliche Frage lautet nicht: “Wie grün sind wir?”, sondern: “Was testen wir nicht, so dass immer noch Fehlerzustände in die Produktion gelangen?” Die Rate der entgangenen Fehler ist eine Antwort darauf und sagt dir, wie gut dein Testsatz wirklich ist, selbst wenn alle Tests bestanden werden.
Die Fehlerentdeckungskurve gilt immer noch, allerdings mit einer Einschränkung
Die klassische Kurve, bei der viele Fehlerzustände früh befundet werden und die dann abflacht, wenn weniger neue Fehler auftauchen, gibt es immer noch. Ein fester Testsatz für ein unverändertes Produkt wird die Fehler finden, die er finden kann, und dann aufhören.
Das ist die nützliche Erkenntnis: Ein Satz von Tests entwickelt sich bis zu einem bestimmten Punkt und stagniert dann. Überdeckung und Anzahl der Tests sagen nichts über die Fehlerzustände aus, die außerhalb dieses Satzes liegen. Die Rate der entgangenen Fehlerzustände hingegen schon. Sie verrät, ob das Plateau bedeutet: “Wir haben die Fehler gefunden” oder “Wir haben aufgehört, an den richtigen Stellen zu suchen.”
Halte die Metrik klein und in deinem Besitz
Drei oder vier KPIs pro Team sind genug. Mehr als das zerstreut die Aufmerksamkeit, anstatt sie zu lenken. Ein konzentrierter Satz sorgt dafür, dass alle in dieselbe Richtung gehen.
Jede Metrik braucht einen Verantwortlichen und einen Review-Rhythmus. Eine Zahl, die gemessen, aber nie umgesetzt wird, hat keinen Wert. Wenn die Quote der bestandenen Tests sinkt und die Reaktion darauf darin besteht, fehlgeschlagene Tests zu deaktivieren, verbessert sich die Metrik, während das Produkt schlechter wird. Eigentümerschaft bedeutet, dass jemand analysiert, was die Zahl aussagt, und etwas dagegen unternimmt.
Eine Metrik muss außerdem von allen, die sie lesen, auf die gleiche Weise verstanden werden. Ein und dieselbe Zahl kann unterschiedlich interpretiert werden. Deshalb muss man sich bei der Übernahme einer Metrik darauf einigen, was in ihr steckt und was sie einem tatsächlich sagt.
Ein Team, eine Zahl schlägt separate Anzeigetafeln
Die Messung von Testern und Entwicklern mit unterschiedlichen Metriken spaltet ein Team, das ein gemeinsames Ziel haben sollte. Jani Grönman plädiert für eine gemeinsame Kennzahl, die das ganze Team für sich beanspruchen kann und die sich an einem produktbezogenen Denken orientiert und nicht an rollenspezifischen Scorecards.
Die mittlere Wiederherstellungszeit ist eine technische Metrik, die dem Team gehört. DORA-Metriken sind technisch gesehen wichtig. Aber um ein Team in eine bestimmte Richtung zu lenken, brauchst du etwas, das näher am Geschäft ist. Spotify gibt seinen Teams eine Metrik für den Zeitaufwand zum Zuhören an die Hand; das Prinzip ist eine einzige Zahl, die die tägliche Arbeit mit dem verbindet, was die Kunden erleben.
Produktorientierte Entwicklung bedeutet, das Team in Kontakt mit den Endnutzern und Geschäftsleuten zu bringen. Wenn Entwickler und Tester verstehen, woher die Einnahmen kommen, können sie ihre Arbeit danach ausrichten. Der Punkt ist die Vermittlung: Deine Arbeit ist wichtig, weil sie zum Produkt beiträgt, und nicht, weil du eine bestimmte Anzahl von Tests produziert hast.
Wie man Metriken einführt, ohne das Vertrauen zu brechen
Entwickle Metriken gemeinsam mit dem Team, schreibe sie nicht vor. Wenn du ankündigst: “Wir messen jetzt dieses und jenes”, lädt das Team dazu ein, mit den Zahlen zu spielen, und damit solltest du rechnen.
Beginne mit den Leuten, die von Natur aus neugierig sind, warum es das Produkt gibt. Manche Ingenieure halten sich lieber von den Geschäftszielen fern und wollen sich auf die technische Seite konzentrieren, und das ist auch gut so. Andere wollen wissen, warum sie das bauen, was sie bauen. Diese Menschen begreifen die KPIs schneller und sind ein guter Ausgangspunkt.
Ein nützlicher Eintrag ist Nacharbeit. Frag, wie viel Zeit darauf verwendet wird, Fehler zu beheben oder herauszufinden, warum etwas nicht funktioniert. Wenn die Hälfte der Woche für Nacharbeit draufgeht, stell die Frage ganz klar: Würdest du lieber zehn Prozent deiner Zeit mit Fehlern verbringen als fünfzig? Das macht die Messung sinnvoller, denn die Metrik ist jetzt mit etwas verbunden, das das Team selbst ändern möchte.
Wenn du die Metrik auf diese Weise einrichtest, wird die Verantwortung dafür übernommen. Diejenigen, die an der Entwicklung einer Kennzahl beteiligt waren, wollen sie verändern, und sie betrachten sie als eine Messung für etwas Reales, das die Kunden wahrnehmen, und nicht als eine abstrakte Zahl, die von oben verordnet wurde.
Was für dich, den Kunden und das Unternehmen wichtig ist
Eine einfache Frage in drei Richtungen eröffnet das Gespräch darüber, welche Metriken wichtig sind: was ist für dich persönlich wichtig, was ist für den Kunden wichtig und was ist für das Unternehmen wichtig, das das Produkt herstellt.
Das Produktmanagement ist meist überlastet und hat wenig Zeit für Metrik-Debatten. Wenn du ihre Aufmerksamkeit gewinnst und dann von diesen drei Gesichtspunkten aus arbeitest, bleibt die Diskussion auf dem Boden der Tatsachen. Von dort aus fragst du, ob das Team seine Ziele erreicht, wo es sein sollte und ob Funktionen um ihrer selbst willen entwickelt werden. Das Ziel ist es, den Grund für die Arbeit zu finden.
Die Durchlaufzeit bis zur Produktion ist eine gute Metrik dafür. Wenn du einen Maßstab für dein Team hast, kannst du fragen, ob du dieses Ziel erreichst, und wenn nicht, warum nicht. Die Antwort führt zu konkreten Maßnahmen, die das Team ergreifen kann, um die Lücke zu schließen.
Tester gehören vorgelagert, in der Nähe der Anforderungen
Fehlerhafte Anforderungen verursachen Fehlerzustände, und die meisten Tester wissen das. Das schwierigere Eingeständnis ist, dass das Testen im Softwareentwicklungslebenszyklus immer noch zu weit rechts sitzt, weit weg von dem Ort, an dem die Anforderungen geschrieben werden.
Schlechte Anforderungen führen zu einem schlechten Testentwurf, denn man kann etwas nicht gut testen, ohne zu wissen, was es tun soll. Dennoch wird selten darauf reagiert, dass man sich dem Requirements Engineering annähert. Dabei haben Tester viel zu bieten: Sie können die Geschäftsidee testen, das Produktmanagement herausfordern und die Anforderungen prüfen, bevor der Code existiert.
Das Zählen von Produktionsfehlern hilft nur, wenn du analysierst, ob jeder einzelne tatsächlich ein Softwarefehler ist. Fehlerzustände in der Produktion haben viele Ursachen. Für ein Entwicklungs- und Testteam zählen nur die Probleme, die auf fehlende Testfälle, Softwarefehler oder Probleme mit den Anforderungen zurückzuführen sind. Eine solide Grundursachenanalyse liefert diese Informationen und ist eine der wertvollsten Ressourcen, die ein Team aufbauen kann.
