10 Schritte zu einem guten Start ins nächste Testprojekt (Teil 6)

von Maud Schlich

Ein neues (Test-)Projekt für Sie? In zehn Schritten legen Sie die Basis für einen guten Start und damit auch ein erfolgreiches Ende - ganz egal, ob Sie in einem agilen Umfeld unterwegs sind oder das V-Modell als Leitlinie haben. Der erste Entwurf des Testkonzeptes steht, aber es fehlen noch Details, die den Fortschritt des Testens und die Qualität der getesteten Systeme sichtbar machen: die Metriken.


Fortschritt des Testens

Was antworten Sie auf die Frage "Wie weit sind Sie mit dem Testen?" oder "Werden Sie rechtzeitig mit dem Test fertig?" und - noch wichtiger - können Sie Ihre Antwort begründen?

Und die Frage "Können wir releasen?" - können Sie Ihre Antwort dazu mit Argumenten belegen?


Schätzen, Abschätzen, Messen

Das Schätzen und das Messen sind im agilen Kontext oft umstritten, nur allzu gerne arbeiten manche Teams einfach darauf los. Das gilt für die Entwicklungsseite genauso wie für die Testteams. Gute Teams nutzen die Retrospektiven, um Ihre zuvor abgegebenen Commitments zum tatsächlich Erreichten zu prüfen und anschließend bessere Vorhersagen treffen zu können. In der klassischen Entwicklung ist es mit dieser kritischen Hinterfragung deutlich schlechter bestellt. Eine Retrospektive wird selten und dann oft auch nur über wenige Stunden durchgeführt. Das Ergebnis ist nahezu immer das Gleiche: es mangelt an der Kommunikation, am Commitment des Managements, an den Ressourcen und an der rechtzeitigen Erledigung von Arbeitsaufträgen, ganzen Arbeitspaketen und Meilensteinen oder die Termine werden nur durch reduzierte Umfänge erreicht. Gelernt wird selten daraus - oft genug sind es nicht einmal die genau gleichen Teams, die die nächsten Projekte durchführen. Die zeitliche Dauer und der Umfang der Projekte sind so groß, dass das der häufig schlechte Start erst Monate später in der Retrospektive als einer der verbesserungswürdigen Dinge zur Sprache kommt, Korrekturen bzw. Korrekturversuche im Laufe des Projektes sind oft genug nur Sache des Projektmanagements aber nicht des gesamten Teams.

Eine Mitschuld haben für mich dabei Metriken, die bei Projektbeantragung von der Organisation gefordert werden und in Lenkungsausschüssen zum Controlling benutzt werden.  Manche sind sicher hilfreich für genau diesen Zweck, aber nicht geeignet für das Controlling des Testens und der Qualität der Arbeitsergebnisse des Projektes. Ein Grund dafür sind Standard-Metriken statt projektspezifischer Metriken, ein anderer die Definition der Metriken "von oben" zur Kontrolle statt "vom Team" zur Selbstkontrolle.


Es gibt ein berechtigtes Interesse von Auftraggebern an messbaren Ergebnissen - kein Zweifel. Wer für etwas zahlt, möchte möglichst frühzeitig und möglichst oft bestätigt bekommen, dass das Geld nicht aus dem Fenster geworfen wird.

Das Problem ist natürlich, dass das Team so gut wie möglich dastehen möchte. Schon vor etlichen Jahren hat Gerald Weinberg1 in einem Experiment dargestellt, dass Softwareentwickler immer genau die Metriken optimal erfüllen, die sie als Ziele vorgegeben bekommen. Das typische Beispiel hierfür ist die Messung von gefundenen Fehler je Tester. Ist die Maxime hier, dass diese Zahl möglichst hoch sein soll, dann werden Tester jegliche Befunde möglichst einzeln dokumentieren statt diese sinnvoll zusammenzufassen und nur einmal (mit der entsprechenden Anmerkung zum wiederholten Auftreten) zu berichten. Und es werden mehr Fehler mit höherem Schweregrad berichtet, einfach da die Vielzahl "kleiner" Fehler dazu führt, dass eine erhöhte Anzahl (aus Zeitgründen) nicht mehr korrigiert werden. Eine Teufelsspirale, bei der am Ende bei einem meiner Kunden sogar ein Schweregrad oberhalb von Showstopper eingeführt wurde: "Absolute Showstopper".

 

Dabei gibt es eine Reihe von Metriken, die ich bereits 2006 im Vortrag Maßvolles Messen bei der Prozessverbesserung nach Reifegradmodellen vorgestellt und seither wiederholt optimiert habe.

Es gibt Standard-Metriken, was "man" so misst und es gibt für mich einige grundlegende Metriken, was Sie aus meiner Sicht typischerweise in jedem Testprojekt messen sollten. Außerdem gibt es noch eine große Bandbreite von Metriken, die  situationsabhängig sind und entsprechend GQM2 eingeführt werden sollten und in aller Regeln nicht (!) dauerhaft erhoben werden.

Standard-Metriken

Standard-Metriken sind für mich die Metriken, die "alle" im Testmanagement nutzen oder nutzen müssen, weil es Vorgesetzte oder Kunden so wollen. Nachfolgend liste ich exemplarisch ein paar auf und beschreibe, warum diese mindestens frag-würdig sind.

  • Anzahl Fehler je Priorität
    Klar, Fehler sind das A&O dessen, was Tests finden sollen. Das häufig zu beobachtende Problem dabei ist die Definition der Priorität. Allzu oft wird diese eher als "Dringlichkeit der Korrektur" denn als "Schwere des Fehlers" interpretiert. Besser ist es genau zu hinterfragen, für wen diese Priorität angegeben wird, wie sie daher defniert werden muss und ob es nicht besser zwei Kategorien gibt: Priorität = "Schnelligkeit mit der das bearbeitet werden muss" und Kritikalität/Schwere = "Auswirkungen auf die Nutzbarkeit des Systems".
  • Abdeckung der Anforderungen
    Dass es zu allen Anforderungen auch Testfälle geben sollte, steht außer Frage. Kritisch wird es mit dem Umkehrschluss. Warum darf es in vielen Unternehmen (gerade auch im Bereich Automotive oft erlebt) keine Testfälle geben, zu denen es keine zugehörige Anforderung gibt? Hier greift die Forderung nach der bidirektionalen Traceability (als der Vorwärts- und Rückwärtsverfolgbarkeit von Anforderungen über Design, Code zum Test und zurück) zu kurz. Diese Forderung führt meiner Erfahrung nach nicht dazu, dass nun zum Testfall eine Anforderung nachdokumentiert wird, sondern dazu, dass der Testfall nicht ausgeführt und häufig nicht einmal dokumentiert werden darf.
  • Anzahl geplanter vs. erstellter vs. durchgeführter Testfälle
    Bei THE QUALITEERS werden wir von unseren Kunden oft vor die Aufgabe gestellt, die Anzahl von Testfällen abzuschätzen, meist um den Aufwand des Testprojektes abzuschätzen und die Teamgröße zu rechtfertigen. Das geht durchaus,wenn
    • man eine klare Vorstellung von der Größe eines einzelnen Testfalls je Testmethode hat und diese unterschiedlich behandelt werden (Aufwand zur Erstellung und zur Durchführung sind zum Teil extrem unterschiedlich),
    • die tatsächlichen Zeiten für die Erstellung (aus vorangegangenen und genügend ähnlichen Projekten) vorhanden sind,
    • Rüstzeiten und Vorbereitungsaufwand zur Durchführung und/oder Automatisierungsaufwand bekannt und dokumentiert sind,
    • ein Auf und Ab der Kurve im zeitlichen Verlauf legitim ist (Testfälle werden verworfen, zusammengeführt, vereinzelt, neue kommen spontan hinzu),
    • eine Vereinbarung zwischen allen Stakeholdern darüber besteht, das hiermit keine Leistung der Testteammitglieder gemessen werden können(!)

 

 


Grundlegende Metriken

In den Projekten, in denen unsere Coachees das Testmanagement inne haben oder wo wir das als Interims übernehmen, führen wir nach Möglichkeit und natürlich nur, wenn sinnvoll einige Metriken ein, mit denen wir das Testprojekt optimal steuern können. 

Beispiele für Grundlegende Metriken sind Teststatus und Verteilung Fehlerarten je Testansatz.

Teststatus

Diese Metrik dient dazu eine zusammenfassende Aussage zur Softwarequalität und zum Stand der Durchführung von Tests zu erhalten und berichten zu können. Sie ist dem Buch Successful Test Management von Pinkster et.al. entlehnt und wird von uns schon seit mehr als 15 Jahren in Projekten erfolgreich genutzt.

Für jeden Testfall wird ein Status vergeben:

  • PWF (Pass was Failed / Positiv war Fehlerhaft)
    • Testfälle, die beim vorhergehenden Test negativ und im darauffolgenden Test positiv getestet wurden, d.h. der Retest war erfolgreich.
  • FWP (Failed was Passed / Fehlerhaft war Positiv)
    • Testfälle, die beim vorhergehenden Test positiv und im darauffolgenden Test negativ getestet wurde, d.h. der Regressionstest war nicht erfolgreich.
  • FNP (Failed never Passed / Fehlerhaft niemals Positiv)
    • Testfälle, die bisher noch nicht getestet waren und nun negativ getestet wurden
    • Testfälle, die beim vorhergehenden Test negativ getestet wurden und auch im darauffolgenden Test wiederum negativ getestet wurden, d.h. der Retest war nicht erfolgreich (der Fehler ist weiterhin enthalten oder es ist ein weiterer Fehler aufgetreten).
  • PNF (Passed never Failed / Positiv niemals Fehlerhaft)
    • Testfälle, die bisher noch nicht getestet waren und nun positiv getestet wurden.
    • Testfälle, die beim vorhergehenden Test positiv getestet wurden und auch im darauffolgenden Test wiederum positiv getestet wurden, d.h. der Regressionstest war erfolgreich.
  • S   (Selected / Selektiert)
    • Testfälle, die im aktuellen Testzyklus zum Test ausgewählt wurden, deren Test aber zum aktuellen Zeitpunkt noch nicht erfolgt ist.
  • NS  (Not Selected / Nicht Selektiert)
    • Testfälle, die im aktuellen Testzyklus nicht zum Test ausgewählt wurden.
  • NA  (Not Applicable / Nicht Anwendbar)
    • Testfälle, für die noch keine Entscheidung zu Ihrer Durchführung getroffen wurden, z.B. weil die Testfälle noch nicht abschließend erstellt oder gereviewt wurden oder weil noch unklar ist, ob diese im aktuellen Testzyklus ausgeführt werden sollen.

Dieser Status wird in einem Balkendiagramm aufgetragen mit einem Balken je Berichtszeitpunkt / Testzyklus (x-Achse) und Darstellung der absoluten Zahlen (y-Achse).

Diese Metrik ist ernorm aussagekräftig und bietet einem Testmanager sehr gute Möglichkeiten zusammen mit der Entwicklungsleitung den Test und das gesamte Projekt zu optimieren. Wenn zum Beispiel der Trend eine Steigerung der  FWP zeigt, dann könnte eine mögliche Ursache ein unzureichendes Konfigurationsmanagement oder erodierende Software sein.

 

Fehlerarten je Testansatz

Metrik_Testfallklassen_Fehlerart

Um diese Metrik zu erheben, benötigt man ein Entwicklungsteam, das bereit ist, die analysierten Fehler in Fehlerarten zu kategorisieren. Damit das gelingt und korrekte Daten erarbeitet werden, müssen alle Beteiligten frühzeitig beteiligt werden und die Anonymisierung von Daten gegeben sein, um jegliche Leistungsbeurteilungen auszuschließen.

Welche Kategorien von Fehlerarten bestimmt werden, hängt davon ab, wie genau und wie einfach die Fehlerursache analysiert werden kann und welche Hilfsmittel das (vor allem im Fehler- und Abweichungsmanagementsystem) unterstützen. Komplexe und stark verzweigte Taxonomien bewirken (rein theoretisch) sehr gute Ergebnisse, führen aber häufig zu einer schnellen Vernachlässigung und schlampiger Nutzung weil sie zu aufwändig sind.

Besser sind einfache Kategorien, die Sachverhalte korrekt widerspiegeln, zum Beispiel:

  • Fehlerhafte Eingabe wird akzeptiert
  • Korrekte Eingabe wird nicht akzeptiert
  • Layout / Optik fehlerhaft
  • System verlangt nicht aufgabenangemessene Abarbeitung (ISO 9241)
  • Ausgabe ist unvollständig / fehlerhaft
  • Anforderung wurde nicht (korrekt) umgesetzt
  • Daten werden falsch berechnet
  • System erzeugt Fehlermeldung
  • System stoppt / Programm hängt sich auf
  • Performanz ist ungenügend
  • Duplikat
  • Verbesserungsvorschlag
  • Change Request
  • Sonstiges

Diese Liste ist weder eindeutig orthogonal noch vollständig - sie soll Ihnen lediglich als ersten Ansatz dienen. Wichtig ist, dass die von Ihnen benutzten Testansätze möglichst eindeutig diesen Fehlerarten zugeordnet werden können. Dann können Sie Aussagen treffen, ob Sie Fehler eher explorativ oder gar zufällig aufdecken oder tatsächlich mit der beabsichtigten Testtechnik. Planen Sie z.B. Äquivalenzklassenbasisierte Tests und erkennen bei der Durchführung, dass Sie mit diesen Tests wenige Probleme mit den Kategorien "Korrekte Eingabe wird nicht akzeptiert" / "Fehlerhafte Eingabe wird akzeptiert" aufdecken, sollten Sie die Zeit für diese Tests besser auf andere Testansätze verwenden.


Was immer Sie nun als Metriken bestimmt haben, gehört nun in das Testkonzept. Optimalerweise nur als Referenz auf ein übergeordnetes Dokument, dass diese Metrik ausführlich beschreibt inklusive Interpretationshilfen und einer Erläuterung, was in diesem Testprojekt eventuell abweichend davon gehandhabt wird.

Ein Template für eine optimale Definition von Metriken können Sie gerne bei uns anfordern.

 


Und im agilen Kontext?

Wer meint Metriken gehören nur in den klassischen Kontext hat den Sinn von Burndown-Grafiken und Bestimmung der Velocity nicht verstanden. Allerdings sind Burndown-Grafiken im Testprojekt nicht so einfach. Wir haben bereits in mehreren Projekten mit einer abzuarbeitenden Zahl an User Stories und/oder zu erstellenden / durchzuführenden Testfällen gearbeitet und dabei sehr unterschiedliche Ergebnisse gehabt. Im gleichen Unternehmen z.B. konnten wir einmal bis auf -0,25% die Anzahl zu erstellender Testfälle vorhersagen und in einem anderen Projekt lagen wir um 40% zu hoch. Die Formulierung / Größe der Testfälle war dabei durchaus vergleichbar. Woran lag es? Das erste Projekt war eine Erweiterung bekannter Systeme, das zweite Projekt war etwas Neues, dass ein altes System ablösen sollte. Weitere Ursachen spielten ebenfalls mit (Teamgröße, Teamzusammensetzung, und einiges mehr). Dennoch will der Kunde auch in Zukunft die geplanten vs. durchgeführten vs. PNF+PWF Testfälle als Burndownchart nutzen.

Letztlich helfen Metriken bei der Bestimmung des Status quo und damit bei der Erreichung der Ziele. Wer ganz darauf verzichtet, verzichtet auf jegliche Möglichkeit, Trends zu erkennen und dagegen zu steuern, wenn nötig.



Wenn Sie den Erfolg Ihres Testprojekts nicht dem Zufall überlassen, sondern mit Zahlen, Daten und Fakten planen und steuern wollen: vertiefen Sie ihr Wissen im Workshop "Metriken: Unverzichtbare Werkzeuge für Testmanager". Jetzt gleich ansehen und für Leser dieses Blogs gibt es zusätzlich ohne Aufpreis einen Online-Workshop zur Vor- und Nachbereitung, in dem Sie die Metriken Ihres Projektes mit Ihrem persönlichen Coach bearbeiten können.


You can't control what you can't measure

Tom De Marco, Controlling Software Projects, Management Measurement & Estimation, (1982), p. 3.


 

1Leider weiß ich den Titel des Buches nicht mehr. Sollte ich mal wieder in Kaiserslautern am Fraunhofer IESE sein, werde ich versuchen, das in der dortigen Bibliothek nachzuschlagen. Dort finde ich es bestimmt noch und trage es dann hier nach.

2GQM steht für Goal-Question-Metric und beruht auf dem Quality Improvement Paradigm (QIP). Es geht dabei darum Messziele von Geschäftszielen abzuleiten, sauber zu definieren, davon wiederum Fragen an den zu messenden Prozess oder Sachverhalt abzuleiten und daraus dann wiederum die Metriken zu bestimmen, die die Antworten liefern können und damit zur Zielerreichung beitragen. Einen kurzen Überblick hierzu finden Sie im schon erwähnten Vortrag Maßvolles Messen bei der Prozessverbesserung nach Reifegradmodellen .


Whitepaper-Banner flach

Zurück

Einen Kommentar schreiben