Happy Quality, es ist wieder World Quality Week und da wollen wir Softwarequalität wieder mal so richtig abfeiern. Drum gibt es in dieser Woche wieder jeden Tag eine Spezialfolge zum Thema Testen Qualität und was sonst noch dazugehört. Also lasst uns Software besser machen. Viel Spaß! Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritchie und habe wieder eine Folge aus meiner Heimatstadt mitgebracht.
Nämlich von den Software Quality Days 2024 in Wien. Bei mir zu Gast war Mike, der sich intensiv mit dem Thema Softwaremetriken auseinandersetzt. Das hat mich natürlich sehr interessiert, da ja vor nicht allzu langer Zeit die neue Auflage von Softwaremetriken, dem Buch, das ich zusammen mit Manfred Baumgartner und Harry Sneed geschrieben habe, erschienen ist. Und mit Metriken ist es ja so eine Sache. Es gibt so, so viele und man kann so viel messen. Aber was macht wirklich Sinn?
Und welche Metriken kann ich eigentlich nutzen, um Qualität und Produktivität wirklich auch darzustellen? Und vor allem, was will ich eigentlich mit diesen Metriken? Dazu habe ich Mike interviewt und er gibt uns seine Tipps und Tricks zu dem Thema mit. Und jetzt viel Spaß bei der Folge. Hallo Mike, schön, dass du da bist. Hallo Ritchie, ich freue mich auch hier zu sein. Danke für die Einladung. Ja, sehr gerne. Wir sind ja hier bei den Software-Quality-Days. Tag zwei heute.
Es ist gerade so die erste Keynote durch und die erste Podcast-Aufnahme heute an dem Tag. Das heißt, du bist die heutige Premiere sozusagen. Und ich habe im Vorfeld so ein bisschen mir angeschaut, die Abstracts und die Speaker, was da so für Themen drin sind. Und da bin ich bei dir auch hängen geblieben, weil du dich so um das Thema Messung von Qualität und Produktivität damit auseinandergesetzt hast. Und das finde ich immer ein spannendes Thema. Und ja, wie bist denn du dazu gekommen?
Was hat dich denn daran motiviert, da mal tiefer reinzuschauen? Also Metriken sind bei meiner Arbeit ein ganz wichtiger Faktor, weil ich in Unternehmen immer wieder feststelle, dass hauptsächlich über Meinungen diskutiert wird und wir in unserer sehr komplexer werdenden Zeit und auch in der komplexer werdenden Software-Entwicklung sehr viele Entscheidungen sehr schnell und ja praktisch im Tagesgeschäft.
Und das ist auch ein Grund, weshalb ich versuche, Metriken in den Unternehmen populär zu machen. Demming hat mal gesagt, wenn du keine Daten hast, bist du nur eine weitere Person mit einer Meinung. Und dem möchte ich mich da anschließen. Das ist auch ein Grund, weshalb ich versuche, Metriken in den Unternehmen populär zu machen. Metriken hatten ja schon mal einen recht guten Stand, aber mit der ganzen agilen Bewegung. Ist das so ein bisschen so, das braucht man alles nicht? Kommt mir so vor.
Oder wie ist denn da so deine Wahrnehmung? Also meine Wahrnehmung ist tatsächlich, wir haben Metriken. Wir haben jede Menge Metriken. Wir haben viele super Tools, die alle Daten erfassen und diese Daten auch irgendwie anzeigen. Das Problem ist halt die Nutzung der Metriken. Bleibt noch so ein bisschen hinter den Erwartungen zurück. Also auch wenn wir die Daten haben, müssten sie den Menschen, die sie dann auch brauchen, um diese Entscheidung im Tagesgeschäft zu treffen.
Und das ist auch ein sehr wichtiger Punkt. Und das ist auch ein sehr wichtiger Punkt. Und das ist auch ein sehr wichtiger Punkt. Und das ist auch ein sehr wichtiger Punkt. Kannst du dir vorstellen, ein Flugzeugcockpit, wo der Pilot seine Instrumentendaten auf einem Excel-Sheet sieht, das ist nicht unbedingt eine einfache Zugänglichkeit. Und wir müssen halt lernen, mit den Metriken intuitiver umzugehen. Und dafür muss es tatsächlich so einfach sein. Jetzt mal nicht Beispiel.
Jetzt mal nicht Beispiel. Und in dem Moment, wo man halt Punkte findet und sagt, okay, hier sehen wir, da wäre etwas, das wäre schöner, wenn es anders wäre, dann können wir darüber reden, wie wir es machen. Und dann kommen auch eben sehr schnell Metriken ins Spiel, die dann letztendlich auch ein Kommunikationsmittel sind, um beispielsweise Entscheidungen von Vorgesetzten dann auch zu unterstützen, indem man halt die korrekten Daten abliefert, die dann als Grundlage dienen können.
Ja, also da auch wieder die Sinnhaftigkeit der Metriken. Was kann ich denn da eigentlich dann auch rauslesen aus diesen Daten? Jetzt hast du ja einen anderen Punkt noch, Performance. Was sind da so typische Sachen, die man da nehmen und ansetzen kann?
Also die klassischen Performance-Tests natürlich, die ich bei der Entwicklung in der Pipeline direkt machen kann und wo ich dann eben auch, wenn ich diese Daten aufnehme und über die Zeit von Bild zu Bild darstelle, dann Tendenzen erkennen kann und sofort reagieren. Wenn die Performance beispielsweise schlechter wird, respektive überprüfen kann, ob meine Optimierungen den gewünschten Erfolg haben.
Also auch da würde ich sagen, nicht das Rad neu erfinden, sondern das Ganze einfach konsequent nutzen. Ja, da sagst du auch etwas Spannendes, weil ich es auch immer wieder feststelle. Du hast ja schon zweimal gesagt, das Thema Tendenzen, also wo geht so generell der Pfeil hin? Wird es besser oder schlechter? Das ist ja häufig, glaube ich, besser als eine absolute Zahl, die ja einfach auch mal vielleicht springen kann. Oder so was in Einzelfällen, aber quasi gar keinen Trend dann darstellt.
Genau, also diese Trends sind eine ganz wichtige Geschichte. Das ist auch letztendlich das, worauf ich schauen muss bei den Metriken. Wir machen gelegentlich den Fehler, dass wir versuchen, absolute Metriken zu finden, wo man dann vergleichen kann, welches Team ist besser als ein anderes Team. Da muss man sich die Frage stellen, erstens, wie relevant ist das überhaupt? Und zweitens, das ist auch unglaublich schwer.
Weil wenn ich Produktivität beispielsweise messe, meinetwegen in wie lange dauert es, eben halt eine bestimmte Anzahl Anforderungen umzusetzen, dann ist das nicht so, dass wenn ein Team weniger umsetzt, dieses Team deswegen langsamer oder schlechter ist, sondern das ist vielleicht einfach ein völlig anderer Zusammenhang, in dem das Ganze steht. Also der Kontext spielt dabei eine extrem wichtige Rolle. Ich denke jetzt gerade.
Ich denke gerade bei Produktivität, es gibt ja so viele Einflussmöglichkeiten, wenn ich jetzt sage, ich messe von der Anforderung bis zum Deployment, dann ist irgendwer krank, dann gibt es Meetings, dann macht jemand anderer die Arbeit. Also es ist ja allein die Zuordnung, wann habe ich dann an dieser Anforderung gearbeitet, wann habe ich da wirklich was dran gemacht, wie kann man denn das gestalten, ohne da jetzt in so ein Mikro-Management auch zu kommen.
Jetzt muss ich hier noch drei Minuten aufschreiben, damit wir das nachher alles durchrechnen können. Ja, also Sie sehen das. Mikro-Management, das hast du sehr schön gesagt, sollte ich natürlich vermeiden. Das hilft mir nicht weiter. Im Grunde kann ich mir eine Metrik anschauen, die Durchlaufzeit, die kann ich auch einfach messen. Also wie lange dauert es eben halt, wenn ich eine Anforderung beginne, bis sie fertig ist.
Und auch da muss ich natürlich bestimmte Fehler vermeiden, nämlich eine Vereinfachung. Zum einen darf ich Softwareentwicklung nicht als lineares System betrachten, dann bin ich schon mal komplett auf der falschen Seite. Und bei der Durchlaufzeit muss man sich einfach mal die Frage stellen, was ist eigentlich die Natur dieser Metrik. Und wenn ich ehrlich zu mir bin, kann ich nicht vorhersagen, wann eine Anforderung fertig ist. Hinterher weiß ich es. Vorher kann ich es nicht sagen.
Das ist der Charakter einer Zufallsvariable. Und eine Zufallsvariable kann ich nicht als absolute Zahl darstellen, sondern die muss ich als Histogramm darstellen. Und sobald ich das tue, erkenne ich eine ganze Menge Dinge, die mir dann helfen, auch Prognosen herzustellen. Und vor allen Dingen erkenne ich auch, also es ist eine schiefe Verteilung, die dabei entsteht, weil einige Dinge brauchen einfach manchmal unerwartet lange.
Ich erkenne auch, dass langfristige Planungen, langfristige Vorhersagen schwierig bis unmöglich sind. Allerdings kann ich diese Metrik dann für kurzfristige Prognosen hervorragend einsetzen, weil ich dann teilweise mit Simulationen wie einer Monte-Carlo-Simulation arbeite. Ja, okay. Also das ist ja schon eine hohe Schule, auch diese Dinge dann zu nutzen. Also dann auch wirklich die Sinnhaftigkeit rauszustellen.
Weil ich denke, gerade bei Produktivität, da kippt man ja schnell da rein, eben in diese Vergleichung. Jetzt schauen wir mal, welches Team besser performt. Also was ja gar nicht vielleicht der Sinn ist. Ja, das führt dann natürlich zu einem sogenannten internen Wettbewerb. Den sollte ich tun. Tunlichst vermeiden. Das ist so ähnlich wie bei Krabbenkörben. Ja. Die Fischer wissen, die können den Deckel ruhig auflassen, auch wenn die einzelne Krabbe rauskrabbeln könnte.
Sobald sie zwei Krabben drin haben, dann zieht die eine die andere dann immer runter. Und dann habe ich jede Menge Action, aber nichts passiert. Ah ja, okay. Ja, schöne Metapher, ja. So von diesen, wie würdest du denn vorschlagen, wenn jemand sagt, okay, Metriken, das ist ein Thema, da müssen wir jetzt mehr machen. Oder es wäre mal schön, da reinzuschauen. Wie kann man denn da am besten starten in einem Projekt oder in einem Team?
Ja, also wenn man sich tatsächlich das Thema Metriken bewusst vornimmt und daran arbeiten will, dann sollte man versuchen, auch wirklich einmal zu sagen, was ist eigentlich der Sinn? Was ist das Ziel, was wir verfolgen mit den Metriken? Und dann sollte ich drei Dinge in Betracht ziehen. Das eine ist eben die richtigen Metriken finden. Diese dann auch eben korrekt zur Verfügung. Diese dann auch eben zur Verfügung stellen. Dann diese Metriken lernen auszuwerten.
Ich muss etwas über die Zusammenhänge wissen. Also Performance und Qualität hängen zum Beispiel extrem dicht zusammen. Wenn meine Qualität schlechter wird, wird auch meine Performance und meine Bearbeitungszeit länger. Das heißt, ich kann im Prinzip Rückschlüsse darauf ziehen. Allerdings hängt die Performance auch noch von vielen, vielen anderen Dingen ab. Das heißt, ich muss auch andere Metriken mit einbeziehen. Und dann eben die Zusammenhänge erkennen. Und natürlich ganz wichtig die Anwendung.
Das hast du schon gesagt. Wenn ich Metriken messe und ich nichts damit mache, also dann letztendlich meine Entscheidungen überhaupt nicht beeinflusst werden von den Metriken, dann kann ich mir die Arbeit auch sparen. Also auch das muss ich mir überlegen. Wie soll das erfolgen? Ja, also ich glaube, da kann man auch echt ein bisschen Hirnschmalz reinstecken. Nämlich genau diesen Dings, was will ich denn eigentlich damit entscheiden? Also so eine Metrik. Gerade durch die Fülle.
Ich glaube, das ist auch ein bisschen so dieser Zeitgeist, dass die Dashboards immer größer werden. Weil man hat ja alles. Aber de facto wird es immer unübersichtlicher. Man weiß dann gar nicht, was man da noch damit entscheiden könnte. Genau, das ist tatsächlich eine Herausforderung, dort die korrekten Metriken zu finden. Aber wenn ich ein Ziel habe, dann wird es deutlich einfacher.
Hast du da noch so vielleicht so zwei, drei so typische Ziele, die du immer wieder siehst, was man mit Metriken machen möchte? Sowas, was den Teams kommt? Vielleicht kann man damit auch noch etwas sagen. Vielleicht kann man damit auch ein bisschen inspirieren. Ein wichtiges Ziel steht natürlich im Raum. Ich möchte Software in guter Qualität haben. Und ich möchte letztendlich auch wissen, ist die Qualität tatsächlich so, wie ich es mir vorgenommen habe?
Und das ist eine gute Motivation, weil letztendlich wollen wir mit den Metriken besser werden. Also durch die Metriken besser werden. Und eine Sache zeigen mir Metriken sehr gut. Wo befinde ich mich? Bin ich irgendwo im Mittelfeld oder an der oberen Grenze oder an der unteren Grenze? Und auch das ist durchaus eine Motivation herauszufinden für sich selbst, nicht im Wettbewerb. Wo stehe ich eigentlich und was kann ich tun, um besser zu werden?
Ich finde, das ist noch ein schöner Gedanke, auch zu sagen, okay, das muss jetzt gar nicht so aus dem Team herauskommen, sondern das kann ich vielleicht ich als Entwickler, Entwicklerin, Tester, Testerin automatisieren oder in welcher Rolle ich auch immer gerade bin, zu schauen, okay, wie kann ich Metriken für mich nutzen? Also gar nicht so sehr für das gesamte Team.
Man muss es nicht gleich so riesengroß aufblasen, sondern einfach auch für sich mal zu schauen, wie kann ich die nutzen, um meine Arbeit besser zu machen? Es ist immer eine gute Idee, bei sich selbst anzufangen. Und ich habe in meinem Vortrag auch so ein schönes Bild mit konzentrischen Kreisen, wo die Person in der Mitte ist. Einige Metriken sind tatsächlich nur für mich selbst. Die braucht auch niemand anders sehen. Damit kann ich arbeiten. Da kann ich mich selbst verorten.
Dann gibt es halt die Teammetriken. Das geht dann halt weiter. Die dem Team helfen, sich zu verorten. Das ist dann auch nichts, was ich unbedingt dem Management zur Verfügung stellen müsste, weil die damit einfach nichts anfangen können, weil die den Kontext nicht kennen, den Zusammenhang auch nicht kennen müssen.
Aber ich kann eben basierend auf diesen bereits guten Metriken dann weitere finden, die dann, die dem Management zur Verfügung gestellt werden, weil die ja auch wichtige Entscheidungen treffen müssen und dies möglichst eben auch basierend auf verlässlichen Daten tun sollten. Super. Ja, es ist schon ein schönes Bild, bei sich selbst anzufangen. Ich glaube, da können wir hier auch nur aufrufen an der Stelle, einfach mal bei sich anzufangen und zu schauen, was könnte denn da auch passen.
Es ist eine spannende Reise, auf die man sich dann begibt. Das denke ich auf jeden Fall, ja. Ja, Mike, super. Vielen lieben Dank für diese Einsichten. Ein spannendes Thema. Das kann man, glaube ich, kann jeder für sich auch nochmal ein bisschen vertiefen und zu schauen, was man da rausziehen kann, welchen Impuls man da vielleicht auch bei sich umsetzen möchte. Ich danke dir schön, dass du hier warst. Ja, ich danke auch. Ja. Vielen Dank, dass ich hier sein durfte.
Auf jeden Fall. Und viel Spaß noch bei der Konferenz. Dankeschön.