«Könnte mir jemand zeigen, wie sich die Softwarequalität in den letzten sechs Monaten entwickelt hat?»
«Wieso möchtest du das wissen?»
«Ich möchte als Testmanager gerne wissen, ob wir uns stetig verbessern oder ob die Qualität, gemessen an z.B. Severity und Anzahl Defects, gleichgeblieben ist. Auch möchte ich sehen, wie sich die Testqualität entwickelt hat?»
«Nein, die Daten haben wir leider nicht! Um ehrlich zu sein, wir haben keine fest definierten Metriken.»
«Anhand welcher Kriterien entscheidet ihr euch dann, einen Go-Life durchzuführen?»
«Hmm …»
Wichtige Fragen
Bevor man anfängt Daten zu sammeln, Erfassungsregeln aufzustellen oder Metriken zu konfigurieren und auszuwerten, ist es wichtig, sich zuerst über Ziel und Erfassungsaufwand Klarheit zu verschaffen. Also über «Value» und «Waste».
- Welche Ziele möchte man mit Metriken erreichen?
- Welche Metriken tragen dazu bei, diese Ziele zu erreichen?
- Welche Daten müssen hierzu erfasst werden?
- Sind Erfassungs- und Konfigurationsaufwand akzeptabel?
- Beurteilt nach «Value» und «Waste»: braucht man tatsächlich alle definierten Metriken?
Vor allem die Frage 5 ist sehr wichtig. Einen Schritt zurück machen und objektiv beurteilen, ob man auch tatsächliche die definierten Metriken braucht.
Welche Tools?
Bei vielen Tools ist es schwierig, bestimmte Metriken zu erzeugen. Einfache Metriken stellen kein Problem dar. Sobald man aber eine Entwicklung über mehrere Monate sichtbar machen möchte, ist dies problematischer.
Deswegen greife ich meistens zurück auf das zu Unrecht unterschätzte MS Excel, das ich sehr oft neben den üblich verwendeten Tools einsetze. Damit habe ich bis jetzt alles erstellen können, was das Testmanagerherz begehrt. Der dafür benötigte extra Aufwand war minimal, vernachlässigbar und beinhaltete somit keine «Waste» Elemente. Grundsätzlich ist es aber auch möglich, das komplette Testmanagement in MS Excel zu machen. (Dafür habe ich in Excel ein kleines TM Tool entwickelt. Bei Interesse bin ich gerne bereit, Auskünfte zu geben. Hinterlassen Sie doch unten im Artikel eine Nachricht, ich werde mich umgehend melden.)
«Value» Elemente
Sobald ein Testmanagement-Tool eingesetzt wird, steht eine sehr grosse Menge an Daten zur Verfügung. Dadurch entsteht die Möglichkeit, viele verschiedenartige Auswertungen zu machen und alles Mögliche in Tabellen, Grafiken oder Diagrammen abzubilden.
«Value» Elemente von Metriken für das Testmanagement:
- Das aktuelle Testing und den Testfortschritt beurteilen
- Eine Aussage bezüglich der momentanen Test- und Produktqualität treffen
- Die Test- und Produktqualität steuern
- Eine valide Entscheidung bezüglich Go-Life treffen
Es ergibt aber wenig Sinn, alle möglichen Metriken auch zu erstellen. Man sollte sich bewusst sein, dass Metriken nicht nur einen «Value», sondern auch einen «Waste» bedeuten können.
«Waste» Elemente
Unabhängig vom verwendeten Tool, sollte man folgende «Waste» Elemente vermeiden:
- Zusätzlichen Erfassungs- und Organisationssaufwand
- Um eine Metrik zu erzeugen, müssen die dafür benötigten Daten eingegeben werden. Je mehr Daten erfasst werden müssen, desto länger, komplexer und aufwändiger wird die Erfassung
- Bei eingeschränkten Konfigurationsmöglichkeiten müssen klare Erfassungsregeln aufgestellt werden, deren Einhaltung regelmässig kontrolliert werden muss
- Erstellen von Metriken, die
- schlecht interpretierbar / lesbar sind
- keine validen Entscheidungen erlauben
- keine Fragen beantworten
- zu spät zur Verfügung stehen
- ein schlechtes Verhältnis zwischen Erstellungsaufwand und Nutzen haben
- Zur Verfügung stellen vieler Metriken, mit der Gefahr
- auf widersprüchliche Aussagen
- dass Metriken erstellt werden, die keine wirkliche Aussagekraft haben
- dass Metriken missbraucht werden
- dass Metriken nur erstellt werden, weil es möglich ist diese zu erstellen
Brauche ich 20 Metriken?
Das Verhältnis zwischen Anzahl Metriken und dem Nutzen ist asymptotisch: eine zusätzliche Metrik erzeugt weniger zusätzlichen Nutzen.
Auch die Erfahrung lehrt: weniger ist mehr. Es müssen nicht viele Metriken erstellt werden. Auch sollte die Komplexität der Metriken nicht zu hoch sein. Das Ziel einer Metrik liegt in erster Linie darin, eine Zahlenmenge grafisch übersichtlich und verständlich darzustellen, um so auf einen Blick deren Aussage zu erfassen.
Nachfolgend werde ich die wichtigsten Metriken auflisten, die viele «Value» Elemente beinhalten. Mit diesen Metriken ist man in der Lage, die meisten testmanagementrelevanten Aussagen zu treffen.
Metrik Testabdeckung
Um die Testabdeckung zu beurteilen, muss es möglich sein, Requirements (Anforderungen) oder User Stories mit den dazugehörigen Testfällen zu verknüpfen. Diese Metrik ist sehr wichtig, um die Testqualität beurteilen zu können.
Sind alle Requirements oder User Stories mit einem Testfall abgedeckt, hätte man eine einfache Testabdeckung von 100%. Dies bedeutet aber noch nicht, dass die tatsächliche Testqualität auch hoch ist. Wenn man z.B. die falschen Testfälle entwickelt hat, nützt auch eine einfache Testabdeckung von 100% nichts.
Die mehrfache Testabdeckung ist in dieser Hinsicht ein besseres Kriterium: Bei einer Testabdeckung von 100%, sollte die durchschnittliche Anzahl von Testfällen pro Anforderung >= 2 angestrebt werden, wobei 2 das absolute Minimum ist.
Um bezüglich der Testqualität ganz sicher zu sein, kommt man aber nicht darum herum, einzelne Testfälle z.B. in Abhängigkeit der Priorisierung genauer zu reviewen.
Metrik Testausführung
Diese Metrik zeigt nur eine Momentaufnahme: Wie ist die momentane Situation hinsichtlich Ausführung der Testfälle. Hier genügt es, eine Übersicht über den Status der Testfälle zu haben.
Metrik Defects
Auch diese Metriken zeigen nur eine Momentaufnahme: Wie ist die momentane Situation hinsichtlich der Qualität? Hier ist es ausreichend, Metriken zu erzeugen, die einerseits den Status aller Defects und anderseits die «Severity» von allen Open Defects zeigen. «Open Defects» werden definiert als: Alle Defects die noch weiterbearbeitet werden (z.B. den Status «New», «Open», «Assigned» oder «In Progress» haben).
Unterstehende Grafik zeigt nicht nur den aktuellen Status der Defects, sondern auch, im Verhältnis, den Aufwand, den die gefundenen Defects generieren:
- Den Aufwand, den die Entwickler noch haben, um die gefundenen Defects zu korrigieren
- Der Aufwand, den die Tester noch für die notwendigen Regressionstests haben
Unterstehende Grafik zeigt die Qualität des Produktes: Unter der Annahme, dass gut getestet wird, würde eine relativ tiefe Anzahl «Critical» oder «High» Defects bedeuten, dass die Produktqualität gut ist.
Metrik Defect Entwicklung
Die bisher erwähnten Metriken zeigen nur eine Momentaufnahme. Dies ist aber zu wenig, um über einen längeren Zeitraum ein Gefühl für die Entwicklung der Produkt- oder Softwarequalität zu bekommen.
Um diese Entwicklung der Defects grafisch darzustellen, muss man die einzelnen Momentaufnahmen hintereinander setzen.
Defectentwicklung nach Status:
Je flacher die schwarze Kurve wird, desto besser wird die Produktqualität. Natürlich unter der Annahme, dass die Testqualität gleichbleibend gut ist.
Entwicklung der Defects im Status «Open» oder «In Progress», nach Severity sortiert:
Je geringer die Schwankungen der einzelnen Kurven sind und die Tendenz Richtung 0 geht, desto besser wird die Produktqualität. Auch hier natürlich nur unter der Annahme, dass die Testqualität gleichbleibend gut ist.
Metrik Testfortschritt
Um eine Übersicht zu bekommen, wie weit man mit der Testausführung ist (ist man «on track»?), kann man ein einfaches Burn-Down-Chart verwenden. Hierzu muss man die Anzahl auszuführender Testfälle und die dafür zur Verfügung stehende Zeit ermitteln.
Anhand dieser Metrik ist es einfach zu erkennen, wann man eingreifen sollte, um die Testausführung zu steuern. Sobald die grüne Linie oberhalb der blauen Linie liegt, und das geplante Ende der Testperiode in Gefahr zu kommen droht, sollte man korrigierend eingreifen, z.B. mehr Tester anstellen oder die Testintensität erhöhen.
Fazit
Um ein effizientes Testmanagement und eine kontinuierliche Sicht auf die Produktqualität gewährleisten zu können, braucht es nicht viele Metriken. Grundsätzlich sind sieben Metriken mehr als ausreichend. Die Daten, die dafür gesammelt bzw. erfasst werden müssen, sind Standarddaten.
Wichtig ist, sich immer wieder die Frage zu stellen, welche Metriken man als Testmanager wirklich braucht. Das bedeutet, sich den Lean Gedanken zu verinnerlichen und sich immer wieder die Frage nach dem «Value» und «Waste» zu stellen und danach zu handeln.
