Grundlagen der Testkostensch\u00e4tzung <\/h2>\n\n\n\n
F\u00fcr die Abrechnung von Testdurchf\u00fchrungen durch den Testdienstleister gegen\u00fcber dem Auftraggeber gibt es unterschiedliche Varianten. Bisher sind davon zwei in meinen Projekten, in denen ich Testkostensch\u00e4tzungen erstellt habe, zum Einsatz gekommen: Zum einen \u00fcber T&M-Basis (time and material), zum anderen \u00fcber die Komplexit\u00e4t der durchzuf\u00fchrenden Testszenarien. <\/p>\n\n\n\n
Die erste M\u00f6glichkeit besteht darin, die Testdienstleistung anhand des Zeit-Aufwandes (Personen-Tage) abzurechnen. Dabei werden die erforderlichen Tage beziehungsweise Stunden und die ben\u00f6tigte Anzahl an Testern f\u00fcr die Testdurchf\u00fchrung gesch\u00e4tzt. <\/p>\n\n\n\n
Da sich diese Art der Testaufwandsch\u00e4tzung meistens auf einen vorgegebenen Zeitraum bezieht, gibt es keine Zuordnung zu bestimmten Szenarien bzw. Testf\u00e4llen. Daraus ergibt sich, dass diese Sch\u00e4tzung im Allgemeinen durch den Auftraggeber in dem vollen Ma\u00dfe akzeptiert und auch beauftragt wird. <\/p>\n\n\n\n Die zweite Variante, auf welche sich dieser Beitrag bezieht, ist die Abrechnung auf Basis der Testszenarien und des Aufwands \u00fcber ein Komplexit\u00e4tsmodell. Dabei werden im ersten Schritt, anhand der durchzuf\u00fchrenden Testaktivit\u00e4ten, die erforderlichen Testszenarien identifiziert. Im zweiten Schritt werden die zugeh\u00f6rigen Testf\u00e4lle ermittelt und dem jeweiligen Szenario zugeteilt. Diese Szenarien bilden im besten Fall einen Gesch\u00e4ftsprozess ab und laufen somit \u00fcber mehrere, im Unternehmen befindliche Systeme. Solch ein Prozess k\u00f6nnte exemplarisch \u00fcber die folgenden Systeme f\u00fchren: <\/p>\n\n\n\n Daraus folgt meist, dass unterschiedliche Gesch\u00e4ftsprozesse einen unterschiedlich hohen Aufwand bei der Testdurchf\u00fchrung bedingen. Neben der trivialen Betrachtung des direkten Testaufwandes muss ber\u00fccksichtigt werden, dass nicht nur die reine Testdurchf\u00fchrung den eigentlichen Aufwand darstellt, sondern bereits die zu erf\u00fcllenden Vorbedingungen (z. B. bestimmte Datenkonstellationen) in den Aufwand mit eingerechnet werden m\u00fcssen. <\/p>\n\n\n\n Ebenso kann es zu einer h\u00f6heren Testaktivit\u00e4t kommen, sobald weitere Unterst\u00fctzung durch den Auftraggeber w\u00e4hrend der Testdurchf\u00fchrung ben\u00f6tigt wird. Denn aufgrund von Abstimmungen bzw. Verf\u00fcgbarkeiten der jeweiligen Mitarbeitenden des Unternehmens verl\u00e4ngert sich der zeitliche Aufwand. All diese Aspekte haben einen direkten Einfluss auf den Aufwand der Testdurchf\u00fchrung. <\/p>\n\n\n\n Um den Aufwand und damit auch den Preis eines Szenarios f\u00fcr die Testdurchf\u00fchrung zu ermitteln, m\u00fcssen wir die Komplexit\u00e4t der zu erledigenden Testaufgaben bestimmen. Dazu wurden in den vergangenen Projekten unterschiedliche Herangehensweisen genutzt. <\/p>\n\n\n\n Die erste \u201eeinfache\u201c Variante war die Bestimmung der Komplexit\u00e4t innerhalb von drei Klassen (kleines Szenario, mittleres Szenario oder gro\u00dfes Szenario). Aber auch dort gab es f\u00fcr bestimmte Szenarien mit dem Auftraggeber abgestimmte Ausnahmen, welche mit einem h\u00f6heren Aufwand beziffert wurden, da zus\u00e4tzliche externe Dienstleister bei der Testdurchf\u00fchrung beteiligt waren. <\/p>\n\n\n\n F\u00fcr eine genauere Bestimmung der Komplexit\u00e4ten wurde eine ausf\u00fchrlichere Variante mit breiterer Komplexit\u00e4tskategorie erarbeitet und eingef\u00fchrt. Diese erweiterte Einteilung reicht von \u201c1\u201d f\u00fcr ein sehr kleines Szenario bis zu \u201c9\u201d f\u00fcr ein sehr aufwendiges Szenario unter Beteiligung von externen Dienstleistern. <\/p>\n\n\n\n Zur Bestimmung der Kategorie f\u00fcr ein Szenario wurden die drei folgenden Bereiche innerhalb eines einzelnen Szenarios festgelegt: <\/p>\n\n\n\n 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\u00fcssels die Komplexit\u00e4t eines Szenarios. <\/p>\n\n\n\n Nachfolgend werden Probleme bei der Testkostensch\u00e4tzung beschrieben bzw. Gegebenheiten, die dazu f\u00fchren, dass nach erstellter Sch\u00e4tzung oft ein Handeln um die Kategorien der Szenarien beginnt. <\/p>\n\n\n\n Aus Sicht des Auftraggebers ist klar, dass es in den meisten F\u00e4llen um die Kosten der Testdurchf\u00fchrung geht und diese m\u00f6glichst geringgehalten werden sollten, ohne den Testumfang zu mindern. <\/p>\n\n\n\n Da eine Testkostensch\u00e4tzung zeitlich weit vor der eigentlichen Testdurchf\u00fchrung erstellt werden muss, stehen in den meisten F\u00e4llen noch keine genauen Spezifikationen zur Verf\u00fcgung. Im besten Fall sind bereits erste Versionen von Fachkonzepten vorhanden. Diese verf\u00fcgen jedoch oft noch nicht \u00fcber die komplette Systemlandschaft, welche von der Softwareanpassung betroffen ist. Die noch fehlenden Dokumente wirken sich negativ auf die folgenden Punkte aus. <\/p>\n\n\n\n Bei der Testkostensch\u00e4tzung wird der Testaufwand eines Szenarios aufgrund der bisherigen Durchf\u00fchrungen ermittelt, bzw. bei neuen Themen gesch\u00e4tzt und entsprechend eingestuft. Da in den einzelnen Bereichen (z. B. Aufwand f\u00fcr Testdurchf\u00fchrung) eine Sch\u00e4tzung auf Grundlage des zeitlichen Aufwandes durchgef\u00fchrt wird, kommt es immer wieder zu Diskussionen \u00fcber die gesch\u00e4tzten Zeiten und der damit verbundenen Kategorie eines Szenarios. Der Auftraggeber ist nach dem Pr\u00fcfen der Sch\u00e4tzung nicht selten der Meinung, dass es m\u00f6glich ist, die Tests eines Szenarios in k\u00fcrzerer Zeit durchzuf\u00fchren. Oft setzt er diese Meinung durch und die Testkostensch\u00e4tzung wird angepasst – erstes Handeln erfolgreich abgeschlossen<\/em>. <\/p>\n\n\n\n Diese kleineren Abweichungen k\u00f6nnen durch erfahrene Tester, welche die beteiligten Systeme in- und auswendig kennen und somit schneller bei der Testdurchf\u00fchrung sind, ausgeglichen werden. Unerfahrene Tester, welche bei einem oder mehreren Systemen innerhalb des Szenarios nicht \u00fcber das Expertenwissen verf\u00fcgen, ben\u00f6tigen etwas mehr Zeit, wodurch bereits die erste Diskrepanz zwischen dem gesch\u00e4tzten und dem tats\u00e4chlichen Aufwand entsteht. <\/p>\n\n\n\n Eine weitere Diskrepanz entsteht bei \u00c4nderungen an der Software \u00fcber mehrere Systeme, durch die der Aufwand f\u00fcr das Herstellen der Testvorbedingungen steigt. Dies kann daraus folgen, dass bestimmte Datenkonstellationen nicht mehr ohne Weiteres im Vorsystem erzeugt werden k\u00f6nnen. Dies geschieht z. B. durch den Wegfall von Schreibrechten auf einer Datenbank. Da in diesem Projekt regelm\u00e4\u00dfige Softwareanpassungen (halbj\u00e4hrlich) durchgef\u00fchrt werden, entstehen nach einer gewissen Zeit immer wieder Szenarien, welche den gleichen Gesch\u00e4ftsprozess abbilden. Diese bisherigen Sch\u00e4tzungen werden zum Vergleich herangezogen. Somit werden auch kleinere zus\u00e4tzliche Aufw\u00e4nde, wie der Mehraufwand beim Herstellen der Testvorbedingungen, in der Kategorie gesenkt. Die Testkostensch\u00e4tzung wird angepasst – zweites Handeln erfolgreich abgeschlossen<\/em>. <\/p>\n\n\n\n Es kann bei der Testkostensch\u00e4tzung auch zu dem Punkt kommen, dass ein Szenario in der Kategorie zu gering eingestuft wurde. Dies tritt z. B. bei komplett neuen Funktionalit\u00e4ten in der Software auf, f\u00fcr die es noch keine Erfahrungswerte gibt. Somit wird es n\u00f6tig, das Szenario bei der n\u00e4chsten Sch\u00e4tzung in der h\u00f6heren Kategorie einzuordnen. Diese Erh\u00f6hung der Kategorie wird durch den Auftraggeber gepr\u00fcft, welcher diesbez\u00fcglich kaum Erfahrungswerte besitzt und die vorherige Sch\u00e4tzung als Grundlage verwendet. Die Testkostensch\u00e4tzung wird in diesem Fall nicht angepasst – dritte<\/em>s<\/em> Handel<\/em>n<\/em> erfolgreich abgeschlossen<\/em>. <\/p>\n\n\n\n Dieses Handeln wird nicht bei jeder Kostensch\u00e4tzung mit allen Szenarien durchgef\u00fchrt, kommt aber bei jeder Sch\u00e4tzung mit einzelnen Szenarien immer wieder einmal vor.<\/p>\n\n\n\n Eine Testkostensch\u00e4tzung auf Grundlage von zeitlichen Aufw\u00e4nden sollte aus meiner Sicht nur f\u00fcr interne Zwecke beim Testdienstleister zur Ermittlung der Komplexit\u00e4t erfolgen. Denn eine zeitlich abh\u00e4ngige Sch\u00e4tzung f\u00fcr den Aufwand der Testvorbereitung, die Testdurchf\u00fchrung etc. kann nur funktionieren, wenn die einzelnen notwendigen Parameter auch messbar und von beiden Seiten festgelegt sind. Unterschiede ergeben sich bereits bei der Durchf\u00fchrung und Protokollierung von Testf\u00e4llen durch verschiedene Tester. Der erste Tester protokolliert seine Ergebnisse genauer und mit zus\u00e4tzlichen Screenshots, wohingegen der zweite Tester mittels Copy & Paste aus dem System die Ergebnisse ausreichend protokolliert. Dadurch kann bereits eine Abweichung von +\/- 30 Minuten entstehen. <\/p>\n\n\n\n F\u00fcr eine Testkostensch\u00e4tzung ist es notwendig, Bewertungskriterien heranzuziehen. Diese sollten aber sowohl f\u00fcr den Auftraggeber als auch den Testdienstleister nachvollziehbar und bewertbar sein. Dar\u00fcber hinaus muss eine gewisse Vertrauensbasis untereinander gegeben sein, damit eine f\u00fcr beide Seiten \u00fcberzeugende Sch\u00e4tzung erstellt und akzeptiert werden kann. Denn auch wenn manche Sch\u00e4tzungen von einzelnen Szenarien tiefer eingestuft werden, so gibt es wiederum auch solche, die in der Kategorie h\u00f6her eingestuft sind. Dadurch kann sich die Testkostensch\u00e4tzung in der Gesamtheit die Waage halten. <\/p>\n\n\n\n Wenn man einmal eine gemeinsame Basis gefunden hat, erleichtert dies das Arbeiten an einer Testkostensch\u00e4tzung ungemein. Denn wenn beide Seiten die gleiche Auffassung von dem gesch\u00e4tzten Aufwand vertreten, werden die nachtr\u00e4glichen Anpassungen \u2013 das \u201cHandeln wie auf dem Basar\u201d \u2013 zum Gro\u00dfteil minimiert. <\/p>\n","protected":false},"excerpt":{"rendered":" Das Erstellen einer m\u00f6glichst genauen und von allen Beteiligten akzeptierten Testkostensch\u00e4tzung stellt oft eine Herausforderung dar.<\/p>\n","protected":false},"author":114,"featured_media":2167,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","footnotes":""},"categories":[10],"tags":[561,562,563,570,17,30],"topics":[],"class_list":["post-2124","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-qualitaetssicherung","tag-test","tag-testkosten","tag-kosten","tag-zeiss-digital-innovation","tag-qa","tag-qualitaetssicherung"],"acf":[],"yoast_head":"\n![\"Handschlag\"](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/02\/202102_Testkostenschaetzung_1-600x400.jpg\")
Komplexit\u00e4t bestimmen <\/h2>\n\n\n\n
![\"Abstimmung](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/02\/202102_Testkostenschaetzung_2-600x400.jpg\")
Probleme bei der Testkostensch\u00e4tzung <\/h2>\n\n\n\n
Fazit <\/h2>\n\n\n\n