Testmanagement

Die EOT-Prognose („End of Testing“)

Als Software-Testmanager sind Sie jenes Mitglied eines Projektteams, das sehr oft Rede und Antwort stehen muss rund um die Softwarequalität. Fragen zum aktuellen Status und zu auftretenden Fehlern, aber auch Fragen die Zukunft betreffend – können wir den Einsatztermin halten? Dieser Artikel soll anhand eines realen Projekts Anregungen dazu liefern, wie Sie mithilfe einer Hochrechnung, in Kombination mit einer Monte Carlo Simulation, solche Fragen fundiert beantworten und eine realistische Prognose abgeben können. Dieser Artikel ist gekürzt im SQ Magazin, Ausgabe 41/2016, erschienen – zum PDF.

Softwarequalität_EOT Prognose_EndOfTesting

Als Software-Testmanager sind Sie jenes Mitglied eines Projektteams, das am besten darüber Bescheid weiß, wie es in den jeweiligen Phasen eines Projekts um die Qualität der Software bestellt ist. Es ist also naheliegend, an Sie gewisse Fragen zu stellen.

  • Wie viele Fehler haben wir aktuell im Projekt?
  • Wie viele davon sind kritisch oder schwer?

Dies sind Fragen wie sie tagtäglich (oder mindestens in jeder Projekt-Abstimmung) vorkommen, und sie sind leicht zu beantworten. Egal welches Tool Sie im Software-Test einsetzen, es liefert Ihnen dazu die notwendigen Zahlen.

Andere Fragen sind nicht ganz so leicht zu beantworten. Es sind diese Fragen, die sich mit der Zukunft beschäftigen, zum Beispiel:

  • Können wir den geplanten Einsatztermin aus Sicht des Testteams halten?

Mit dieser Frage ist nichts anderes gemeint als:

  • Wie lange werden wir noch brauchen, bis die vorhandenen Fehler beseitigt sind?
  • Wann können wir guten Gewissens davon ausgehen, dass die Softwarequalität stimmt?
  • Das Entwicklungsteam behauptet, eigentlich „nur die noch vorhandenen Fehler beheben zu müssen“ – was hindert uns am Einsatz zum geplanten Termin?

 

Überlegungen zur Lösung dieser Frage(n)

Screenshot_Fehlertrend-Kurve

Abb. 1 Screenshot „Fehlertrend-Kurve“

Wie ist diese Fehlertrend-Kurve zu lesen?

  • Der grüne Balken zeigt die Anzahl der geschlossenen Fehler pro Zeiteinheit.
  • Der rote Balken zeigt die Arbeitslast (siehe unten) der Entwicklung.
  • Der gelbe Balken zeigt die Arbeitslast des Testteams.
  • Die blaue Linie zeigt die Anzahl der jeweils neu hinzukommenden Fehler (siehe unten)
  • Die Annahme ist: Im Laufe der Zeit sollte der grüne Balken immer größer werden, den roten Balken verdrängen und schlussendlich bei null landen. Wenn dies erreicht ist, wurden alle gefundenen Fehler behoben – der Test kann als abgeschlossen betrachtet werden.

 

Lösungsansatz

Wenn man ermitteln kann, wie lange der aktuelle Trend noch anhalten wird (roter Pfeil) und ab wann die Anzahl offener Fehler gegen Null geht (grüner Pfeil), dann hat man eine auf Basis der gesamten Projekthistorie ermittelte Prognose zu einem wahrscheinlichen Testende.

Dieser Artikel soll anhand eines realen Projekts Anregungen dazu liefern, wie Sie mithilfe einer Hochrechnung solche Fragen fundiert beantworten können – und „fundiert“ ist auch schon ein Stichwort, auf das näher einzugehen ist. Es gilt nämlich ganz klar, Antworten auf Basis des eigenen „Bauchgefühls“ zu vermeiden. Auch viele Jahre Erfahrung im Software-Test werden Sie nicht davor bewahren, falsche Prognosen abzugeben. Ganz abgesehen davon sind solche Bauchgefühl-Aussagen leicht angreifbar weil sie durch nichts gestützt werden, d.h. es fehlt Ihnen die geeignete Basis zur Begründung Ihrer Prognosen.

 

Die Basis für Ihre Prognose

Sie benötigen als Basis Ihrer Aussagen zunächst das geeignete Zahlenmaterial. Für die in diesem Artikel vorgestellte Methode erzeugt man sich eine mit jedem gängigen Werkzeug des Software-Tests schnell ermittelbare Fehlerstatistik, sprich: eine Auswertung, die für jeden Tag innerhalb des Testzeitraums die Anzahl der Fehler im Status „Offen“, „Geschlossen“, „Neu“, etc. ausgibt.

Welche Spalten müssen auf jeden Fall enthalten sein? Dafür ist zu überlegen, welche Werte Auskunft über die Teamperformance geben, damit ist sowohl das Testteam als auch das Entwicklerteam gemeint:

  • Welche Werte zeigen die pro Tag bei der Entwicklung liegende Arbeitslast?
  • Welche Werte zeigen die pro Tag geschlossenen Fehler?
  • Welche Werte zeigen die pro Tag neu hinzukommenden Fehler?

Der folgende Screenshot „Fehlerstatistik“ entstammt einer Auswertung im Rahmen des schon erwähnten realen Projekts. Dieses erstreckte sich über insgesamt 13 Monate, lieferte also eine absolut ausreichende Menge an Daten für die Prognosen.

Abb. 2 Fehlerstatistik

Abb. 2 Screenshot „Fehlerstatistik“ – Auszug

Zur ersten Frage: Die im obigen Bild blau markierten Spalten („New“, „Open“ und „Reopen“) geben Auskunft darüber, wie viele Fehler von der Entwicklung an den jeweiligen Tagen zu bearbeiten waren, also ihre „Arbeitslast“.

Zur zweiten Frage: Die Spalte „Closed“ gibt an, wie viele Fehler an den jeweiligen Tagen geschlossen waren, also ergibt zum Beispiel die Differenz zum Vortag den gesuchten Wert (wenn man nur 1 Tag betrachten würde).

Zur dritten Frage: Die pro Tag neu hinzukommenden Fehler finden sich implizit in der Spalte „<Total>“, d.h. sie entsprechen ebenfalls wieder jeweils der Differenz zum Vortag.

Auf diesen Werten aufbauend können Metriken zur Performance des Teams ermittelt werden (eine von mir sogenannte „Aufdeckungsrate“ und eine „Behebungsrate“) – diese sind die wesentlichen Bestandteile der eigentlichen Hochrechnung.

Tabelle 1

Bevor man mit der Hochrechnung nun beginnt, sollte man sich eine abschließende Frage stellen bzw. eine Annahme treffen: Wie lange noch wird seitens des Entwicklungsteams neue Funktionalität implementiert werden (und somit das Testteam vorbereitete Testfälle durchführen)? Der Hintergrund dieser Frage ist die Annahme, dass – wenn weitere x Tage implementiert wird – weiterhin an diesen x Tagen Fehler gefunden werden.

Es kann natürlich sein, dass seitens Entwicklung keinerlei neue Funktionalität mehr ausgeliefert werden wird (entweder man hat schon alles abgeschlossen, oder es werden Neuentwicklungen erst in einer späteren Projekt-Phase vorgenommen). In diesem Fall steht „x Tage“ für jene Anzahl an Tagen, die das Testteam benötigen wird, um sämtliche noch ausstehenden Testfälle abarbeiten zu können.

Der letzte Fall liegt vor, wenn keine Neuentwicklung und auch keine vorbereiteten Testdurchführungen mehr anstehen – es sich also nur noch um Fehlernachtests („Retests“) handelt. In dieser einen Situation wäre für x der Wert Null anzunehmen.

Es ist in all diesen Fällen nicht davon auszugehen, dass sich „ab nun“ die Aufdeckungsrate wesentlich ändert.

 

Die Hochrechnung

Nachdem die Umsetzung all dieser Überlegungen (beispielsweise im Excel) relativ trivial ist, beschränkt sich dieser Artikel auf die Darstellung der zugrunde liegenden Formel:

Formel

Tabelle 2

Nachdem es sich um eine Prognose bzw. Hochrechnung auf Basis von Durchschnitts-Werten handelt, ist zu empfehlen, nicht nur einen Zeitraum zu betrachten, sondern gleich mehrere – in der Praxis haben sich drei Zeiträume bewährt:

  • der gesamte Zeitraum des Projekts
  • die letzten 10 Wochen
  • die letzten 5 Wochen

Es kann somit vom Testmanager einerseits erkannt werden, ob sich die Performance-Werte in den Zeiträumen ändern bzw. ob sie sich „in die richtige Richtung“ verändern – und andererseits bekommt man die Möglichkeit, mithilfe der Zeiträume zu interpretieren und so seine Prognosen zu verfeinern. Doch für welchen Zeitpunkt entscheidet man sich nun? Um diese Frage letztlich zu beantworten, wird zusätzlich eine Monte Carlo Simulation durchgeführt.

 

Die Monte-Carlo-Simulation

Es können bestimmte komplexe Prozesse simuliert werden, die sonst nicht direkt analysiert werden können. Sie kennzeichnet nicht „einen bestimmten Algorithmus“, sondern umfasst vielmehr eine Gruppe von numerischen Methoden zur Ermittlung einer sehr großen Anzahl von Zufallszahlen – mittels derer die Realität möglichst gut simuliert wird. In meiner Methode werden 20.000 Datums-Berechnungen durchgeführt. Jeder dieser drei Zeiträume hat eine für sich typische Aufdeckungs- bzw. Behebungsrate. Mithilfe der Normalverteilungs-Funktion wird nun daraus für jede dieser vielen Berechnungen ein Input-Wert generiert und 20.000 Testende-Zeitpunkte errechnet. Der am häufigsten vorkommende Datumswert, wird als Ergebnis der Simulation ausgegeben. Im optimalen Fall bestätigt der simulierte Wert einen der drei bereits berechneten Datumswerte – oder weist in die richtige Richtung.

montecarlosimulation1

 

Die Praxis

Es ist empfehlenswert, diese Art der Hochrechnung regelmäßig durchzuführen, beispielsweise alle 2 Wochen. Zu diesem Zweck macht es Sinn, ein Programm zu entwickeln – in meinem Fall wurde daraus das „EOT-Tool“. Am Beispiel des Datenstands vom September 2014 (siehe [Screenshot „Fehlertrend-Kurve“]) soll nun gezeigt werden, welche konkreten Aussagen ableitbar sind.

Die Konsolen-Ausgabe des EOT-Tools zeigte am 11.09.2014:

Screenshot_EOT-Tool

Abb. 3 Konsolen-Ausgabe des EOT-Tools

Diese drei berechneten möglichen Zeitpunkte – kombiniert mit dem Resultat der Monte Carlo Simulation – ermöglichen gute Prognosen und helfen dabei diverse Fragen fundiert bearbeiten zu können.

tabelle1

Anmerkung: Das reale Projekt wurde schlussendlich Ende Februar 2015 in Produktion gesetzt.

 

Was man beachten sollte

  • Je mehr Daten für eine Prognose zur Verfügung stehen, desto besser werden Ihre Rückschlüsse daraus werden.
  • EOT ist nicht dafür gedacht, tagesgenaue Prognosen zu liefern. Das jeweils ermittelte Tagesdatum ist nur ein Anhaltspunkt.
  • Prognosen sind und bleiben Prognosen – eine Schau in die Zukunft – sie sind daher mit einem gewissen Unsicherheitsfaktor behaftet, aber:
    • Die Prognosen haben nicht wegzuleugnende Zahlen bzw. Fakten als Basis.
    • Diese Zahlen sind Performance-Werte des gesamten Teams auf Basis der Projekthistorie – sie werden sich nicht „von heute auf morgen“ signifikant verändern.
    • Die Wahrscheinlichkeit für zutreffende Prognosen ist daher hoch.

Mein Wunsch wäre nun, dass dieser Artikel Ihnen Anregungen dafür liefert, wie Sie in Ihrem Testprojekt zu relativ sicheren Prognosen kommen können – denn eines ist absolut sicher: die eingangs erwähnten Fragen an den Software-Testmanager wurden und werden nicht nur mir gestellt.

 

 

Passende Artikel

Kommentare gesperrt.