Qualitätsmetriken für Softwareteams sind messbare Kennzahlen, die zeigen, ob eine Änderung oder eine Verbesserung tatsächlich wirkt. Eine einzelne Metrik braucht fast immer eine Gegenmetrik: Die mittlere Zeit bis zur Behebung eines Produktionsfehlers gehört neben die Wiedereröffnungsrate, die Bestehensquote der Tests neben die Rate entgangener Fehler. Ein Team sollte höchstens drei oder vier Metriken gleichzeitig verantworten, und jede davon muss regelmäßig ausgewertet werden und Konsequenzen haben, sonst ist sie wertlos.
Das Wichtigste in Kürze
- Jeder KPI braucht eine Gegenmetrik: Wer die mittlere Zeit bis zur Fehlerbehebung misst, ohne die Wiedereröffnungsrate zu erfassen, verleitet Teams dazu, Tickets zu schließen, ohne das eigentliche Problem zu lösen.
- Ein Team sollte höchstens drei oder vier KPIs gleichzeitig verantworten. Wenige Kennzahlen geben eine Richtung vor, eine lange Liste erzeugt nur Rauschen und verwischt die Verantwortung.
- Eine Metrik, aus der niemand etwas folgert, ist nutzlos. Klare Verantwortung und regelmäßige Reviews machen den Unterschied zwischen einem aussagekräftigen KPI und einer Zahl, die nur das Dashboard schmückt.
- Wer das Team an der Entwicklung seiner Metriken beteiligt, schafft echte Verantwortung. Das ist der Unterschied zwischen Leuten, die eine Zahl schönrechnen, und Leuten, denen wichtig ist, was sie misst.
- Hohe Unit-Test-Abdeckung und Fehler in Produktion schließen sich nicht aus. Deshalb braucht jede Kennzahl zu Bestehensquote oder Abdeckung die Rate entgangener Fehler als Gegengewicht.
Warum Qualitätsmetriken eine Gegenmetrik brauchen
Qualitätsmetriken taugen nur dann etwas, wenn jede Kennzahl ein Gegenstück hat. Die Anzahl geschriebener Tests oder den Prozentsatz der Unit-Test-Abdeckung zu zählen, sieht ordentlich aus. In der Praxis bringt es die Leute aber dazu, die Zahl zu optimieren statt das Produkt.
Wird ein Tester nur daran gemessen, wie viele Tests er in einem Zeitraum schreibt, schreibt er Tests, um das Ziel zu erreichen und den Bonus mitzunehmen. Dann beschreibt die Metrik den Aufwand, nicht die Qualität. Deshalb gehören Metriken paarweise eingesetzt.
Das Paar hält die Zahl ehrlich. Die mittlere Zeit bis zur Behebung eines Fehlers macht sich gut auf dem Dashboard, verleitet für sich allein aber dazu, Tickets schnell zu schließen. Stellst du die Wiedereröffnungsrate daneben, ändert sich das Bild: Ein geschlossenes Ticket zählt nur, wenn das Problem auch gelöst bleibt. Dasselbe gilt für die Bestehensquote der Tests. Eine hohe Quote wirkt beruhigend, bis du die Rate entgangener Fehler (Escaped Defect Rate) oder die Rate instabiler Tests danebenlegst. Erst dann siehst du, ob die grünen Tests überhaupt etwas finden.
90 Prozent Testabdeckung und trotzdem Fehler in Produktion
Hohe Abdeckung beweist keine Qualität. Du kannst 90 Prozent Unit-Test-Abdeckung erreichen und trotzdem Fehler in Produktion haben, denn die Abdeckung misst, wie viel Code deine Tests berühren, nicht, wie gut sie das Wichtige finden.
Jani Grönman beschreibt eine Lücke, die viele Entwickler aus ihren ersten Berufsjahren mitnehmen: den Glauben, dass mehr Abdeckung automatisch weniger Fehler bedeutet. Was fehlt, ist die Leitplanke. Ohne eine Gegenmetrik, die beobachtet, was an den Tests vorbeirutscht, wird die Abdeckung zur Beruhigungszahl.
“Ich kann 90 Prozent Unit-Test-Abdeckung haben und trotzdem Fehler in Produktion. 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, sodass trotzdem Fehler in Produktion landen?” Die Rate entgangener Fehler beantwortet genau das. Sie zeigt dir, wie gut deine Testsuite wirklich ist, auch wenn alle Tests bestehen.
Die Fehlerfindungskurve gilt noch, mit einer Einschränkung
Die klassische Kurve gibt es weiterhin: Am Anfang werden viele Fehler gefunden, dann flacht sie ab, weil kaum neue dazukommen. Eine feste Testsuite gegen ein unverändertes Produkt findet die Fehler, die sie finden kann, und dann ist Schluss.
Genau das ist die nützliche Erkenntnis. Eine Testsuite wächst bis zu einem bestimmten Punkt und erreicht dann ein Plateau. Abdeckung und Anzahl der Tests sagen nichts über die Fehler, die außerhalb dieser Suite liegen. Die Rate entgangener Fehler schon. Sie zeigt, ob das Plateau bedeutet “Wir haben die Fehler gefunden” oder “Wir suchen nicht mehr an den richtigen Stellen”.
Wenige Metriken mit klarer Verantwortung
Drei oder vier KPIs pro Team reichen. Mehr davon verteilen die Aufmerksamkeit, statt sie zu bündeln. Eine kleine Auswahl sorgt dafür, dass alle in dieselbe Richtung laufen.
Jede Metrik braucht jemanden, der sie verantwortet, und einen festen Rhythmus für Reviews. Eine Zahl, die gemessen wird, aus der aber nie etwas folgt, ist Ballast. Sinkt die Bestehensquote und das Team reagiert, indem es fehlschlagende Tests abschaltet, wird die Metrik besser und das Produkt schlechter. Verantwortung heißt: Jemand wertet aus, was die Zahl sagt, und handelt danach.
Außerdem müssen alle, die eine Metrik lesen, sie gleich verstehen. Dieselbe Zahl lässt sich unterschiedlich deuten. Wer eine Metrik einführt, muss sich deshalb darauf einigen, was in ihr steckt und was sie tatsächlich aussagt.
Ein Team, eine Zahl statt getrennter Scorecards
Wer Tester und Entwickler mit unterschiedlichen Metriken misst, spaltet ein Team, das ein gemeinsames Ziel haben sollte. Jani Grönman plädiert für eine gemeinsame Kennzahl, die das ganze Team verantwortet und die aus dem Produktdenken kommt statt aus rollenspezifischen Scorecards.
Die mittlere Wiederherstellungszeit (Mean Time to Recovery) eignet sich als technische Kennzahl für das ganze Team. DORA-Metriken sind technisch relevant. Um ein Team aber in eine gemeinsame Richtung zu bringen, brauchst du etwas, das näher am Geschäft liegt. Spotify teilt mit seinen Teams eine Kennzahl zur Hördauer. Das Prinzip: eine einzige Zahl, die die tägliche Arbeit mit dem verbindet, was Kundinnen und Kunden erleben.
Produktorientierte Entwicklung heißt, das Team mit Endnutzern und Fachleuten aus dem Business in Kontakt zu bringen. Wenn Entwickler und Tester verstehen, woher der Umsatz kommt, können sie ihre Arbeit danach ausrichten. Es geht um Selbstwirksamkeit: Deine Arbeit zählt, weil sie zum Produkt beiträgt, nicht weil du ein Soll an Tests erfüllt hast.
Metriken einführen, ohne Vertrauen zu verspielen
Entwickle Metriken mit dem Team, statt sie vorzuschreiben. Wer verkündet “Ab jetzt messen wir bei euch dies und das”, lädt das Team ein, die Zahl zu manipulieren, und genau damit solltest du dann auch rechnen.
Fang bei den Leuten an, die von sich aus wissen wollen, warum es das Produkt gibt. Manche Entwickler halten lieber Abstand zu den Geschäftszielen und konzentrieren sich auf die Technik, und das ist in Ordnung. Andere wollen verstehen, warum sie bauen, was sie bauen. Diese Leute verstehen KPIs schneller und sind ein guter Ausgangspunkt.
Ein guter Einstieg ist Nacharbeit. Frag, wie viel Zeit in Fehlerbehebung fließt oder in die Suche danach, warum etwas nicht funktioniert. Wenn die halbe Woche in Nacharbeit verschwindet, stell die Frage ganz direkt: Würdest du lieber zehn Prozent deiner Zeit mit Fehlern verbringen statt fünfzig? So bekommt das Messen einen Sinn, weil die Metrik mit etwas verbunden ist, das das Team selbst ändern will.
Richtest du Metriken auf diese Weise ein, folgt die Verantwortung von selbst. Wer eine Kennzahl mitgestaltet hat, will sie auch bewegen. Die Leute sehen darin ein Maß für etwas Echtes, das Kunden merken, und keine abstrakte Zahl, die von oben verordnet wurde.
Was für dich, den Kunden und das Unternehmen zählt
Eine einfache Frage in drei Richtungen eröffnet das Gespräch darüber, welche Metriken wichtig sind: Was ist dir persönlich wichtig, was ist dem Kunden wichtig, und was ist dem Unternehmen wichtig, das das Produkt baut?
Das Produktmanagement ist meist ausgelastet und hat wenig Zeit für Debatten über Kennzahlen. Wenn du seine Aufmerksamkeit bekommst und dann aus diesen drei Blickwinkeln arbeitest, bleibt die Diskussion geerdet. Von dort aus fragst du, ob das Team seine Ziele erreicht, wo es stehen sollte und ob Features um ihrer selbst willen gebaut werden. Am Ende soll das Warum hinter der Arbeit sichtbar werden.
Die Durchlaufzeit bis in die Produktion eignet sich dafür als übergeordnete Metrik. Mit einem Richtwert für die Art von Team, die du führst, kannst du fragen, ob ihr das Ziel erreicht, und wenn nicht, warum nicht. Aus der Antwort werden konkrete Aufgaben, mit denen das Team die Lücke schließen kann.
Tester gehören nach vorn, zu den Anforderungen
Fehlerhafte Anforderungen verursachen Fehler, das wissen die meisten Tester. Schwerer fällt das Eingeständnis, dass Testen im Entwicklungszyklus immer noch zu weit rechts sitzt, weit weg von der Stelle, an der Anforderungen entstehen.
Schlechte Anforderungen führen zu schlechtem Testentwurf, denn was man nicht versteht, kann man nicht gut testen. Trotzdem rücken Tester selten näher an das Requirements Engineering heran. Dabei hätten sie dort viel beizutragen: die Geschäftsidee testen, das Produktmanagement hinterfragen, Anforderungen prüfen, bevor es Code gibt.
Produktionsfehler zu zählen, hilft nur, wenn du analysierst, ob jeder davon wirklich ein Softwarefehler ist. Fehler in Produktion haben viele Ursachen. Für ein Entwicklungs- und Testteam zählen die Fälle, die auf fehlende Testfälle, Softwarefehler oder Probleme in den Anforderungen zurückgehen. Eine solide Ursachenanalyse spielt diese Information zurück und gehört zu den wertvollsten Dingen, die ein Team aufbauen kann.
Häufig gestellte Fragen
Bedeutet eine hohe Unit-Test-Überdeckung weniger Fehler?
Eine hohe Überdeckung ist kein Beweis für Qualität. Ein Team kann eine Unit-Test-Überdeckung von neunzig Prozent erreichen und trotzdem Fehlerzustände ausliefern, denn die Überdeckung misst, wie viel vom Code die Tests abdecken, nicht, wie gut sie das Wesentliche erfassen. Die „Entgangene Fehlerrate“ (Anteil der übersehenen Fehler) ist das ehrliche Gegenstück: Sie zeigt, was an der Testsuite vorbeirutscht, selbst wenn alle Tests bestanden werden.
Was ist eine Gegenkennzahl, und welche Kombinationen funktionieren in der Praxis?
Eine Gegenkennzahl ist die Zahl, die die erste Kennzahl im Zaum hält. Die durchschnittliche Zeit bis zur Behebung eines Fehlers verleitet Teams dazu, Tickets schnell zu schließen, kombiniere sie daher mit der Wiedereröffnungsrate: Ein Abschluss zählt nur, wenn das Problem geschlossen bleibt. Die Testbestandsrate braucht die Rate der entgangenen Fehler oder die Rate der unzuverlässigen Tests als Gegenstück, sonst beweisen grüne Tests gar nichts.
Wie viele Metriken sollte ein Team gleichzeitig betreuen?
Drei oder vier reichen aus. Ein fokussierter Satz sorgt dafür, dass alle am gleichen Strang ziehen, während eine längere Liste die Aufmerksamkeit zerstreut und die Zurechenbarkeit verwässert. Jede Metrik braucht außerdem einen namentlich benannten Verantwortlichen und einen festen Rhythmus für Reviews. Eine Zahl, die gemessen wird, aber nie zum Anlass für Maßnahmen genommen wird, ist nur Ballast auf einem Dashboard.
Gilt die klassische Fehlerentdeckungskurve noch?
Ja. Ein fester Testsatz, der auf ein unveränderliches Produkt angewendet wird, findet die Fehler, die er finden kann, und erreicht dann ein Plateau. Genau das beschreibt die Kurve. Die Einschränkung besteht darin, dass weder die Überdeckung noch die Anzahl der Tests etwas über Fehlerzustände aussagt, die außerhalb dieses Satzes liegen. Die Rate der entgangenen Fehler zeigt dir, ob das Plateau bedeutet, dass die Fehlerzustände gefunden wurden oder dass die Suche eingestellt wurde.
Sollten Tester und Entwickler anhand unterschiedlicher Metriken gemessen werden?
Nein. Getrennte Scorecards spalten ein Team, das ein gemeinsames Ziel verfolgen sollte. Die „Mean Time to Recovery“ eignet sich gut als teaminterne technische Metrik, und DORA-Metriken sind in technischer Hinsicht wichtig, aber eine Zahl, die näher am Geschäft liegt, gibt dem Team eine gemeinsame Richtung vor. Spotify teilt seinen Teams eine Metrik zur Hörzeit als gemeinsamen Wert mit.
Wie kannst du Metriken zur Qualität einführen, ohne dass das Team sie ausnutzt?
Entwickle die Metriken gemeinsam mit dem Team, anstatt sie von oben herab vorzuschreiben. Eine Ankündigung, dass die Leute nun anhand dieser oder jener Metrik gemessen werden, lädt zum Ausnutzen des Systems ein, und genau dieses Ergebnis ist zu erwarten. Nacharbeit ist ein guter Einstieg: Frag, wie viel Zeit pro Woche für die Behebung von Fehlern draufgeht, und frag dann, ob zehn Prozent besser wären als fünfzig.
Warum sollten Tester schon vor dem Schreiben des ersten Codes einbezogen werden?
Fehlerhafte Anforderungen verursachen Fehlerzustände, und schlechte Anforderungen führen zu schlechtem Testentwurf, denn man kann etwas nicht gut testen, ohne zu verstehen, was es eigentlich leisten soll. Das Testen findet im Entwicklungszyklus immer noch zu spät statt. Tester können die Geschäftsidee prüfen, das Produktmanagement hinterfragen und Anforderungen untersuchen, solange der Code noch nicht existiert.
Ist die Anzahl der Produktionsfehler eine nützliche Metrik für die Qualität?
Nur, wenn eine Analyse dahintersteht. Produktionsfehler haben viele Ursachen, daher sagt eine reine Stückzahl dem Entwicklungs- und Testteam nur sehr wenig. Was zählt, sind die Probleme, die auf fehlende Testfälle, Softwarefehler oder Probleme mit den Anforderungen zurückzuführen sind. Eine fundierte Grundursachenanalyse liefert diese Informationen zurück und wird zu einem der wertvollsten Vermögenswerte des Teams.
