Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute im Podcast ein ganz besonderer Gast, Manfred Baumgartner. Ich glaube keinen kenne ich so lange im Bereich Software Testing wie Manfred, denn er hat mir mein richtig erstes großes Testprojekt verschafft. Aber wir haben nicht nur Testprojekte gemeinsam gestemmt, wir haben auch einige Bücher zusammengeschrieben und eines, Softwaremetriken, ist gerade in der
zweiten Auflage erschienen. Und darüber unterhalten wir uns. Wofür können wir Softwaremetriken gebrauchen? Welche gibt es überhaupt? Was kann ich alles messen? Und wie fange ich am besten an? Und jetzt viel Spaß bei der Folge. Hallo Manfred, schön, dass du da bist. Servus Ritschi. Ebenfalls schön, dich so frisch und munter zu sehen. Es ist wirklich frisch. Es ist ja, naja, es ist Frühjahr Nachmittag. Genau, du bist gerade aufgestanden.
Ja, schön. Eine Live-Schalte nach Wien sozusagen in meine Heimat. Und also von allen Podcast-Gästen, die ich bis jetzt hatte, kennen wir uns, glaube ich, am längsten, weil du warst so mit mir der Einstieg, also du warst mein Einstieg in Software Testen.
Genau, ja. Das war ja schon, was war es, 2005 oder so, man darf ja gar nicht wirklich zurückrechnen, also das ist ja doch schon sehr lange Zeit, sehr lange gemeinsame Zeit, gemeinsame Projekte, gemeinsame Kundenprojekte und doch einige gemeinsame Buchprojekte auch. Genau, genau. Also das war ja damals so mein großer Schritt ein bisschen ins Consulting, in die Beratung. Und das hast du mir ja auch mit ermöglicht und du warst ja damals
auch Testprojektleiter für das Projekt, das wir gemacht haben. Da konnte ich auch ganz viel lernen. Und ja, und nicht nur die Abende an der Hotelbar und im Testcenter haben uns da geprägt, sondern auch das gemeinsame Buchschreiben, das wir ja durch Harry, den Dritten im Bunde, ja da auch begonnen haben. Und das ist ja auch mit das Thema, warum wir heute hier miteinander sprechen, weil ganz druckfrisch, fast, also zu dem Zeitpunkt, wenn die Folge erscheint zumindest,
gibt es die zweite Auflage vom Buch Softwaremetriken, ehemals Software in Zahlen. Die zweite Auflage heißt Softwaremetriken. Ja, und da wollen wir uns jetzt einfach mal ein bisschen auch drüber unterhalten und auch generell vielleicht über das Thema der Metriken und so. Und du bist ja schon ein lang gedienter Testmanagement- und Testingfuchs. Sind denn für deiner Meinung nach so Metriken eigentlich sinnvoll? Ja, das ist eine gute Frage, berechtigte Frage, weil es ist ja auch ein Thema,
mit dem man sich oft nicht so ganz gern auseinandersetzt. Ja, zum einen, ja, ist es ja auch eine gewisse Arbeit, Metriken zu erheben, um sich darum zu kümmern. Und zum anderen kommen durch Metriken auch manchmal weniger erfreuliche Tatsachen zutage, dass man sagt, manchmal will man es gar nicht so genau wissen, wie sich denn vielleicht die Metriken erlauben. Und daher ist es schon so ein Thema, das aus meiner Sicht über die ganzen Jahre hinweg und immer schon eher
stiefmütterlich betrachtet wird. Also wo selbst einfache Metriken nicht so wirklich gut und vielleicht sinnvoll auch wirklich dann auch angewendet und genutzt werden. Aber generell, also ich habe gerade im Vorfeld geredet, mit was kann man es eigentlich vergleichen, das Thema Metriken? Und natürlich gibt es immer Vergleiche, die auch hinken. Aber Software und Softwareentwicklung hat schon ein bisschen, muss immer etwas anderes zu sein,
ja. So ein bisschen künstlerisch und ein bisschen weg von diesem Ingenieurmäßigen. Aber das ist in dem Fall natürlich auch, es ist ein Ingenieurbereich, ja. Aber lustigerweise ein, in dem relativ wenig über Metriken gesprochen wird, wo doch immer noch relativ wenig Metriken angewendet werden, ganz im Gegensatz zu anderen Produktionsverfahren oder Ingenieurtechniken. Und in Wirklichkeit kann man es ein bisschen so mit vergleichen. Also allgenehm, du fährst mit dem Auto, du hast ein
Auto, heutzutage hast du ein Auto und das hätte keine Sensoren. Also keinen Tacho, du weißt nicht so genau, du merkst nur, du bist langsam, schneller. Ungefähr hast du ein Gefühl, wie schnell du gerade bist, aber das ist umgebungsabhängig. Es gibt Umgebungen, da sind 40 km/h schon schnell, ja. Und auf der Autobahn sind 40 km/h vielleicht sehr langsam und das merkst du, ohne dass du einen Tachometer hast. Aber ohne Tachometer hätte ein komisches
Gefühl, ja. Drehzahlmesser, das kannst du auch hören, da schaue ich weniger drauf, muss ich ganz sagen. Aber zum Beispiel eine Tankanzeige, wie viel habe ich eigentlich noch drin, wie weit komme ich noch? Das ist schon recht hilfreich. Das gilt auch in einem Projektverlauf, wie viel Budget habe ich noch, wie viel Zeit habe ich noch, wie auch immer. Alle diese Fragestellungen sind natürlich da interessant und viele Projekte, glaube ich, sind wirklich so unterwegs, als hätten sie alles
das nicht. Kein Tacho, keine Tankanzeige, keine Drehzahlmesser, nichts. Und geschweige dann, jetzt halt der Navi oder so was, ja, ist ja letztendlich auch sowas ähnliches. Und mir sind viele dieser Dinge jetzt wieder bewusst geworden, wo wir auch wieder die Überarbeitung von den Zahlen, jetzt Softwaremetriken gemacht haben, wo wir gedacht haben, ja, gescheit, gescheit, gescheit. Und in dem Buch sind irrsinnig viele Metriken drinnen. Das ist ein Kompendium an
Softwaremetriken, die man da anwenden kann. Und das heißt ja nicht, dass man all diese Metriken einsetzen muss und auch nicht kann, aber manches ist schon sinnvoll und manches ist auch relativ wahrscheinlich einfach zu bewerkstelligen. Und insofern sind eben Metrik wirklich auch eine Hilfe zu wissen, wo steht man, aber auch, wie weit komme ich noch und wie weit muss ich noch. All diese Dinge kamen über Softwaremetriken oder diverse Software- und Projektmetriken,
wenn man es jetzt genauer nimmt, natürlich da auch erfahren. Ja, ich selbst habe diese
Metriken gerne genutzt. Alleine die Metriken, die man aus dem Fehlermanagement herausziehen kann, aber auch aus dem, zum Beispiel Testdesignmetriken, Testfallmetriken, Durchführungsmetriken, Fehlerraten und, und, und einfach auch zu wissen, wo steht man und zum Controlling, um auch entsprechende steuernde Maßnahmen zu setzen, extrem hilfreich, relativ einfach, wenn man sich das mal hergerichtet hat, auch mal zu gestalten und in vieler, vieler Hinsichten
nützlich. Ich glaube, das ist auch etwas, was dieses Buch ja auch irgendwie, finde ich, ausmacht, ist dieses, wie du sagst, so ein Kompendium an diesen unzähligen Metriken. Und für mich war damals schon, als wir damals mit der ersten Version begonnen haben, diese, allein diese Kategorisierung schon total hilfreich. Es gibt Metriken für Quantität, also die so irgendeine
Menge berechnen von irgendwas, dann Metriken für die Qualität und für die Komplexität. Und dieses, dieses Gereich, diese Dreiklang, das fand ich immer schon total hilfreich auch, denn gerade, gerade so Quantitätsmetriken, das ist so, das ist immer so lapidar, aber auch einmal zu wissen, wie viele Testfälle hat man denn eigentlich, wie viele Lines of Code, wie viel, aus wie vielen
8 Fakten besteht eigentlich so mein ganzes Ding? Auch das ist ja schon mal eine interessante Aussage, gerade wenn ich mal irgendwie überschlagen muss, was brauche ich denn eigentlich am Test aufwenden oder solche Sachen dazu. Ja, und auch, und das Wichtige ist auch, sozusagen dieses Zusammenspiel dann auch dieser Metriken. Und es gibt ja manche Metriken, die sind ja einfacher. So Quantitätsmetriken, ich kann die Lines of Code zählen, ich kann
die Anfälle der Testfälle zählen, ja, dann hat man mal eine Zahl. Aber um zu wissen, was bedeutet das eigentlich, muss man sich das oft noch in Beziehung setzen, zum Beispiel einfach auch mit weiteren Metriken, ja, oder sie gegeneinander oder zueinander in Beziehung setzen. Also, wenn ich 10 Testfälle habe, aber ich weiß nicht, 500.000 Lines of Code, dann wird ziemlich klar, dass das vielleicht nicht so zusammenpasst. Das Buch zeigt natürlich auch
auf, dass es hier nicht einfach nur eine Regel gibt. Also sieh, für 100.000 Lines of Code brauchst du 150 Testfälle, sondern jedes Software schreibt sich anders. Unterschiedliche Software Sprachen generieren unterschiedliche Anzahlen von Lines of Code. Wenn du nur mit Libraries arbeitest, hast du natürlich wenig selbstentwickelnden Code, musst du dafür alle, für allen Code und Testfälle haben. Da muss man sich schon intensiver damit auseinandersetzen, ist eben nicht so einfach.
Aber so wie du sagst, das Buch unterscheidet einmal in der einen Dimension zwischen diesen Themen Quantität, Komplexität, auch ganz wichtig, das ist schon ein bisschen schwieriger zu messen, ja, denn Komplex ist eigentlich Software. Und eben auch die Qualität, nachdem dieser Begriff ja auch nicht so allgemein definiert ist, auch nicht so einfach, aber natürlich kommt es auch auf die Qualität an. Und dass eben zum Beispiel auch die Komplexität wesentlich aufwandsbestimmender
ist natürlich für einen Test oder Retest, als wie zum Beispiel eine Quantität. Aber das drückt sich da drinnen aus und das Buch bietet eben verschiedene Perspektive auf dieses Thema. Ich glaube, in der weiteren, das ist eine Dimension, die da drinnen abgebildet wird. Die andere Dimension ist dann natürlich, was betrachte ich eigentlich? Und da ist zum einen einmal die, ich sage mal so, die ganzen, es geht ja nicht nur um den Code der Applikationen,
sondern auch Messung von Anforderungen, Anforderungsdokumenten. Jetzt könnte man sagen, heutzutage, es gibt ja keine Anforderungen mehr, das sind alles nur mehr Stories in irgendwelchen ergiegen Projekten, da habe ich nichts mehr zu messen. Es ist tatsächlich dort ein bisschen schwieriger auf Basis von dokumentierten Wörterdokumenten oder sonst, oder Text quasi, eine Menge oder Komplexität abzuleiten. Dort, wo ich aber Beschriebenes habe, also Lastenpflichten,
Hefte, was auch immer, gibt es die Möglichkeiten schon. Oder wenn ich, wenn ich mehr modellgetrieben meine Anforderungen definiert habe, auch da gibt es natürlich Möglichkeiten, das auch zu messen und dazu entsprechende Maßzahlen zu definieren. Aber wie gesagt, die Anforderungen, was wir sagen, eine Dimension, die hier vermessen wird oder bewertet wird, wo es Metriken dazu gibt, dann gibt es das selber natürlich auch für den Entwurf, also auch für die Architektur,
im Software-Design, wenn man so will. Auf das, was man am meisten zuerst denkt, das sind natürlich die Code-Metriken, also wie viele Lines of Code habe ich, wie viele Code-Do, ich kann die Code-Do-Statements von damals noch messen. Heutzutage sind es halt Klassenaufrufe oder Lines of Codes und diese ganzen Dinge. Dann haben wir da drinnen auch dann die Testmetriken oder Dinge eben auch mit Fokussierung auf die Test-Deliverables und Testergebnisse,
die genauso vermessen werden können. Also das sind quasi die verschiedenen Objekte der Messung. Ja, genau. Also, dass man die auch noch, dass man sich eben nicht nur auf den Code auch konzentriert, sondern eben auch Entwürfe, Architekturen, Anforderungen, Tests und so
mit betrachtet und dort eben auch Metriken entwickeln kann. Ich glaube, das ist für, also wenn man sich das erste Mal mit dem Thema beschäftigt, denkt man gar nicht dran, dass es auch Architekturmetriken gibt oder, also man hat immer ganz klar, Lines of Code, das ist immer schnell, das sieht man manchmal schon im Editor irgendwo drinnen und auch die Testfallanzahl sehe ich in meinem Testmanagement-Tool und so, aber dass es da noch viel mehr gibt,
ich glaube, das ist oft gar nicht bewusst und gerade so findigere Metriken dann auch in den Entwurfsdokumenten, also da sich dort meine Komplexität oder sowas anschauen, das kann ja auch helfen dabei, das für ein Refactoring oder sowas, um die Dinge dann wieder einfacher zu machen. Ich meine, das ist ja quasi noch die nächste Dimension. Natürlich immer, wenn ich Metriken habe, auch immer die Frage stellen, wofür, was will ich
damit machen, was will ich damit tun? Und da gibt es eben dann die verschiedenen Metriken, die da auch erklärt sind im Buchstab, verschiedene Nutzen, Nutzbarkeiten. Zum einen geht es natürlich zum Beispiel aus Entwurfsmetriken, dass ich vielleicht ableiten kann, okay, welcher Aufwand geht hier auch in die Umsetzung und in die Entwicklung? Auf Basis des Entwurfs, wie viel
Entwicklungsaufwand auf Basis des Entwurfs, wie viel Testaufwand? Das sind natürlich Fragestellungen im Sinne von der Planung und Projektierung eigentlich von Vorhaben oder Teilvorhaben als Test oder Entwicklung. Zum anderen dient es auch natürlich der Qualitätssicherung dieser Testobjekte selbst, also des Entwurfs zum Beispiel selbst. Und da gibt es ja Verfahren, um zum Beispiel wirklich zu überprüfen, sind Standards, sind gewisse Kriterien eingehalten.
Also man könnte in einem Entwurfsdokument zum Beispiel alle Möglichkeitsformen zählen. Reihen Sie mal den Syntax durch, checken und wie viele Optionen oder Möglichkeiten bietet noch dieser Entwurf für eine spätere Umsetzung. Das ist auch ein Qualitätsmerkmal. Wenn in jedem zweiten Satz ein "vielleicht" oder "es könnte" oder "unter Umständen" oder solche
Formulierungen drin sind, tut man es in der Umsetzung besonders im Test schwer. Interessanterweise haben da die Entwickler weniger Probleme damit, weil das bietet natürlich mehr Entfaltungsspielraum. Und Ähnliches gilt natürlich auch in der Architektur, um hier auch die Qualität des Dings selbst zu messen. Aber eben die Projektierung und Schätzung und Planung auch anderer und weiterer Aktivitäten ist da natürlich auch relevant. Ein großes Thema, auch eine Grundlage
dieses Buches ist zum Beispiel Softwaremigration. Wenn ich sage, ich nehme das Teil, was ich habe und möchte es neu entwickeln oder ich möchte es refactoren, ganz egal, ist es schon gut, wenn man ungefähr weiß, mit welchem Volumen hat man es zu tun und mit welcher inneren Qualität. Wenn das halt wirklich Kraut und Rüben oder sonst irgendwas ist, ist das was anderes, als wenn das vielleicht straightforward und sehr gut entwickelt ist. Aber wie gesagt,
so Mengenzahlen sind natürlich interessant. Natürlich ist auch eines bei diesen Metriken, immer so eine punktuelle Messung zu machen, ist die Interpretation oft schwierig, weil das natürlich auf Applikation oder in jeder Organisation immer ein bisschen anders interpretiert und justiert werden muss. Daher macht es auch Sinn, für ein Unternehmen sich zum Beispiel solche Maßzahlen als Rahmen oder als Leitlinie zu geben, wo man halt iterativ auch die Bewertung,
wie justiere ich quasi solche Berechnungen, wo man das laufend anpassen kann. Es ist leider schwer übernehmbar von einem Unternehmen oder von einer Applikation auf die andere. Es gibt zumindest eine Anleitung. Genau, es gibt ja oft so, dass ja auch gerade der Trend auch eine Maßzahl sein kann. Also, wenn ich öfter zu so alten Projekten komme, die fangen dann an mit einer statischen Analyse, machen dann ihre Metriken darüber über den Code
und dann kommt raus, das ist total viel. Und dann mal zu sagen, es darf einfach mal nicht schlechter werden, dann muss ich natürlich den Trend anschauen, dass das halt einfach auf dem Level bleibt, obwohl was umgebaut wird, obwohl was dazu entwickelt wird, dass es zumindest die Trendfunktion dann da erhalten bleibt. Und ich glaube, da kann man sich auch ein bisschen Druck rausnehmen, vielleicht alte Sachen, wenn man das von so einer Metrik erschlagen wird, dann da auch wirklich
alles umbauen zu müssen. Und ich finde auch, dass was du sagst mit diesen Entwicklungsphasen, also ich hatte ja ein Projekt mal mit Harry, wo es auch darum ging, da waren ja Systeme in verschiedenen Programmiersprachen gebaut und die Frage war, welches entwickelt man weiter? Die
können alles ähnliche, aber irgendwas muss man, was soll der Dienst? Und da mal zu schauen, okay, da hat man natürlich mit Metriken die Möglichkeit, wenn man sagt, programmierspezifisch, das sind die Komplexitäten, das sind die Qualitäten in dem System, um mal ein Gefühl dafür zu bekommen, was hat man denn da eigentlich vor, welches entwickle ich weiter und welches lasse ich vielleicht aussterben. Genau, richtig. Und wie gesagt, das ist auch hier getreten und es gibt ja auch die Werkzeuge und
Tools dazu. Zum weitesten haben wir zum Beispiel Function Point Messung. Function Point ist ein bisschen ein genormter Maß für eine Umfangmenge von Softwareapplikationen. Und das kann man dann auf Basis eigentlich des Codes, bestehenden Codes messen, kommt man einfach zu einer Bewertung, einer Zahl, natürlich muss man die Parameter konfigurieren, aber man bekommt eine Aussage und kann eben auch diese fachliche Menge, die dahintersteckt, hinter Software ein bisschen
einordnen, in Größenordnung. Das kann eben auch für die gesamte Entwicklungs- und Portfolioplanung auch sehr wichtig und relevant sein, dass man da irgendeinen Anhaltspunkt hat. Man weiß nie so genau, was man hat. Du bist ja immer noch viel in Projekten unterwegs und du kriegst mit, wie unterschiedliche deiner Kunden ihre Projekte machen. Was siehst du denn da für Metriken? Gibt es denn da überhaupt welche, die reported werden oder denkst du, ich könnte da viel mehr machen
und muss die erst quasi mit reinbringen? Oder gibt es so eine, die du immer wieder findest, wo du sagst, ach, sehr schön, dass sich die zumindest etabliert hat? Also jetzt aus Testsicht, da gibt es natürlich schon auch immer diese, der Klassiker ist, wenn man so will, diese Fehler, diese Fehler und Fehlertrends und wo steht man so in der Messung des Ganzen. Aber da würde ich mir manchmal schon ein bisschen noch mehr wünschen im Sinne der Interpretation testen. Es beginnt auch
ein bisschen zu verschwimmen. Im Zuge der agilen Projekte, du hast halt wieder oft Projekte, da wird nicht jeder Fehler irgendwann einmal wirklich so explizit in einem Fehlermanagement Werkzeug dokumentiert. Ich bin eher vor allen Dingen zu dokumentieren, auch um zu sehen, wo steht man eigentlich mit der Arbeit, was ist alles schon erledigt. Aber da verschwimmt es.
Aber es gibt auch Unternehmen, die auch dort sehr konsequent eigentlich das auch weiterführen und die Dinge nicht einfach irgendwo in einen nicht auswertbaren Backlog zum Beispiel verschwinden. Was schon geschaut wird, das sind vielleicht so Metriken, die in dem ganzen CI-Prozess, CI/CD-Prozess drinnen sind oder wo man auch Code-Abdeckungsmessungen zum Beispiel auf Unitest-Ebene machen kann. Das ist schon, aber sich vielleicht noch zu wenig mit der
wirklichen Qualität, Umfang und Interpretation dieser Zahlen auseinandersetzt. Aber auf dieser technischen Ebene durchaus. Aber würde ich mir wehrwünschen. Ich glaube, das ist das, was du vorher auch gesagt hast. Wofür brauche ich die Metrik und was kann ich daraus lesen? Also es ist ja auch, sagen wir mal, bei so Test-Reporting oder bei solchen Sachen geht es ja auch immer
darum, was mache ich denn mit diesen Informationen und was steckt da eigentlich drin? Da wissen wir das ja auch, wenn zwei Testfälle rot sind und das heißt ja nicht, dass wir nicht releasen können. Das kann ja auch trotzdem gehen, wenn die jetzt nicht so kritisch sind oder sowas und dann führt man das weiter. Also was lese ich denn aus diesen Dingen eigentlich raus? Ich glaube, das ist total
wichtig, sich darüber auch Gedanken zu machen. Absolut. In dem Sinn gibt es auch in dem Buch, ja neben diesen, also wir hatten diese eine Dimension, die Dimension der zu testenden Objekte.
Es gibt ja dann auch noch die Betrachtung, im Buch nennt es sich quasi diese Produktivitätsmessungen, die von letztendlich sozusagen der Softwareentwicklungsproduktivität, der Wartungs- und Wartungsproduktivität, wo es einfach auch darum geht, wie viel Aufwand geht eigentlich hinein in die Entwicklung und in die Wartung und Betreuung der Systeme, auch um hier
zum Beispiel Kostenkalkulationen entsprechend auch aufstellen zu können und zu wissen. Aber dafür braucht man natürlich auch eine Erhebung und Zuordnung der entsprechenden Aufwände und Kosten. Und da gibt es oft schon eben auch das Problem und die Mängel, dass man diese Informationen
teilweise nicht hat. Ja, genau. Also ich habe da Projekte, wo zum Beispiel in den Testprojekten, da ist der Fachbereich zum Beispiel massiv involviert, da ist nicht jede Stunde des Fachbereichs auf irgendwelche Testprozesse dann runtergebrochen, erfasst, sondern gar nicht, teilweise, das ist einfach seine Arbeitszeit. Und daher ist es auch nicht so einfach, aber das ist
auch natürlich das Ziel zu schauen, wo stehe ich eigentlich mit meiner Produktivität. Und jetzt in Magillen gibt es ja auch durchaus die ganzen Burnout, Down, Burnup, wie auch immer die ganzen Charts heißen. Aber auch da habe ich so manchmal die Befürchtung oder auch schon gesehen, dass man es jetzt irgendwie vorgenommen hat, aber irgendwie im Trubel dann wieder verschwindet das. Und werden nicht immer entsprechende Maßnahmen daraus abgeleitet und was jetzt wirklich die Velocity
ist und was nicht schwer in messbare Zahlen bringenbar. Es ist natürlich auch immer A, ein bisschen an Aufwand das zu betreiben und B, vielleicht will man es wirklich nicht ganz so wissen. Genau und auf wen interessiert es? Also vielleicht ist es ja auch für das Team jetzt nicht wirklich interessant, wie viel sie schaffen, die wollen einfach nur ihr Zeug machen und nur weil der Manager sagt, jetzt hier müsst ihr das alles super tracken,
dann funktioniert das ja meistens auch nicht so wirklich. Das muss dann auch gewollt sein. Jetzt wenn jetzt jemand sich unser Buch hier kauft oder sagt, wir sollten uns auch mal mit dem Thema Metriken beschäftigen, was wäre denn so dein Tipp, wie geht man es an, wie kann man starten damit oder wie kann man auch mit dem Buch gut arbeiten? Es ist jetzt als Roman zum Einschlafen, also vielleicht schon, aber es ist jetzt nicht die Urlaubsliteratur.
So richtige Urlaubsliteratur ist es natürlich nicht. Aber ich denke, gerade auch diese Kapitel, dass man sich mal ein bisschen Gedanken macht und sich anschaut, das Bewusstsein der Dimension, Quantität, Komplexität, Qualität, das kann man sich schon einmal so durchlesen, sage ich jetzt einmal. Es werden dann quasi die Basismessungen, die da drin definiert sind, ja dann in den anderen Einsatzszenarien in der Testmetrik oder in der Produktivitätsmessung
wiederverwendet aus Sicht genau dieses Bedarfs. Aber es ist tatsächlich, das ist dann glaube ich das viertes Kapitel, genau, im fünften Kapitel kann man dann wirklich so punktuell einmal hineinschauen, was heißt denn das Anforderungsmessung, komisch, was kann man denn da messen. Aber es gibt ja auch den Index, wo man auf spezifische Metriken aufgehen kann. Es ist ja quasi zu all diesen Dimensionen, wenn ich da hineinschaue, sind ja auch verschiedene Ansätze der Messung für alle
diese Dimensionen vorhanden. Also wenn ich da jetzt hineinschaue zum Thema Entwurf, da gibt es halt irgendeinen Meckeransatz von Tom Gilb, dann haben wir ein Burschmessung nach Kart und Gleis, da gibt es ja verschiedenste Ansätze der Messung, es gibt ja nicht eine einzelne einheitlich normierte Messung von einem ISO und Wammers Institut. Das ist durchaus, da ist sich einfach mal das Interessante, sich das anzuschauen und die Möglichkeit sich zu überlegen, für mich,
in meinem Umfeld, was wäre eigentlich hier spannend und interessant für mich. Und wenn ich es jetzt ein bisschen aus Test sich sehe, ich denke, wäre es schon auch interessant zu wissen, habe ich meine Anforderungen in irgendeiner Form fachlich abgedeckt im Szenario. Beispiel, ja, ist ein Beispiel. Das, was ich, das werde ich auch in einigen Projekten auch in einem gemeinsamen großen Frequenz gemacht haben, das sind meine Prozesse, meine Szenarien oder jetzt
fachlich, das können es aber auch Storys oder Epics sein, ist ja egal. Wo ich das als Tester gesagt habe, na gut, ist das jetzt komplex oder klingt das einfach, wie auch immer. Und das ist einfach nur eine Liste mit Komplexitätszuordnung und wir haben damals nur gesagt, okay, für Niederkomplexität brauche ich zwei, drei Testfälle, für Mittelkomplexität vielleicht zehn, für hoch 20 und dann gibt es noch so Unsichere, das könnten potenziell hunderte werden, kann man auch noch
machen, so kategorieren. Das haben wir gemacht und dann zusammengezählt und in einem agilen Ansatz habe ich vielleicht nicht die ganze Liste schon am ersten Tag. Das entwickelt sich. Aber wir haben das zum Beispiel so gemacht, wirklich nichts anderes gemacht, als wie Geschäftsvorfall oder Use Case, Komplexität, Anzahl Testfälle und entsprechend dieser Anzahl. Und dann haben wir Testfälle geschrieben in die Woche und wir hatten eine große Erstschätzung auf Basis der summierten
Testfälle, sagen wir 500 Testfälle mal x Tage, so viele Tage wir haben ungefähr gebraucht. Ganz simpel. Und wir haben dann nach dem ersten Sprint, wenn man so will, geschaut, wir haben das so eingeschätzt, Komplexität, wir haben so viele Testfälle geplant und so viel haben wir entworfen, haben also mit dem Gefühl, das ist ausreichend, das passt und haben das dann zusammengezählt und haben entsprechend justiert, dass wir gesagt haben, okay, Komplex ist so viel, Niedrig ist so viel.
Wir haben letztendlich quasi unseren Plan, unsere Inhalte im Planwert, von mir aus zahlengetrieben, aber dann inhaltsgetrieben angepasst. Zahlengetrieben mal definiert und inhaltsgetrieben angepasst. Wir hatten am Ende, glaube ich, des Projekts ein, und wir haben das hinterlegt, kann sich erinnern, hinterlegt auch mit, wie viele Fehler erwarten wir pro Testfall. Auch das weiß
man ungefähr, wenn man historische Daten hat. Und am Ende des Projekts waren wir, glaube ich, plus oder minus 10 Prozent der Fehleranzahl, die wir ursprünglich Monate davor angeschätzt haben. Aber auch durch die Justierung, durch ein Gesetz der großen Zahl, letztendlich sind wir ungefähr auf diesen Planwert hingekommen. Das ist schon spannend, das mal so zu erleben und zu erfahren und man weiß dann auch ungefähr. Es war leider auch nicht so nett, weil man hätte können sagen,
wir haben viele Fehler gehabt mit den ersten Sprints. Man muss dann nicht die Hoffnung haben, dass die nächsten Sprints den nächsten wesentlich besser werden. Die Hoffnung kannst du haben, aber sie ist meist unberichtet. Damit hat man schon noch ein bisschen Projektion in die Zukunft. Man kann das handeln, man kann zusätzliche Testressourcen vielleicht herbeiziehen, man kann ein Warning an die, ein Five-Minute-Warning oder so was an die Projektleitung geben. Das geht
sich nicht aus. Also man kann jetzt optimistisch sein und sagen, okay, wir haben gerade dummerweise die ersten zehn Geschäftsfallfälle genommen, die sowas so ein Problem hatten. Die anderen 30 sind fehlerfrei. Es zeigt sich, es verteilt sich mehr oder weniger statistisch. Das war sehr hilfreich, das war sehr hilfreich und es war vom Zugang her sehr simpel. Ja genau, gleichverständlich gut darstellbar und ein sehr pragmatischer Zugang. Wir haben es
ja leichtgewichtig vorangetrieben und das finde ich, so kann es ja auch sein. Es muss nicht immer eine komplexe mathematische, statistische Formel sein. Das kann manchmal auch einfach sein, so eine Metrik zu nutzen. Aber ganz wichtig, vielleicht noch einmal zum Essen, sie mal natürlich einen Überblick verschaffen. Damals hat es halt noch so
ausgeschaut, das Buch. Jetzt schaut es ein bisschen in der neuen Version aus. Was eigentlich so geht, ich war jetzt auch in der Durcharbeit wieder, auch wieder viel ist wieder in Erinnerung gekommen, sich heraussuchen, was man vielleicht im Projekt anwenden kann, zielgerichtet. Weil jede dieser Metriken, sie kommt einfach nicht so herausgegossen. Man muss schon ein bisschen was dafür tun. Ja super, vielen Dank Manfred für diese Einsichten. Die treuen Podcast-Hörer wissen,
was jetzt kommt. Nämlich, natürlich, wenn wir ein Buch vorstellen, dann gibt es auch eine Verlosung. Also es werden fünf Exemplare hier verlost. Der Link ist unten in den Show Notes mit drinnen und wir wollen schon noch mal das handsigniert hinbekommen mit Essen, Wien, mit der Distanz. Aber da schauen wir mal. Auf jeden Fall gibt es die Bücher zu gewinnen. Und ansonsten, wenn dich das Thema für Softwaremetriken interessiert hat, dann kannst du gerne auch Manfred und mich
anschreiben. Da gibt es auch unsere Kontaktdaten natürlich drinnen. Manfred, ich danke dir schön für das Gespräch. Das war super interessant. Ich freue mich auch auf unsere nächsten Projekte. Wir haben ja noch ein paar Buchprojekte in der Zeit. Auf neue Auflagen bedürfen. Also da werden wir auch wieder quatschen dazu natürlich. Ja, und ich schicke mal ganz liebe Grüße nach Wien und sage danke und bis bald. Auch liebe Grüße und bis bald. Servus. [Musik]