Frank Witte Metriken für das Testreporting Analyse und Reporting für wirkungsvolles Testmanagement Metriken für das Testreporting Frank Witte Metriken für das Testreporting Analyse und Reporting für wirkungsvolles Testmanagement Frank Witte Landshut, Deutschland ISBN 978-3-658-19844-2 ISBN 978-3-658-19845-9 (eBook) https://doi.org/10.1007/978-3-658-19845-9 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detail- lierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verar- beitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröf- fentlichten Karten und Institutionsadressen neutral. Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany Vorwort In Software-Projekten ist eine der zentralen sich stellenden Fragen, wie man die eigenen Ergebnisse dem Management wirkungsvoll präsentiert. Das Projektmanagement, überge- ordnete Stellen und verantwortliche Entscheidungsträger müssen erkennen, wie es um das Projekt steht und wo es Handlungsbedarf gibt. Das Testmanagement soll zeigen, ob es die vorgegebenen Ziele erreichen kann oder ob spezielle Maßnahmen getroffen werden müssen. Leider ist heute das Reporting auf der einen Seite zu umfangreich, andererseits aber oft inhaltsleer, und leider ist das Management in vielen Fällen nicht bereit, weiter ins Detail zu gehen; man versucht sogar eher, kritischen Fragen aus dem Weg zu gehen. Das Repor- ting kann mit der technischen und inhaltlichen Komplexität, die von neuen Systemen und aktuellen Technologien gefordert ist, in vielen Fällen nicht mehr Schritt halten. Es ist eine große Herausforderung, die wesentlichen Daten so aufzubereiten, dass man eine mehrdimensionale und schwierige Botschaft wirkungsvoll seinen Adressaten präsen- tieren kann. Das führt dazu, dass Metriken, die anhand ausgewählter Daten, Indizes und Kurven eine grafische Aufbereitung bestimmter Sachverhalte plakativ darstellen, in den vergangenen Jahren eine immer größere Bedeutung bekommen haben. Die zentrale Bedeutung des Softwaretests wird mehr und mehr als projektkritisch erkannt und führt dazu, dass man Metriken über den Projektstand vom Testmanager einfordert. Metriken sind wie ein Fieberthermometer: Sie sollen zeigen, wie gut oder wie schlimm es um das Testprojekt steht. Man kann durch die richtige Interpretation und Bewertung von Metriken weitaus besser dokumentieren, warum bestimmte Probleme im Projekt aufgetreten sind. Messungen bestimmen unser Leben, ob im Bau, im Handwerk, in der Medizin oder in der industriellen Fertigung. Schon früh in der Geschichte der Menschheit war das Maß wichtig, um eine Orientierung zu schaffen und Erkenntnisse einordnen zu können, um Vergleichbarkeit herzustellen und um ein gemeinsames Verständnis, einen gemeinsamen Kompass für alle Betrachter zu schaffen. Messungen erlauben Vergleichbarkeit von Daten und eine Einordnung von Erkenntnissen in ein Koordinatensystem. Das Messen von Wegstrecken und Entfernungen ist eine Grundlage für die Schifffahrt, Logistik und Ver- kehr. In der Medizin werden zahlreiche Werte des Körpers gemessen, um den Gesund- heitszustand des Patienten festzustellen. Um diese Werte sinnvoll zu messen, muss man V VI Vorwort wissen, welche Parameter dazu herangezogen werden müssen: die Größe, das Gewicht, die Körpertemperatur, der Blutdruck, der Cholesterinspiegel oder der Körperfettanteil sind unterschiedliche Größen, die auf Probleme an der einen oder anderen Stelle hinweisen können. Bei der Arbeit mit Metriken werden Indexwerte gebildet: Der BMI setzt Größe und Gewicht miteinander in Beziehung und erlaubt dadurch die Vergleichbarkeit von Sachver- halten, die aus zwei Größen bestehen. So ist es auch bei einem Softwareprojekt, und ana- log zum Body-Mass-Index gibt es auch hier Indexgrößen die unterschiedliche Kenngrößen sinnvoll in Relation zueinander setzen. Diese Indexwerte können erweitert werden, um mehrere Werte gleichzeitig miteinander in Beziehung zu setzen. Die Gewichtung mit Fak- toren erlaubt eine individuelle Bewertung: Der Aktienindex sagt etwas über die gesamt- wirtschaftliche Lage. Im DAX fließen die Aktienkurse der 30 größten deutschen Aktiengesellschaften ein, die wiederum unterschiedlich stark gewichtet werden: Am 07.12.16 wurde der Aktienkurs der Deutsche Lufthansa AG mit 0,58 %, der Wert der Sie- mens AG hingegen mit 9,44 % gewichtet. Diese Gewichtung ändert sich von Jahr zu Jahr. Indem man bestimmten Werten eine größere Bedeutung beimisst, kann man das Reporting von Ergebnissen besser an die Realität oder an die Botschaft anpassen, die man beim Reporting übermitteln will. Durch unterschiedliche Gewichtungen kann ein Ergebnis bes- ser oder schlechter, eher beschwichtigend oder dramatischer dargestellt werden. Projektzyklen werden tendenziell kürzer, neue Entwicklungen wegen der Fortschritte der Hardware-Entwicklung (Prozessoren, Speicher) und der dynamischen Prozesse (z. B. in agilen Projekten) immer schneller möglich. Diese Schnelligkeit erzeugt einen hohen Erwartungsdruck auf neue Softwareanwendungen und Erweiterungen bestehender Featu- res. Dieser Termindruck wirkt sich auch auf Testaktivitäten aus. Projekte müssen zu bestimmten Terminen fertig werden, Meilensteine und Budgets sind (leider) dem Quar- talsdenken und teilweise unrealistischen Renditeerwartungen unterworfen. Die Planung ist häufig nicht ausreichend filigran und berücksichtigt bestimmte Parameter und Rahmen- bedingungen nicht hinreichend. So geht vieles an Qualität und Tiefe verloren, die Kosten- vorgaben und Zeitschätzungen sind zu ambitioniert und stehen nachhaltigen, qualitativ hochwertigen Produkten entgegen. Die Globalisierung hat zwar in vielen Fällen das Tempo von Entwicklungszyklen erhöht, das geht aber meist auf Kosten der Produktreife („Bananensoftware reift beim Kunden“). Diese Problematik erkennt man häufig in Ent- wicklungsprojekten, hat aber schließlich nicht genügend handfeste und transparente Argumente, um entsprechend gegenüber dem Management oder dem Controlling zu argumentieren. Ich bemerke immer wieder, dass der Projektaufwand unterschätzt wird, weil zu wenig auf Probleme in den Prozessen und der Organisation geachtet wird. Technisch sind die Probleme meist lösbar, aber die Technik macht eben tendenziell nur 20 % der gesamten Probleme aus, 80 % liegen in der Kommunikation, der Arbeitsorganisation und den Rah- menbedingungen verborgen. Diese Tatsache wird gerade im technologielastigen Umfeld nicht ausreichend gewürdigt. Dazu kommt immer wieder ein Phänomen, das menschli- chen Schätzungen generell innewohnt: Wir unterschätzen die Ziele, die wir in 5 oder 10 Vorwort VII Jahren erreichen können, aber überschätzen, was in 1 oder 2 Jahren erzielt werden kann. Intervalle von 1 oder 2 Jahren Dauer sind aber gerade die typische zeitliche Länge für Projekte in der Softwareerstellung. Aussagen, mit denen man auf mehr Softwarequalität und Risikominimierung hinwirkt, müssen jedoch mit handfesten Daten untermauert werden, um auf Abhängigkeiten und Auswirkungen hinzuweisen. Dazu verhelfen Vergleichswerte und fundierte Zahlen. Je mehr unterschiedliche Indizes erhoben werden, desto genauer wird das Bild, was man über ein Projekt, ein Produkt oder eine Software erhält. Zahlen verhelfen dazu, von einem ungefähren, emotionalen Eindruck zu einer definierten, verlässlichen und belastbaren Messung zu gelangen. Nur mit Zahlen schafft man eine sichere Argumentationsbasis und erhält nachvollziehbare Aussagen. Viele Probleme sind von verschiedenen Einflussgrößen abhängig, die sich gegenseitig beeinflussen. Zahlen, Metriken und Analysen schaffen eine bessere Grundlage, die richtigen Entscheidungen zu treffen und frühzeitig die entschei- denden Weichenstellungen vorzunehmen. Ein Reporting über 20 bis 50 Seiten, wie es bereits für ein mittleres Softwareprojekt erforderlich ist, erschlägt den Empfänger durch seinen Informationsumfang. In einem Pro- ject Review vor einem Project Director oder Manager, das in der Regel einmal pro Woche stattfinden sollte, hat man vielleicht eine Stunde Zeit, um den aktuellen Projektstatus dar- zustellen: Da sollte man mit wenigen Charts auskommen, die man mit wenigen Worten erklären kann. Es wird leider vermehrt dazu übergegangen, aus „Zeitgründen“ die Metri- ken nur online bereitzustellen. Auch das ist ein Trend, bei dem aus vermeintlicher Zeitein- sparung eher wesentliche Informationen verloren gehen. Bei einzelnen Aktivitäten, zum Beispiel im Reporting, bei Review-Maßnahmen oder bei der Erstellung der System Requi- rements, sieht man die Erfolge nicht sofort. Deswegen werden einige notwendige Aktivi- täten aus falsch verstandener Prioritätensetzung weggelassen oder eingespart, was aber das Gesamtprojekt am Ende viel teurer und langwieriger werden lässt. Weiterhin muss man bedenken, dass das Reporting von Projekten nach oben hin immer mehr verdichtet wird. Wenn es in einem Konzern 100 unterschiedliche größere Entwicklungsprojekte gibt, dann will das Topmanagement am Ende nur über diejenigen im Detail informiert werden, bei denen Penalty-Zahlungen oder Abbrüche drohen, also die Projekte bei denen „die Hütte brennt“. In jedem Fall besteht eine besondere Herausforderung darin, die wesentlichen Aussa- gen mit Hilfe von Metriken hervorzuheben und die Konzentration auf das Wesentliche zu lenken. Dazu verhelfen „Projektampeln“ und „Fieberkurven“, weil diese Darstellungen schon aus dem täglichen Leben bekannt sind. Viele Projekte verlaufen zwar sicherlich nicht gerade optimal, aber eben gerade noch so, dass man es mit ein paar Wochen Verzug und wenigen Prozent Kostenüberlauf und einer etwas geringeren Qualität als beabsichtigt oder einer abgespeckten Funktionalität immer noch vermeiden kann, im Fokus des Top- managements zu stehen. Wenn man nämlich erst einmal zu den wenigen Katastrophenpro- jekten gehört, die im Rampenlicht stehen, gewinnt man dauernde Reportings und zusätzliche Panik und wird allein durch die ständige Aktualisierung der Fehlerlisten noch weniger fertig als ohnehin schon. In diesem Fall erlebt man häufig Aktionismus: Viele VIII Vorwort zusätzliche Ressourcen werden in kurzer Zeit ins Projekt gepumpt, Maßnahmen wie Samstagsarbeit und angeordnete Überstunden getroffen, die aber in vielen Fällen nur akut das Schlimmste verhindern und letztlich Kosmetik sind, weil die eigentlichen Probleme in der Regel viel tiefer liegen und kurzfristig gar nicht behoben werden können. Wenn man aber nicht die tiefen Ursachen angeht, erschöpft man sich in der Besänftigung von Symp- tomen. Je eher man daher Projekte auf eine gesunde Grundlage stellt, desto besser sind die Projektziele zu erreichen. Bei der Präsentation, Analyse und Bewertung der Metriken gefällt es dem Management allgemein, wenn linear oder progressiv ansteigende Kurven zu sehen sind. In der Praxis gibt es aber in der Regel viel zu viele Einflussfaktoren, um diese optimalen Kurvenver- läufe permanent präsentieren zu können. Um die richtigen Metriken zu nutzen, die einzel- nen Fakten sinnvoll zu interpretieren und den Fortschritt korrekt zu bewerten, müssen geeignete Parameter in einer anschaulichen Darstellung angegeben werden. In Metriken fließen unterschiedliche Werte ein. Wichtig ist zunächst einmal, möglichst viele Daten konsequent zu erheben. Metriken können auch unterschiedliche Projekte mit- einander vergleichen. Es bringt wenig, die Schuld bei den Projektmitgliedern zu suchen, wenn ein Projekt nicht richtig läuft. Eine Metrik bringt den wirklichen Status klar und neutral hervor. Daher erkennt man auch, dass vielleicht bestimmte Voraussetzungen von Anfang an gar nicht gegeben waren und das Projekt gar keine höhergesteckten Ziele errei- chen konnte. Damit überhaupt Metriken unterschiedlicher Projekte miteinander verglichen werden können, ist es wichtig, innerhalb des Unternehmens gemeinsame Festlegungen zu treffen, sonst vergleicht man Äpfel mit Birnen. Das einzelne Projekt sollte sich daher aus einem unternehmensweit von einer Prozessgruppe definierten Bestand von Metriken diejenigen auswählen, die für das entsprechende Projekt sinnvoll und notwendig sind. Für diese Metriken werden die erforderlichen Daten für die Laufzeit des Projekts regelmäßig erhoben. Gerade diesen Aspekt sehe ich bisher in der betrieblichen Praxis in den w enigsten Fällen erfüllt, meist wird das Rad in jedem Projekt neu erfunden. Der geforderte unterneh- mensweit definierte Bestand von Metriken existiert nämlich in den seltensten Fällen bzw. ist so gut versteckt, dass der Projektmanager und der Testmanager ihn nicht finden und sich dann doch wieder eigene Metriken überlegen. Um in solchen Situationen nicht ganz bei null anfangen zu müssen, sind in diesem Buch einige geeignete Metriken näher beschrieben. In den Projekten werden viele Daten nicht erhoben bzw. nicht archiviert. Und falls in einem Projekt dennoch brauchbare Ergebnisse erhoben wurden, fließen diese Daten selten in die Planung und Kalkulation von Folgeprojekten ein, die gewonnene Datenbasis wird nicht weitergenutzt. Dabei wird wertvolles Potenzial verschenkt. Meist wird beim Folge- projekt ähnlich optimistisch kalkuliert wie beim vergangenen Projekt, das man schon kaum gestemmt hat und das nur mit Terminverzug und Kostenüberschreitung auf den letzten Drücker bei Abstrichen in der Qualität fertig wurde. Die „Lessons Learned Meetings“ beschränken sich oft nur auf 30 Minuten oberflächli- che Betrachtungen, an den Meetings nehmen nur wenige Stakeholder (oder diejenigen, die Vorwort IX mit der operativen Umsetzung am wenigsten betraut waren) teil, oder eine skeptische Rückschau fällt ganz aus. Wenn überhaupt notwendige Aktivitäten für die Zukunft proto- kolliert werden, sind sie beim nächsten Projekt längst vergessen. Besonders zu beachten ist, dass immer nach dem Ziel der einzelnen Metrik gefragt werden sollte und ein gemeinsames Verständnis vorhanden sein sollte, was eine bestimmte Metrik aussagen kann, welche Folgerungen aus ihr gezogen werden können und welche nicht und wo die Grenze der einzelnen Metrik ist. Einzelne Metriken beantworten ganz bestimmte Fragen, und wenn einfach nur Hunderte von Zahlen erhoben werden, also ein Messen ohne Ziel am Ende steht, wenn der Nutzen den Entwicklern und Testern nicht transparent ist, entsteht eine Abwehrhaltung und es wird nur zusätzlicher Aufwand gese- hen. Metriken können immer interpretiert werden und geben unter diesen Bedingungen ein Zerrbild der Realität ab. Die Arbeit in der Produktion wird schon seit Jahrzehnten sehr genau getrackt und mit Hilfe von Metriken untersucht. Inzwischen wird Büroarbeit wie Fließbandarbeit in zahl- reiche Teilschritte zerlegt. Das Tayloring der Prozesse, die verursachergerechte Zuord- nung von Aktivitäten und die zunehmende Überwachung und Kontrolle von einzelnen Arbeitsschritten führt zu einem erhöhten Bedarf an Reporting und das betrifft auch Test- aktivitäten. Demgegenüber entsteht eine Abwehrhaltung und es wird nur zusätzlicher Auf- wand gesehen. Metriken sind dann sinnvoll, wenn alle Beteiligten im Projekt ihren Sinn verstehen und aus den Aussagen zielgerichtet Optimierungen eingeleitet und umgesetzt werden. Im Zeitverlauf von Projekten kann es vorkommen, dass einzelne Fragestellungen sich ändern und unterschiedliche Aussagen im Fokus stehen. Die einzelnen Kapitel dieses Buches beziehen sich auf bestimmte Fragestellungen, die im Zusammenhang mit Testak- tivitäten stehen. Die häufigsten und verbreitetsten Metriken werden dabei genannt. Es kann aber im individuellen Projekt durchaus erforderlich sein, Fragestellungen zu vertie- fen oder Erweiterungen von Metriken vorzunehmen, spezielle Indexwerte zu erheben und Metriken zu erweitern. Daher ist es aus meiner Sicht erforderlich, dem Testmanagement Unterstützung in Analyse und Interpretation erhobener Daten zukommen zu lassen und sehr genau hinzusehen, wo die Probleme im Projekt sind und wie sie in eine sinnvolle Darstellung gebracht werden können, um den Ist-Zustand umfassend und dennoch präg- nant darzustellen und die richtigen Fragen zu stellen, damit die richtigen Maßnahmen eingeleitet und die richtigen Entscheidungen getroffen werden. Richtig eingesetzt, können Metriken sehr effizient zum Projektcontrolling eingesetzt werden, falsch eingesetzt fristen sie schnell ein Schattendasein oder werden als überflüssiger Aufwand abgeschafft. Es ist daher von besonderer Bedeutung, dass das Management Metriken fordert und den Einsatz aktiv beeinflusst. Metriken sollen Eigenschaften von Funktionen auf Zahlenwerte abbilden. Sie sollen möglichst objektiv Informationen verdichten, Komplexität reduzieren, adressatengerecht aufbereitet sein und schnell und frühzeitig Probleme erkennen lassen und diese Erkennt- nisse transparent darstellen. Im Auto werden auf dem Armaturenbrett wesentliche Infor- mationen (Geschwindigkeit, Drehzahl, Uhrzeit, Warnhinweise) dem Fahrer dargestellt.