Die Planung eines anforderungsbasierten Systemtests setzt voraus, dass der Testaufwand anhand der Anforderungen kalkulierbar ist. Wenn Test-Points zur Aufwandsschätzung herangezogen werden, müssen die Test-Points sich aus der Anforderungsdokumentation ableiten lassen. Wenn Testfälle als Basis der Aufwandsschätzung dienen sollen, müssen diese aus den Anforderungen hervorgehen. Mit dem Textanalysator Werkzeug für englisch- und deutschsprachige Texte werden beide gezählt – Test-Points und Testfälle. Anschließend fließen sie in eine modifizierte COCOMO-II Formel ein, um den Aufwand und die Dauer des geplanten Tests zu schätzen. Dabei werden Faktoren wie die Testbarkeit des Systems, der Grad der Testautomation und die Testbedingungen berücksichtigt. Es wird empfohlen mindestens drei Schätzungen durchzuführen und die Ergebnisse zu vergleichen. Es soll eine Kostenbandbreite entstehen mit unterer und oberer Grenze. Diese wird benutzt um mit dem Anwender über den Umfang des Tests zu verhandeln. Letztendlich ist der Umfang des Tests eine Frage des ROI.
Eine unerlässliche Aufgabe im Rahmen der Testplanung ist die Schätzung der Testkosten. Nach der Methode der Vorwärtsplanung wird geschätzt welcher Aufwand erforderlich ist, um die Erfüllung sämtlicher Anforderungen zu bestätigen. Im Anschluss daran wird die Mindestdauer des Tests kalkuliert. Dann erst wird die Höhe des Testbudgets nach den Sollkosten und der Endtermin nach der kalkulierten Dauer ausgerichtet. So würden es die Testverantwortlichen oft gerne sehen.
Nach der Methode der Rückwärtsplanung wird umgekehrt vorgegangen. Zunächst werden ein Testbudget und ein Endtermin festgelegt. Bei der Schätzung geht es darum zu ermitteln wie viele Testfälle bzw. Test-Points mit dem vorgegebenen Budget bis zu dem vorgegebenen Termin getestet werden können. Danach gilt es Prioritäten aufgrund einer Risikoanalyse und einer Nutzwertanalyse zu setzten. Das Ziel ist soviel wie möglich im Rahmen der budgetären und zeitlichen Grenzen zu testen.
Beide Methoden verwenden die gleichen Schätzformel, allerdings mit unterschiedlichen Parameter. Je nach Situation wird die eine oder die andere Methode angewandt.
Voraussetzung für beide Methoden ist die Messung des Testumfangs. Im Falle eines anforderungsbasierten Systemtests heißt das die Messung der Anforderungen. Die Anforderungsdokumente sind entweder manuell oder maschinell zu analysieren um so die Testfälle oder Test-Points zu zählen. Die Testfälle werden entweder aus den Anforderungen oder aus den Anwendungsfällen abgeleitet. Überall wo eine Aktion verlangt, ein Zustand befragt oder eine Bedingung gestellt wird, ist eine Testfall zu spezifizieren. Bei Bedingungen sind es sogar zwei Testfälle, einen für den positiven und einen für den negativen Ausgang. Auf diese Weise ist es möglich alle Testfälle für die Abdeckung des Anforderungstexts zu zählen. Natürlich werden auch weitere Testfälle dazukommen, vor allem dort wo die Anforderungen oberflächlich definiert und unvollständig sind. Aber immerhin hat man eine Ausgangsbasis. Wenn diese Zählung außerdem noch automatisiert ist, kommt man schnell und ohne größeren Aufwand zu einer Testfallzahl.
Das Gleiche gilt für Test-Points, die wie die Function-Points anhand der Eingaben, Ausgaben, Schnittstellen und Datenbanktabellen gezählt werden. Sofern die Benutzeroberflächen und die Systemschnittstellen in dem Anforderungsdokument erwähnt sind, können sie klassifiziert und gewichtet werden. Die Zahl der Datenbanktabellen und deren Attribute geht aus dem Datenmodell hervor. Durch die Zusammenführung der Oberflächen-, Schnittstellen- und Datenbankpunkte kommt man zu den Test-Punkten. Auch diese Zählung lässt sich automatisieren. Damit haben wir zwei verschiedene Messungen für den Testumfang:
Nachdem wir festgestellt haben wie groß das Testvorhaben ist, ist der nächste Schritt die Ermittlung der Testproduktivität, d.h. wie viele Testfälle oder Testpunkte pro Personentag abgearbeitet werden können. Hier haben wir mit Erfahrungswerten zu tun. Sie lassen sich nicht aus der Luft holen. Das Wertvollste an einem professionellen Testbetrieb ist, dass er ein Gedächtnis hat, nämlich die Erfahrungen aus vergangenen Testprojekten. Es gilt diese Erfahrungen zu hüten und fortzuschreiben. Sie können nur schwer aus der Literatur oder von anderen Projekten übernommen werden, denn jede Umgebung hat eine andere Produktivität. Dies ist zum Teil kulturbedingt, zum Teil technikbedingt und zum Teil betriebsbedingt. So haben wir z.B. in einem Projekt im Schnitt 3,8 Testfälle pro Tag, in einem anderem 8,2 Testfälle pro Tag gemessen. In ersterem wurden viele Weboberflächen, im zweiten Batch-Abläufe getestet.
In einem Projekt eines Autors wurden 79.000 Testfälle innerhalb 2 Monaten mit 92 Tester pro Release ausgeführt. Das macht 21 Testfälle pro Testertag. Man muss aber wissen, dass dies mehr ein Regressionstest war. Nur die Änderungen und Erweiterungen wurden gegen die Spezifikation getestet. Der Rest wurde gegen die Vorgänger Version getestet. Heute testet derselbe Testbetrieb 120.000 Testfälle innerhalb 6 Wochen mit 24 Tester. Das ergibt eine Produktivität von sage und schreibe 166 Testfälle pro Testertag. Diese sensationelle Steigerung der Testproduktivität wurde durch die Automatisierung des ganzen Testverfahrens möglich gemacht.
Diese Erfahrungen zeigen, wie schwer es ist, Durchschnittswerte für Testproduktivität zu definieren. Ein automatisierter Test ist unvergleichbar produktiver als ein manueller Test.
Anwendungssysteme sind nicht gleich testbar. Es gibt Systeme die leicht zu testen sind und andere die nur schwer zu testen sind. Ein System in dem die Anwendungslogik mit der Benutzeroberfläche verwoben ist, ist schwerer zu testen als ein System in dem die Anwendungslogik von der Benutzeroberfläche getrennt ist. Die Komponente des zweiten Systems können über eine Batchschnittstelle getestet werden, die Komponente des ersten Systems können nur über die Benutzeroberfläche getestet werden. Systeme mit breiten Import- und Exportschnittstellen sind auch schwerer zu testen, weil die Tester mehr Parameter mit mehr Kombinationsmöglichkeiten generieren müssen. Auch die Größe der Datenbanken beeinflusst die Testbarkeit. Je mehr Attribute eine Datenbank hat, desto mehr Daten müssen generiert und validiert werden.
Die Testbarkeit lässt sich mittels statischer Analyse der Programm-Sourcen, der Oberflächendefinitionen, z.B. der HTML oder XSL Sourcen, der Schnittstellendefinitionen, z.B. der XML oder IDL Sourcen und der Datenbankschemen in SQL oder XML ermitteln. Aus der Analyse der Software-Artefakte folgt ein rationales Maß auf der Skala 0,1 bis 0,9. Dieser Messwert, z.B. 0,45 wird in den Mittelwert 0,5 dividiert um den Testbarkeits-Multiplikator zu bekommen = 1,11. Das bedeutet der Testaufwand wird wegen der unterdurchschnittlichen Testbarkeit der Software um 11% höher sein.
Steht der Testumfang, die Testproduktivität und die Testbarkeit fest, ist die Berechnung der Testaufwände nur eine Frage der Schätzformel. Hier wird eine modifizierte COCOMO Formel verwendet. Die originale COCOMO-II Formel ist:
Die Systemtypen sind Standalone = 0,5, Integriert = 1, Verteilt = 2, Embedded = 4.
Die Systemgrösse kann in Anweisungen, Function-Points, Object-Points, Use-Case Points oder was auch immer sein.
Die Produktivität ist die Zahl der Größeneinheiten, die ein Entwickler pro Monat erzeugen kann.
Der Einflussfaktor ist das Produkt 20 einzelner Einflussfaktoren auf der Skala von 0,7 bis 1,4.
Die Skalierungsexponente ist der Mittelwert fünf verschiedener Projektbedingungen:
im Bereich von 0,91 bis 1,23.
Für die Schätzung von Testprojekten schlagen die Autoren vor, die Systemgrösse und die Produktivität in Testfälle oder Test-Points auszudrucken, der Einflussfaktor durch den Testbarkeit-Multiplikator zu ersetzen und folgende Skalierungsexponenten zu verwenden:
Der Systemtyp ist auf 0,5, 1, 1,5 und 2 zu reduzieren.
Demnach würde ein verteiltes System mit 1200 Testfälle und eine Testbarkeit von 0,45 von einem Testteam mit einer Produktivität von 8 Testfällen pro Testertag und eine Skalierungsexponente von 1,05 320 Testertage kosten.
Diese Schätzung zeigt worauf es ankommt bei der Minimalisierung der Testkosten. Zum Einen muss die Testbarkeit der Software möglichst hoch sein, aber darauf hat der Testteam in der Regel wenig Einfluss. Sie können den Anwender nur dafür sensibilisiern. Auch der Systemtyp ist gegeben. Was die Tester beeinflussen können sind die Testbedingungen und die Testproduktivität. Die Testbedingungen können sie durch professionelle Tester, die aufeinander eingespielt sind, die in einem ausgereiften Testprozess mit einem hohen Automatisierungsgrad arbeiten, verbessern. Ihre Produktivität können sie wiederum durch mehr Testautomatisierung erreichen. Es kommt letztlich darauf an möglichst viele Testfälle in einer möglichst kurzen Zeit durchzuschleusen und dabei möglichst viele Fehler aufdecken. Das heißt hohe Testautomation.
All dies spricht von einer Abkehr von der traditionellen, hausbacken Art Software Systeme zu testen. Die Anwender müssen bereit sein ihre Anwendungssysteme nicht nur von Profis entwickeln zu lassen sondern auch von gut ausgerüsteten Profis testen zu lassen.