Testaufwand
Allgemeines
Der Testaufwand gehört zu den sog. Qualitätskosten des zu prüfenden Produkts. Er wird zum Aufwand für präventive Maßnahmen gezählt.[1] Diese schließen auch die Kosten für die Qualität in der Softwareerstellung (siehe "statisches Testen") ein. Ebenso gehören im Besonderen die aktiv ausgeführten Tests (= "dynamische Testarten") – aus Sicht des Projektziels "Produktivsetzung" – zur Fehlervermeidung.
Diesem präventiven steht nach[1] der Aufwand für reaktive Maßnahmen gegenüber, die Kosten der Fehlerbeseitigung. Im engeren Sinn zählen sie nicht zum Testaufwand, sondern zum Aufwand für die Implementierung. Trotzdem werden sie, falls sie während des Testens auftreten, häufig zum Testaufwand gezählt. Hierzu gehören auch Kosten und Schäden, die (durch nicht entdeckte Fehler) erst nach der Produktivsetzung auftreten. Sie können auch außerhalb des Unternehmens (bei Kunden, in der Umwelt etc.) wirken und (in dramatischen Fällen) sogar die Existenz des Unternehmens gefährden.
Hierzu gilt die Faustformel Je später Fehler entdeckt werden, desto aufwändiger ist ihre Behebung, woraus sich auch der Umkehrschluss ableitet: Qualität muss (im ganzen Projektverlauf) implementiert, nicht 'eingetestet' werden[1].
Faktoren, die den Testaufwand beeinflussen, sind: Reifegrad des Entwicklungsprozesses, Qualität und Testbarkeit der Testobjekte, die Testinfrastruktur, Mitarbeiter-Qualifikation, Qualitätsziele und die Teststrategie.
Softwaretests
Ansätze zur Schätzung des Testaufwandes
Alle Faktoren zu analysieren ist schwierig, da sich die meisten Faktoren gegenseitig beeinflussen. Es können folgende Ansätze zur Schätzung benutzt werden: metrikbasierte (im englischen genannt: top-down estimation) und expertenbasierte (im englischen: bottom-up estimation) Ansätze.
Die Metrik-basierten Techniken (als Controlling-Instrumentarium) sind formelbasiert und werden meist relativ zum Entwicklungsaufwand angegeben: dazu zählen unter anderem das Function-Point-Verfahren (FPA) und die Test-Punkt-Analyse (TPA). Dabei können entsprechende Informationen (z. B. Aufwand je Projektphase oder je Testobjekt, Abweichung Plan / Ist, Anzahl gefundener Fehler, Anzahl erforderlicher Retests usw.) ermittelt und dargestellt werden, um die Qualität und die Effizienz des Testprozesses nachzuweisen.
Die Experten-basierten Techniken basieren auf ausführlichen Informationen und involvieren oft Experten. Folgende Techniken gehören dazu: Projektstrukturplan (im englischen: Work Breakdown Structure (WBS)) und Wide Band Delphi (WBD).
Testaufwand aus der Literatur
Der Testaufwand (in Softwareprojekten) liegt je nach Autor zwischen 20 % und 70 % der Gesamtkosten. Pol, Koomen und Spillner beziffern sie in[1] mit 30 % bis 40 % des Gesamtbudgets. Die Streubreite wird von projektspezifischen Gegebenheiten bestimmt.
Wenn der Testaufwand für einzelne Phasen des Testprozesses betrachtet wird, ist er unterschiedlich verteilt: Mit je circa 40 % sind häufig die Test-Spezifikation und die Test-Durchführung beteiligt. Der Rest wäre für die Planung, Auswertung und den Testabschluss zu veranschlagen.
Nach den "Prinzipien des Softwaretestens" (ISTQB), Grundsatz 2, ist vollständiges Testen nicht möglich (*); denn Testen kann zwar die Anwesenheit von Fehlern zeigen, nicht aber deren Abwesenheit (Grundsatz 1) – (*) weil alle Einflussgrößen, in allen möglichen Kombinationen, praktisch nicht prüfbar sind (außer bei trivialen Funktionen).
Deshalb müssen die Testaktivitäten strategisch geplant werden, um die Testintensität, somit auch den Testaufwand, "angemessen" zu wählen. Nach Juran, referenziert in[1], soll der Testaufwand so hoch sein, dass die Gesamtkosten (Testaufwand plus potenzielle Fehlerfolgekosten) auf einem möglichst niedrigen Niveau liegen. Wie die Grafik schematisch zeigt, entstehen bei zu geringer Testintensität überproportional hohe Fehlerfolgekosten, bei zu hoher Testintensität (deren Kosten linear verlaufen) sind die Testkosten im Verhältnis zur erwartbaren Reduzierung von Fehlerfolgekosten (aus noch vorhandenen Fehlern) zu hoch.
Nach ISTQB[2] soll die Höhe des Testaufwands so bemessen sein, dass die Tests genug Informationen liefern, um über die Freigabe (der Software) entscheiden zu können.
Literatur
- Andreas Spillner, Tilo Linz: Basiswissen Softwaretest – Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester: Foundation Level nach ISTQB-Standard. 3., überarbeitete und aktualisierte Auflage, dpunkt.verlag GmbH, Heidelberg 2005, ISBN 3-89864-358-1.
- Martin Pol, Tim Koomen, Andreas Spillner: Management und Optimierung des Testprozesses, ISBN 978-3-89864-951-3
- Erik van Veenendaal (Hrsg. und Mitautor): The Testing Practitioner. 3. Auflage. UTN Publishers, CN Den Bosch, Niederlande 2005, ISBN 90-72194-65-9.
- German Testing Board e.V. & Swiss Testing Board (Hrsg.): Certified Tester – Foundation Level Syllabus. Deutschsprachige Ausgabe, Möhrendorf 2005, International Software Testing Qualifications Board (ISTQB), (PDF; 0,266 MB).
- Andreas Spillner, Tilo Linz, Thomas Roßner, Mario Winter: Praxiswissen Softwaretest – Testmanagement: Aus- und Weiterbildung zum Certified Tester: Advanced Level nach ISTQB-Standard. 1. Auflage. dpunkt.verlag GmbH, Heidelberg 2006, ISBN 3-89864-275-5.
- Harry Sneed, Manfred Baumgartner, Richard Seidl: Der Systemtest - Von den Anforderungen zum Qualitätsnachweis. 3. Auflage. Carl Hanser Verlag, 2011, ISBN 978-3-446-42692-4.
- Harry Sneed, Richard Seidl, Manfred Baumgartner: Software in Zahlen - Die Vermessung von Applikationen. 1. Auflage. Carl Hanser Verlag, 2010, ISBN 978-3-446-42175-2.
Einzelnachweise
- Martin Pol/Tim Koomen/Andreas Spillner, Management und Optimierung des Testprozesses, 2002
- ISTQB: Certified Tester Foundation Level Syllabus, 5.2.4