Testaufwand mit Test Points
Veröffentlicht auf 30. Juni 2010
Nachdem mein letzter Beitrag um die Schätzung von Softwaregrößen ging, möchte ich mich mit diesem Beitrag dem Thema Schätzung des Testumfangs widmen.
Im Vergleich dazu ist es für den Test jedoch etwas schwieriger einen Umfang zu schätzen, da man keine grundlegende Metrik wie die Lines of Code besitzt. Man ist also so gut wie immer darauf angewiesen eine Metrikendatenbank zu haben, auf deren Grundlage man Schätzungen entwickeln kann.
Folgende Ansatzpunkte werden oft bei der Schätzung des Testumfangs eingesetzt:
* Analoges Schätzen (Beim letzten mal dauert es so und so lange ...)
Ohne Metrikendatenbank und vergleichbare Projekte praktisch nicht anwendbar.
* Schätzungen aufgrund der Softwaregröße (SLOC/FP entspricht x Teststunden)
Aufgrund der Softwareart sollte von Testexperten eine ungefähre Umrechnungskennzahl zwischen der Softwaregröße und dem Testaufwand in Stunden festgelegt werden. Diese sollte im Laufe des Projektes ggf. korrigiert werden, da besonders bei größeren Projekten große Abweichungen eher wahrscheinlich sind und der Aufwand gegen Projektende steigt. Einfach anzuwenden, aber keine explizite Testmetrik ermittelbar.
* Testfall basiertes Schätzen (Testfall entspricht durchschnittlich x Teststunden)
Falls die Anforderungen bereits bekannt sind oder die Testfälle bereits spezifiziert, kann man versuchen für jeden Testfall eine realistische, positive und negative Angabe zur Durchführungsdauer anzugeben, zu verrechnen (P+N+4*R/6) und das Ergebnis dann zusammenzuzählen. Aufwand ohne Anforderungs- oder Testfalldatenbank ist hoch. Keine explizite Testmetrik.
* Aktivitätsbasiertes Schätzen (bottom up Schätzung)
Das Vorgehen dürfte jedem Projektmanager bekannt sein. Man teilt den Test in bestimmte Phasen mit Zielen ein und versucht die Aktivitäten weit möglichst herunterzubrechen. Evtl. werden wie beim vorigen Punkt ebenfalls mehrfach Schätzungen durchgeführt und wie oben miteinander verrechnet. Am Ende wird dann zusammengezählt. Leicht anzuwenden, auch ohne Metrikendatenbank. Keine explizite Testmetrik.
* Test Point basiertes Schätzen
Die Anforderungen (ggf. auch schon Testfälle) werden ähnlich wie bei den Function Points bewertet und verrechnet. Ein Standard oder ähnliches existiert für diese Methode aber meines Wissens nach nicht.
Für die Test Point Methode muss man nun aber nun erst mal definieren, was man unter einem Test Point versteht. Ich suche mir dazu meist eine halbwegs anspruchsvolle Anforderung oder einen Testfall heraus, dessen Testdurchführungszeit abschätzbar ist und nehmen ihn als Grundlage. Ihm werden dann je nach Aufwand/Input/Output/Logik eine bestimmte Anzahl von Test Point zugewiesen. Somit hat man bereits eine Umrechnung für die Test Points hin zu der Testdurchführungszeit.
Ein Test Point wird gebräuchlich wie folgt definiert:
"Ein Test Point ist ein Metrik zur Abschätzung des Testaufwands. Ein Test Point ist äquivalent zu einem normalisierten Testfall mit einem genau bestimmten Input und einem genau vorgegebenem Output."
Vorgegebene Umrechnungskennzahlen wie zwischen SLOC und Function Points existieren für Test Points nicht und müssen somit wenn benötigt selbst festgelegt und wiederum angepasst werden.
Zusätzlich zum normalen Testaufwand sollten aber noch weitere Faktoren berücksichtigt werden, die Einfluss auf die Testdurchführung haben:
* Softwareart und Architektur (Testability)
* Level der Programmiersprache
* Art des Testens (Black Box, White Box, Performance, Funktional...)
* Testlevel (Unit, Integration, System ...)
* gewünschter Testabdeckungsgrad
* Definition eines Testfalls (Sind nur logische Testfälle Testfälle? Ist jede Abwandlung von Testdaten ein neuer Testfall?)
* Die teils unterschiedliche Größe von Testfällen
* Iterationszeit zwischen Fehlermeldung und erneutem Fehlertest
* Testwerkzeuge
* Testumgebung
* Qualität der Testvorgaben. Existieren Reviews für Code oder Anforderungen?
Zur Berechnung des Testaufwands kann wie folgt vorgegangen werden:
1. Bestimmung der Test Points (Konvertierung, Berechnung)
2. Bestimmung des Einflusses der oben genannten Faktoren
Summe aller Faktoren, multipliziert mit Komplexitätsfaktor der Anwendung und Programmiersprache, multipliziert mit einem Faktor für die eingesetzten Werkzeuge.
3. Multiplizieren von 1. und 2.
4. Bestimmung des Testaufwands pro Test Point in Stunden
5 Multiplizieren von 3. und 4. Man erhält eine Anzahl von Teststunden.
Nachteilig bei der Ermittlung der Test Points ist somit:
* Kein Standard
* Vergleichsweise aufwendig
* Keine internationalen Vergleichsdaten vorhanden
* Faktoren etc. werden nach Gefühl verrechnet. Eine realistische Schätzung setzt somit viel Erfahrung mit der Methode und der Software- und Projektart voraus.