Wenn sich ein externer Testdienstleister und der Kunde über den Umfang des nächsten Testprojektes abstimmen, nutzen sie eine Testkostenschätzung. Das Erstellen einer möglichst genauen und von allen Beteiligten akzeptierten Testkostenschätzung stellt aber meist eine Herausforderung dar. Dafür gibt es zwei Gründe – der Zeitpunkt der Erstellung und die festgelegten Parameter zur einzelnen Bewertung von Testszenarien bzw. Testfällen. Die meisten werden sich nun sicher die Frage stellen, wie es mit dieser Problemstellung zu genannter Überschrift gekommen ist. Diese Erkenntnis beruht auf meinen bisherigen Erfahrungen beim Erstellen von früheren Testkostenschätzungen. Dabei kam es immer wieder zu den gleichen Grundsatzdiskussionen und Anpassungen der erstellten Testkostenschätzungen. Darauf wird später noch einmal eingegangen. Zunächst werden die Grundlagen für eine Testkostenschätzung beschrieben.
Grundlagen der Testkostenschätzung
Für die Abrechnung von Testdurchführungen durch den Testdienstleister gegenüber dem Auftraggeber gibt es unterschiedliche Varianten. Bisher sind davon zwei in meinen Projekten, in denen ich Testkostenschätzungen erstellt habe, zum Einsatz gekommen: Zum einen über T&M-Basis (time and material), zum anderen über die Komplexität der durchzuführenden Testszenarien.
Die erste Möglichkeit besteht darin, die Testdienstleistung anhand des Zeit-Aufwandes (Personen-Tage) abzurechnen. Dabei werden die erforderlichen Tage beziehungsweise Stunden und die benötigte Anzahl an Testern für die Testdurchführung geschätzt.
Da sich diese Art der Testaufwandschätzung meistens auf einen vorgegebenen Zeitraum bezieht, gibt es keine Zuordnung zu bestimmten Szenarien bzw. Testfällen. Daraus ergibt sich, dass diese Schätzung im Allgemeinen durch den Auftraggeber in dem vollen Maße akzeptiert und auch beauftragt wird.
Die zweite Variante, auf welche sich dieser Beitrag bezieht, ist die Abrechnung auf Basis der Testszenarien und des Aufwands über ein Komplexitätsmodell. Dabei werden im ersten Schritt, anhand der durchzuführenden Testaktivitäten, die erforderlichen Testszenarien identifiziert. Im zweiten Schritt werden die zugehörigen Testfälle ermittelt und dem jeweiligen Szenario zugeteilt. Diese Szenarien bilden im besten Fall einen Geschäftsprozess ab und laufen somit über mehrere, im Unternehmen befindliche Systeme. Solch ein Prozess könnte exemplarisch über die folgenden Systeme führen:
- Kundenverwaltungssoftware (interne Nutzung durch Auftraggeber)
- Dokumentenablage (interne Nutzung durch Auftraggeber)
- Abrechnungssoftware (interne Nutzung durch Auftraggeber)
- Geräteverwaltung (interne Nutzung durch Auftraggeber)
- Kundenportal (externe Nutzung durch Kunden)
- Gerätenutzung (externe Nutzung durch Kunden)
- zusätzliche Prüfungen in Datenbanken
Daraus folgt meist, dass unterschiedliche Geschäftsprozesse einen unterschiedlich hohen Aufwand bei der Testdurchführung bedingen. Neben der trivialen Betrachtung des direkten Testaufwandes muss berücksichtigt werden, dass nicht nur die reine Testdurchführung den eigentlichen Aufwand darstellt, sondern bereits die zu erfüllenden Vorbedingungen (z. B. bestimmte Datenkonstellationen) in den Aufwand mit eingerechnet werden müssen.
Ebenso kann es zu einer höheren Testaktivität kommen, sobald weitere Unterstützung durch den Auftraggeber während der Testdurchführung benötigt wird. Denn aufgrund von Abstimmungen bzw. Verfügbarkeiten der jeweiligen Mitarbeitenden des Unternehmens verlängert sich der zeitliche Aufwand. All diese Aspekte haben einen direkten Einfluss auf den Aufwand der Testdurchführung.
Komplexität bestimmen
Um den Aufwand und damit auch den Preis eines Szenarios für die Testdurchführung zu ermitteln, müssen wir die Komplexität der zu erledigenden Testaufgaben bestimmen. Dazu wurden in den vergangenen Projekten unterschiedliche Herangehensweisen genutzt.
Die erste „einfache“ Variante war die Bestimmung der Komplexität innerhalb von drei Klassen (kleines Szenario, mittleres Szenario oder großes Szenario). Aber auch dort gab es für bestimmte Szenarien mit dem Auftraggeber abgestimmte Ausnahmen, welche mit einem höheren Aufwand beziffert wurden, da zusätzliche externe Dienstleister bei der Testdurchführung beteiligt waren.
Für eine genauere Bestimmung der Komplexitäten wurde eine ausführlichere Variante mit breiterer Komplexitätskategorie erarbeitet und eingeführt. Diese erweiterte Einteilung reicht von “1” für ein sehr kleines Szenario bis zu “9” für ein sehr aufwendiges Szenario unter Beteiligung von externen Dienstleistern.
Zur Bestimmung der Kategorie für ein Szenario wurden die drei folgenden Bereiche innerhalb eines einzelnen Szenarios festgelegt:
- Aufwand für Testvorbereitung
- Aufwand für Testdurchführung
- Aufwand für Testspezifikation
In diesen drei Bereichen werden jeweils eine gewisse Anzahl an Punkten vergeben, die sich am zeitlichen Aufwand orientieren. Die Summe der gesamten Punkte aus diesen drei Bereichen ergibt mit Hilfe eines Umrechnungsschlüssels die Komplexität eines Szenarios.
Probleme bei der Testkostenschätzung
Nachfolgend werden Probleme bei der Testkostenschätzung beschrieben bzw. Gegebenheiten, die dazu führen, dass nach erstellter Schätzung oft ein Handeln um die Kategorien der Szenarien beginnt.
Aus Sicht des Auftraggebers ist klar, dass es in den meisten Fällen um die Kosten der Testdurchführung geht und diese möglichst geringgehalten werden sollten, ohne den Testumfang zu mindern.
Da eine Testkostenschätzung zeitlich weit vor der eigentlichen Testdurchführung erstellt werden muss, stehen in den meisten Fällen noch keine genauen Spezifikationen zur Verfügung. Im besten Fall sind bereits erste Versionen von Fachkonzepten vorhanden. Diese verfügen jedoch oft noch nicht über die komplette Systemlandschaft, welche von der Softwareanpassung betroffen ist. Die noch fehlenden Dokumente wirken sich negativ auf die folgenden Punkte aus.
Bei der Testkostenschätzung wird der Testaufwand eines Szenarios aufgrund der bisherigen Durchführungen ermittelt, bzw. bei neuen Themen geschätzt und entsprechend eingestuft. Da in den einzelnen Bereichen (z. B. Aufwand für Testdurchführung) eine Schätzung auf Grundlage des zeitlichen Aufwandes durchgeführt wird, kommt es immer wieder zu Diskussionen über die geschätzten Zeiten und der damit verbundenen Kategorie eines Szenarios. Der Auftraggeber ist nach dem Prüfen der Schätzung nicht selten der Meinung, dass es möglich ist, die Tests eines Szenarios in kürzerer Zeit durchzuführen. Oft setzt er diese Meinung durch und die Testkostenschätzung wird angepasst – erstes Handeln erfolgreich abgeschlossen.
Diese kleineren Abweichungen können durch erfahrene Tester, welche die beteiligten Systeme in- und auswendig kennen und somit schneller bei der Testdurchführung sind, ausgeglichen werden. Unerfahrene Tester, welche bei einem oder mehreren Systemen innerhalb des Szenarios nicht über das Expertenwissen verfügen, benötigen etwas mehr Zeit, wodurch bereits die erste Diskrepanz zwischen dem geschätzten und dem tatsächlichen Aufwand entsteht.
Eine weitere Diskrepanz entsteht bei Änderungen an der Software über mehrere Systeme, durch die der Aufwand für das Herstellen der Testvorbedingungen steigt. Dies kann daraus folgen, dass bestimmte Datenkonstellationen nicht mehr ohne Weiteres im Vorsystem erzeugt werden können. Dies geschieht z. B. durch den Wegfall von Schreibrechten auf einer Datenbank. Da in diesem Projekt regelmäßige Softwareanpassungen (halbjährlich) durchgeführt werden, entstehen nach einer gewissen Zeit immer wieder Szenarien, welche den gleichen Geschäftsprozess abbilden. Diese bisherigen Schätzungen werden zum Vergleich herangezogen. Somit werden auch kleinere zusätzliche Aufwände, wie der Mehraufwand beim Herstellen der Testvorbedingungen, in der Kategorie gesenkt. Die Testkostenschätzung wird angepasst – zweites Handeln erfolgreich abgeschlossen.
Es kann bei der Testkostenschätzung auch zu dem Punkt kommen, dass ein Szenario in der Kategorie zu gering eingestuft wurde. Dies tritt z. B. bei komplett neuen Funktionalitäten in der Software auf, für die es noch keine Erfahrungswerte gibt. Somit wird es nötig, das Szenario bei der nächsten Schätzung in der höheren Kategorie einzuordnen. Diese Erhöhung der Kategorie wird durch den Auftraggeber geprüft, welcher diesbezüglich kaum Erfahrungswerte besitzt und die vorherige Schätzung als Grundlage verwendet. Die Testkostenschätzung wird in diesem Fall nicht angepasst – drittes Handeln erfolgreich abgeschlossen.
Dieses Handeln wird nicht bei jeder Kostenschätzung mit allen Szenarien durchgeführt, kommt aber bei jeder Schätzung mit einzelnen Szenarien immer wieder einmal vor.
Fazit
Eine Testkostenschätzung auf Grundlage von zeitlichen Aufwänden sollte aus meiner Sicht nur für interne Zwecke beim Testdienstleister zur Ermittlung der Komplexität erfolgen. Denn eine zeitlich abhängige Schätzung für den Aufwand der Testvorbereitung, die Testdurchführung etc. kann nur funktionieren, wenn die einzelnen notwendigen Parameter auch messbar und von beiden Seiten festgelegt sind. Unterschiede ergeben sich bereits bei der Durchführung und Protokollierung von Testfällen durch verschiedene Tester. Der erste Tester protokolliert seine Ergebnisse genauer und mit zusätzlichen Screenshots, wohingegen der zweite Tester mittels Copy & Paste aus dem System die Ergebnisse ausreichend protokolliert. Dadurch kann bereits eine Abweichung von +/- 30 Minuten entstehen.
Für eine Testkostenschätzung ist es notwendig, Bewertungskriterien heranzuziehen. Diese sollten aber sowohl für den Auftraggeber als auch den Testdienstleister nachvollziehbar und bewertbar sein. Darüber hinaus muss eine gewisse Vertrauensbasis untereinander gegeben sein, damit eine für beide Seiten überzeugende Schätzung erstellt und akzeptiert werden kann. Denn auch wenn manche Schätzungen von einzelnen Szenarien tiefer eingestuft werden, so gibt es wiederum auch solche, die in der Kategorie höher eingestuft sind. Dadurch kann sich die Testkostenschätzung in der Gesamtheit die Waage halten.
Wenn man einmal eine gemeinsame Basis gefunden hat, erleichtert dies das Arbeiten an einer Testkostenschätzung ungemein. Denn wenn beide Seiten die gleiche Auffassung von dem geschätzten Aufwand vertreten, werden die nachträglichen Anpassungen – das “Handeln wie auf dem Basar” – zum Großteil minimiert.
Dieser Beitrag wurde verfasst von:
