Warum es so schwierig ist, den Testaufwand zu schätzen

Der Testaufwand  für Softwaretests hängt in der Praxis von einer Vielzahl von Faktoren ab:

• Ist es ein neues Produkt, ein Redesign oder eine Weiterentwicklung?
• Wie hoch sind Prozess- und der Testreifegrad?
• Wie dynamisch sind die Anforderungen?
• Welche Kritikalität haben die erwarteten Fehler? Welcher menschlicher, materieller oder Image-Schaden entsteht?
• Welchen Ausbildungs- und Erfahrungsgrad haben die Tester und Entwicker?
• Wie komplex ist die  Anwendung?
• Welche Infrastruktur, Architektur, Programmiersprache, …?

Diese Liste lässt sich endlos fortsetzen. Demgegenüber bietet die Literatur und das Internet eine Vielzahl von Möglichkeiten, Testaufwände zu schätzen. Dabei gibt es ganz unterschiedliche Ansätze:

• Daumenregeln, wie z. B. 30 % des Projektaufwandes oder 50 % des Entwicklungsaufwandes
• Ableitungen aus Function Points und ähnlichen Modellen
• Ableitungen aus der erwarteten Anzahl Fehler, die z. B. aus der erwarteten LOC ermittelt wird
• Verschiedene  mathematische Modelle

Doch warum fühlen wir uns dabei eigentlich nicht wohl?

• Mathematische Modelle erzeugen eine Scheingenauigkeit, die nicht gegeben ist. Daumenregeln erzeugen gar keine Genauigkeit.
• Oft werden als Basis Werte herangezogen, die zu Beginn des Projektes, bzw. zum Zeitpunkt der Aufwandsschätzung nicht vorhanden sind.
• Es wird eine Erfahrungsdatenbank zu Grunde liegt, die viele Unternehmen nicht haben, vor allem, wenn zusätzlich noch die Vergleichbarkeit der Projekte verlangt wird.
• Die Kosten, um alle Faktoren zu erheben und um daraus den Testaufwand abzuleiten, sind hoch.
• Die berechneten Zahlen sagen nicht aus, welche Aufwände damit abgedeckt sind (wie steht es z. B. mit den Kosten für Testmanagement, Testinfrastruktur, Testtools, Testautomatisierung, usw.).

 

Was können Sie tun?

Diese E-Mail-Adresse ist gegen Spambots geschützt! Sie müssen JavaScript aktivieren, damit Sie sie sehen können.