Mit Metriken managen: Mist!

"Was man nicht messen kann, kann man nicht lenken", so sagte Peter Drucker. Das sollte für Softwareentwicklung auch gelten. Also geben wir Metrikwerte vor und alles wird gut. Wirklich?

Ein konkretes Beispiel: Testabdeckung. Sie ist ein Maß dafür, wie viel Code bei den Tests tatsächlich durchlaufen wird. Code, der nicht durchlaufen wird, validiert der Tests auch nicht. Eine höhere Testabdeckung ist also besser und zeigt, dass mehr vom Code tatsächlich überprüft wird.

Testabdeckung ist recht einfach messbar. Was liegt also näher, als einen bestimmten Mindestwert einfach vorzugeben? Wer das schon einmal in einem Projekt getan hat, bekommt als Ergebnis zwar eine gute Testabdeckung. Ein genauerer Blick zeigt dann oft, dass trivialer Code getestet wird, statt den komplexen und fehleranfälligen Code zu untersuchen. Oder die Ergebnisse, die der Code liefert, werden gar nicht auf Richtigkeit überprüft.

Metrik: Ziel oder Information?

Dahinter steckt ein allgemeines Prinzip, dass mir irgendwann jemand erklärt hat. Eine Metrik, bei der ein bestimmter Zielwert vorgegeben wird, hört auf, tatsächlich sinnvolle Informationen zu liefern. Für Testabdeckung bedeutet das: Sie zeigt eigentlich an, wo der Code nicht gut getestet ist. Wenn eine hohe Testabdeckung zu einem Ziel wird, verliert sie diese Aussagekraft. Denn nun werden alle am Projekt beteiligten versuchen, einen hohen Wert für die Metrik möglichst ohne viel Aufwand zu erreichen. So entstehen Tests, die zwar Code ausführen, aber triviale Fälle untersuchen oder sogar die Ergebnisse des Codes nicht überprüfen. Die hohe Testabdeckung sagt nun nicht mehr viel über die Qualität der Tests aus. Trotz hoher Testabdeckung ist der Code nicht gut getestet.

Dazu passt auch ein Zitat, das ich einmal gehört habe: "Ein guter Manager erreicht seine Zahlen – und wenn das Unternehmen dabei pleite geht." Das vorgegebene Ziel wird erreicht – ohne Rücksicht auf die weiteren Konsequenzen.

Metriken = Informationsreduktion

Metriken sollten daher meiner Meinung nach zur Informationsreduktion genutzt werden. Softwaresysteme sind komplex. Wenn man das gesamte System verstehen könnte, wären keine Metriken notwendig. Dazu ist die Software meistens zu kompliziert. Also nutzt man Metriken, um herauszufinden, wo Probleme sein könnten und diese zu beseitigen. Eine niedrige Testabdeckung kann auf ein Problem hinweisen – oder auch nicht. Eine niedrige Testabdeckung bei trivialem Code ist wesentlich weniger schlimm als bei einem bekannten Fehlerschwerpunkt.

Am Ende ist das Ziel eines Projekts keine hohe Testabdeckung, sondern eine hohe Qualität. Tests sind nur eine Möglichkeit, die notwendige Qualität zu erreichen und fokussieren auch nur auf die Codequalität. Der Nutzer nimmt diese aber gar nicht wahr. Eine Zielvorgabe für Testabdeckung fokussiert auf eine bestimmte Art der Zielerreichung eines bestimmten Ziels. Vielleicht ist eine Art von Zielvorgabe besser. ()