Fakultät für Wirtschaftswissenschaften Seminararbeit Testmanagement im Modul Formale Methoden eingereicht von: Gutachter: Julia Volkmer, Michael Zschintzsch, Sebastian Ballert Prof. Dr. Jürgen Cleve Berlin, den 18. November 2012
I I. Inhaltsverzeichnis I. Inhaltsverzeichnis... I II. III. IV. Abbildungsverzeichnis... III Tabellenverzeichnis... IV Abkürzungsverzeichnis... V 1. Einleitung... 1 2. Notwendigkeit eines strukturierten Testmanagements... 2 2.1. Was versteht man unter Testmanagement?... 2 2.2. Was ist schlechtes Testmanagement?... 3 2.3. Beispiele von Softwarefehlern... 4 2.4. Aktuelle Zahlen / Fakten... 5 3. Die verschiedenen Aspekte des Testmanagements... 5 3.1. Testorganisation... 5 3.2. Qualifikation des Testteams... 7 3.3. Testplanung... 8 3.3.1. Testkonzept... 9 3.3.2. Priorisierung der Tests... 11 3.3.3. Kriterien für Teststart und Testende... 12 3.4. Kosten- und Wirtschaftlichkeitsaspekte... 13 3.4.1. Fehlerkosten... 14 3.4.2. Testkosten... 16 3.4.3. Schätzung des Testaufwands... 18 3.5. Wahl der Teststrategie... 19 3.5.1. Vorbeugender vs. reaktiver Ansatz... 19
II 3.5.2. Analytischer vs. heuristischer Ansatz... 20 3.5.3. Testen und Risiko... 21 3.6. Management der Testarbeiten... 23 3.6.1. Testzyklusplanung... 23 3.6.2. Testzyklusüberwachung... 25 3.6.3. Testzyklussteuerung... 25 3.7. Fehlermanagement... 26 3.7.1. Fehlermeldung... 26 3.7.2. Fehlerklassifikation... 27 3.7.3. Fehlerstatus... 28 3.8. Konfigurationsmanagement... 29 3.9. Relevante Normen und Standards... 30 4. Outsourcing als Möglichkeit der Optimierung... 30 4.1. Ziele und Hintergründe des Outsourcings... 31 4.2. Aktuelle Verbreitung... 33 4.3. Auswahlkriterien und Aspekte für eine erfolgreiche Zusammenarbeit... 35 5. Fallbeispiel... 37 6. Fazit... 37 V. Literaturverzeichnis... 38 VI. Ehrenwörtliche Erklärung... 39 VII. Anhang... 40
III II. Abbildungsverzeichnis Abbildung 1: Ursachen schlechter Testdurchläufe... 4 Abbildung 2: Softwarefehler im historischen Ablauf... 4 Abbildung 3: Vor- und Nachteile von unabhängigen Testern... 5 Abbildung 4: Phasen der Testplanung... 8 Abbildung 5: Beziehung zwischen Fehlerkosten und Qualitätskosten... 13 Abbildung 6: Kosten eines Fehlers in Abhängigkeit von der Phase, in der der Fehler gemacht, und der Phase, in der entdeckt wurde... 15 Abbildung 7: Typischer Aufbau einer Fehlerdatenbank... 27 Abbildung 8: Fehlerstatusmodell... 28 Abbildung 9: Vorteile im Software-Testing durch die Zusammenarbeit mit externen Spezialisten... 32 Abbildung 10: Organisation der Testaktivitäten... 33 Abbildung 11: Priorisierte Kompetenzen der Testing-Dienstleister... 35 Abbildung 12: Aspekte zur Messung der Zielerreichung des Testing-Teams... 36
IV III. Tabellenverzeichnis Tabelle 1: Übersicht Aufgaben und Qualifikation von qualifizierten Mitarbeitern... 8 Tabelle 2: Testkostenbeeinflussende Faktoren... 17 Tabelle 3: Einfluss des Testmanagers auf die Faktoren... 18 Tabelle 4: Herangehensweisen - analytischer vs. heuristischer Ansatz... 21 Tabelle 5: Projektrisiken... 22 Tabelle 6: Metriken im Rahmen der Zyklusüberwachung... 25 Tabelle 7: Anforderungen an das Konfigurationsmanagement... 29 Tabelle 8: Übersicht Normen und Standards... 30
IV. Abkürzungsverzeichnis V
1. Einleitung 1 Die Nutzung von Software hat sich längst in den Alltag der Menschheit als ein fester Bestandteil festgesetzt. Ob die digitale Anzeige der U-Bahn, oder die höchstkomplexe Software im alltäglichen Betrieb eines Flughafens, wir verlassen uns heute mehr denn je auf modernste Technologie, die schnell ausgerollt wird und immer zuverlässiger aus der Sicht des Endkunden arbeitet. Wirklich wahrnehmen wir jedoch die Abhängigkeit von Software erst dann, wenn diese die Menschen im Stich lässt. Schon ein einziger Applikationsfehler an einer entscheidenden Stelle eines Prozesses oder einer Transaktion kann einen Systemausfall und eine teure und komplexe Reparatur nach sich ziehen, welche Umsätze und Kundenkulanz kostet, oder im Extremfall sogar Menschen gefährdet, wie viele Beispiele zeigen. 1 So kam es 1991 durch ein Versäumnis im Testprozess in diversen Großstädten Amerikas zu einem kompletten Ausfall der Telefonanlage. Die Software die für die Rufweiterleitung verantwortlich war, ist komplett ausgefallen. er Code des Programmes bestand aus mehreren Millionen von Zeilen. Bevor die Software in Betrieb gegangen ist, gab es einen 13wöchigen erfolgreichen Testlauf. Zu einem späteren Zeitpunkt wurden lediglich drei Zeilen des Codes ausgetauscht bzw. angepasst. Die Firma verzichtete aus Zeitgründen und den nur minimalen Änderungen am Code auf eine nochmalige intensive Testphase. Diese hätte der amerikanische Telefondienstleister wohl in Anspruch nehmen sollen, da diese kleine Anpassung letztlich zu dem Totalausfall führte Verärgerte Kunden und das verspätete Durchführen der Testphase waren die Konsequenz. 2 Durch Vorfälle wie diese wächst das Bewusstsein, dass eine gute Software-Prüfung eine spezialisierte und professionelle Fähigkeit ist und nicht bloß ein nachträglicher Einfall, der gegen Ende des IT-Projektes irgendwie noch eingearbeitet wird. Doch diese Aufgabe letztlich zu meistern kann für IT-Führungskräfte, die oftmals mit einem Mangel an ausgebildeten Softwaretestern und knappen Testressourcen konfrontiert sind, eine schwer zu meisternde Herausforderung sein. 3 Nach einer aktuellen Studie werden lediglich die Hälfte aller Softwareprojekte erfolgreich nach Plan und ohne Nacharbeiten abgeschlossen werden. Diesen Anteil gilt es im Rahmen 1 Vgl. Capgemini, 2009, S. 2. 2 Vgl. Wiender, 1994. S. 28. 3 Vgl. Capgemini, 2009, S. 2.
2 des Testmanagements zu verbessern. Denn unsichere Software kann, wie bereits aufgezeigt, für ein Unternehmen geschäftsschädigende Konsequenzen haben. 4 Die vorliegende Hausarbeit beschäftigt sich mit dem Management des Testens bzw. Testprozesses. Ziel ist es, die verschiedenen Teile des Testmanagements vorzustellen und aufzuzeigen, warum ein gutes Testmanagement elementar wichtig ist. Einleitend wird beschrieben, was unter Testmanagement genau zu verstehen ist und welche aktuellen Trends vorherrschen. Darauf aufbauend werden die verschiedenen Aspekte des Testmanagements, wie der Aufbau von Testorganisationen oder wirtschaftliche Überlegungen, theoretisch erläutert. Grundlage ist hierfür das Buch Basiswissen Softwaretest der Autoren Spillner und Linz. Ergänzend werden an geeigneten Stellen weitere Literatur bzw. Ergebnisse aktueller Studien einbezogen. Im Anschluss erfolgt ein Exkurs über das Outsourcing von Testmanagement-Aktivitäten. Im Rahmen dieses Kapitels werden die Ziele sowie die aktuelle Verbreitung und Erfolgsfaktoren, abgeleitet aus den Ergebnissen aktueller Studien, beschrieben. Abschließend sollen 2 Fallbeispiele aus dem betrieblichen Umfeld die praktische Relevanz der verschiedenen Aspekte des Testmanagements aufzeigen. 2. Notwendigkeit eines strukturierten Testmanagements In diesem Kapitel werden die Grundlagen für das weitere Verständnis des Testens in der Hausarbeit gelegt. Im Besonderen wird dabei der Fokus auf Begriffsdefinitionen sowie auf die Herausarbeitung von schlechtem Testmanagement gelegt. 2.1. Was versteht man unter Testmanagement? Zu Beginn soll erst einmal der Begriff des Testens genauer erläutert werden. Testen wird der gesamte Prozess bezeichnet, ein Programm auf systematische Weise auszuführen, um die korrekte Umsetzung der Anforderungen nachzuweisen und um Fehlerwirkungen aufzudecken. 5 Ein Testprozess ist demnach nicht nur die Durchführung dessen, sondern auch diese zu planen, durchzuführen und zu dokumentieren 6. An diesem Punkt findet ein Über- 4 Vgl. http://www.ferchau.de/news/archiv/details/idc-studie-viele-unternehmen-sind-testmuffel-1082/; 18.10.2012. 5 Rosner, T. u.a., 2010, S. 24. 6 Vgl. Rosner, T. u.a., 2010,. S. 24.
3 gang der Softwareentwicklung in die Managementebene statt, in das Testmanagement. Dieses definiert für die Testfälle die Anforderungen und den Umfang des Testes. Konzeptionell muss entschieden werden, ob die Durchführung des Testes eher automatisiert oder eher manuell durchführbar ist. Der Testmanager ist die Person, welche die Aufgaben genau definiert, diese weiterverteilt und die benannten Testpersonen verwaltet, den Testfortschritt dokumentiert sowie die Ergebnisse des Testes zusammenstellt, auswertet und zurück an die Softwareentwicklung spielt. 7 Dabei wird in zwei verschiedene Arten von Tests unterschieden. Zum einen den statischen und zum anderen den dynamischen. Statische Tests kennzeichnen sich dadurch, dass sie [ ] den Prüfgegenstand [ ] nicht ausführen und somit auf alle Entwicklungsprodukte also auch z.b. Anforderungs- und Entwurfsspezifikationen anwendbar sind [ ] 8. Dynamische Tests hingegen führen Testobjekte (Programmcode) mit dem Ziel aus, Fehlerwirkung zu finden oder die richtige Umsetzung der vorher definierten Anforderungen nachzuweisen. 9 2.2. Was ist schlechtes Testmanagement? Bevor in der Hausarbeit dargelegt wird, inwiefern das Testmanagement erfolgreich durchgeführt wird, soll erst einmal herausgestellt werden, was schlechtes Testmanagement ausmacht. Die Studie Erfolgreiche Software-Projekte durch Software Quality Assurance Software- Entwicklung und Software-Testing in Deutschland 2012 unterstreicht nochmals, dass Unternehmen heutzutage im Bereich des Testmanagements Defizite aufweisen. Das Stichwort Software Quality Assurance (SQA) umfasst dabei [ ] die Planung, Software, Dienstleistungen und konzeptionelle Ansätze für die Testabläufe innerhalb eines Software-Projektes auf Basis der Richtlinien eines Unternehmens. 10 Gerade bei der Beherrschung dieser wichtigen Ansätze zur Durchführung von Testing liegen die defizitären Ursachen wie folgende Grafik im Überblick zeigt: 7 Vgl. Rosner, Brandes, Götz, Winter, 2010, S. 23-25. 8 Rosner, T. u.a., 2010, S. 16. 9 Rosner, T. u.a., 2010,. S. 16. 10 Autor unbekannt: http://www.ferchau.de/news/archiv/details/idc-studie-viele-unternehmen-sindtestmuffel-1082/; 18.10.2012.
4 Mangelnde Abstimmung zwischen Anwendungsentwicklern und Testern unzureichende Verankerung des Testings geringer Automatisierungsgrad des Testens ungeeignete Auswahl von Testmethoden Abbildung 1: Ursachen schlechter Testdurchläufe Eigene Darstellung in Anlehnung an: http://www.ferchau.de/news/archiv/details/idc-studie-vieleunternehmen-sind-testmuffel-1082/ Nach bereits angesprochener Studie ist bei Softwareprojekten als großer Missstand das Nichteinhalten der Zeit- und Budgetplanung, welche im Verantwortungsbereich des Projektmanagements liegt angegeben. Demnach ist unzureichendes Projektmanagement die größte Herausforderung beim Testen. 11 2.3. Beispiele von Softwarefehlern Die Geschichte der Softwarefehler ist lang. Folgender Zeitstrahl stellt historische Softwarefehler in der Übersicht dar: Abbildung 2: Softwarefehler im historischen Ablauf Quelle: Autor Unbekannt: http://www.certitudo-gmbh.de/g_geschichte.html; 28.10.2012 11 Vgl. Autor unbekannt: http://www.ferchau.de/news/archiv/details/idc-studie-viele-unternehmen-sindtestmuffel-1082/; 18.10.2012.
5 2.4. Aktuelle Zahlen / Fakten Zu ergänzen 3. Die verschiedenen Aspekte des Testmanagements Nachdem im vorrangegangen Gliederungspunkt das grundsätzliche Verständnis des Testens gelegt wurde, wird im folgenden Teil der Arbeit explizit die Organisation von Testteams und die Planung von Testumläufen beschrieben. 3.1. Testorganisation Die Organisation des Testings hängt nicht nur von der Aufstellung von Testteams zusammen, sondern richtet sich auch nach der Branche. Gerade in der Automobil- und Luftfahrtbranche kommt diese Phase eher, als bspw. im Bankensektor. 12 Nichtsdestotrotz hat jede Branche gemein, dass über den kompletten Produktlebenszyklus Testingeinheiten durchzuführen sind. Das Zusammenstellen von Testteams stellt die größte Schwierigkeit in der Testorganisation dar. Sicherlich wäre es die simpelste Lösung die Entwickler ihre Arbeitsergebnisse selber testen zu lassen. Jedoch stellt die Betriebsblindheit beim Testen ein erhöhtes Gefahrenpotential dar. Fehler werden nicht erkannt, Wechselwirkungen zu anderen Systemen/Projektteilnehmern falsch eingeschätzt. Folgende Grafik stellt die Vor- und Nachteile von unabhängigen Testern in der Übersicht dar: 13 Vorteile Objektivere Herangehenweise kritisches Hinterfragen von Annahmen im technischen Konzept Nachteile Isolation kann behindernd zwischen Tester und Entwickler wirken zu wenig Ressourcen decken nicht alle Testfälle ab Entwickler senken den Qualitätsanspruch an ihre Arbeit Abbildung 3: Vor- und Nachteile von unabhängigen Testern Quelle: Eigene Darstellung In Anlehnung an Linz, Spillner, S. 173, 2010 Um der Diskrepanz zwischen den Vor- und Nachteilen zu entgegnen bieten sich verschiedene Modelle für das unabhängige Testen an. Diese definieren sich in der Teilung der zu erledigenden Aufgaben zwischen den Entwicklern und Testern: 12 Haberl, P. u.a., 2012, S. 9. 13 Vgl. Linz; Spillner, 2010, S. 173.
6 1. Gegenseitiges testen: Testing der Programme der Entwicklerkollegen, kein Testung der eigenen Programme. 2. Aufteilung der Entwicklerteams: Einige Entwickler werden nur für das Testing abgestellt und erledigen somit alle aufkommenden Testarbeiten des Teams. 3. Aufstellung unabhängiger Tester: Diese können bspw. aus der Fachabteilung kommen. 4. Hinzunahme unabhängiger Tester: Einige Tests verlangen keine Fachkenntnisse über das Projekt und können gut von anderen Abteilungen übernommen werden (Useability; Lasttests). 5. Hinzunahme anderer Organisationseinheiten: externe Dienstleister oder Testabteilungen können herangezogen werden, was ebenso das unabhängige testen gewährleistet. 14 Für jedes Projekt gilt es somit, das passende Modell für sich zu finden. In jedem Modell sollten Test-Consultants einbezogen werden. Diese nehmen die Funktion der Beratung ein und geben methodische Unterstützungen bei verschiedenen Testarbeiten. Dies kann beispielsweise in Form von Testautomatisierungen oder aber auch Trainings geschehen. Weiterhin hängt die Modelauswahl mit den bereits erwähnten Teststufen zusammen. 15 Der Komponententest kennzeichnet sich durch eine entwicklungsnahe Arbeit. Demnach müssen tiefergehende Fachkenntnisse des Testers für einen guten Test bereitstehen. Modell 1 macht dies möglich, Modell 2 ist bei ausreichend zur Verfügung stehenden Testern möglich. Die bereits genannten Gefahren beim Testen durch Entwickler wurden bereits erläutert. An dieser Stelle ist es jedoch möglich, dass durch die Test-Consultants Testpläne vorgegeben werden sollten und die Testarbeiten zu protokollieren. Mit Ihrem Fachwissen sollten die Consultants darüber hinaus methodisch unterstützen. 16 Die Integration von Komponenten kennzeichnet den Integrationstest zum einen. Dieser kann analog dem Komponententest durchgeführt werden Modell 1 und 2. Gilt es aber, zum anderen, Komponenten zusammenzuführen, kann nicht so verfahren werden. Die Zusammen- 14 Vgl. Linz; Spillner, 2010, S. 173-174. 15 Vgl. Linz; Spillner, 2010, S. 174. 16 Vgl. Linz; Spillner, 2010, S. 174.
7 stellung des Teams sollte gemischt oder durch unabhängige Testteams gestaltet werden. Die Gefahr der Betriebs-Blindheit würde andernfalls sehr hoch sein. Abhängig der zu integrierenden Komponenten und der Projektgröße bieten sich Modell 3-5 an. 17 Abgerundet wird das Testing von dem Systemtest. Dieser steht so nah am Kunden wie keiner der beiden bisher genannten. Funktionalität, Useability, Logik im Prozessablauf prüft dieser Test ab. Es ist zwingend notwendig losgelöst von der Entwicklung zu testen, womit nur Modell 3-5 in Frage kommen. 18,19 Es ist nun bekannt wie ein Testing durchzuführen ist und an welchen Charakteristika sich eine geeignete Modellauswahl festmachen lässt. Im weiteren Teil wird nun auf die explizite Zusammenstellung des Testteams eingegangen. 3.2. Qualifikation des Testteams Umfassende Softwaretestings lassen sich nur durch ein breites Fachwissen der involvierten Tester durchsetzen. Folgende Tabelle zeigt im Überblick die zu besetzenden Rollen im Testprozess und die dazugehörigen Eigenschaften und Aufgaben: 17 Vgl. Linz; Spillner, 2010, S. 174-175. 18 Vgl. Haberl P. u.a., 2012, S. 77. 19 Vgl. Linz; Spillner, 2010, S. 175.
8 Testmanager (Testleiter) Testdesigner (Testanalyst) Wer Experte für Aufgabengebiet (u.a.) Testplanung; Teststeuerung, Qualitäts-, Projektmanagement, Personalführung Testmethoden u. Testspezifikation; Erfahrung in Software-Engineering und Spezifikationsmethoden Testautomatisierer Testautomatisierung Grundlagenwissen; Programmiererfahrung Testadministrator Installation und Betrieb der Testumgebung Tester Testdurchführung Bugreports Bedienung der eingesetzten Tools - Erstellung und Abstimmung des Testkonzeptes - Beschaffung der nötigen Testressourcen - Auswahl u. Einführung von Testwerkzeugen; Trainings - Anpassung, Auswertung und Kommunikation der Testpläne - Review von Requirements - Erstellung von Testdokumentationen - Ermittlung und Aufbereitung von Testdaten Automatisierung der Test mit existierender Toolumgebung - Aufsetzen und betreuen der Testumgebung (mit angrenzenden Fachabteilungen) - Review von Testplänen und fällen - Ausführung und Protokollierung von Tests Tabelle 1: Übersicht Aufgaben und Qualifikation von qualifizierten Mitarbeitern Quelle: Eigene Darstellung in Anlehnung an: Spillner; Linz, S. 176-177. 2010 Neben den hier aufgelisteten fachlichen Kenntnissen und Erfahrungen ist es für jede der aufgelisteten Gruppen wichtig soziale Kompetenzen wie Teamfähigkeit; Exaktheit und vor allem die Fähigkeit, sich schnell in neue Themengebiete einzuarbeiten, zu besitzen. 20 3.3. Testplanung Die Testplanung nimmt im Rahmen des Testings eine der größten Rollen ein. So besser ein- Test geplant und strukturiert aufgebaut ist, desto besser und zielorientierter die Ergebnisse dessen. Ein grober Überblick der Phasen der Testplanung stellt folgende Grafik dar: Qualitätssicherungsplan Testkonzept Priorisierung der Tests Kriterien für Teststart und Testende Abbildung 4: Phasen der Testplanung Quelle: eigene Darstellung; in Anlehnung an Linz; Spillner; S. 178-183. 2010 20 Vgl. Linz; Spillner, 2010, S. 177.
9 Das Testen stellt lediglich ein Teil der Qualitätssicherung dar, denn es wird nie ohne begleitende Maßnahmen, wie beispielsweise ein Lasttest, eingesetzt. Im Qualitätssicherungsplan werden diese Maßnahmen gebündelt. Die Norm IEEE 21 730 setzt sich im Rahmen der Qualitätssicherung mit Software-Qualitätssicherungs-Plänen auseina der. 22 Die Gliederung dieses Planes sieht folgende 16 Punkte vor. 1. Zweck und Anwendungsbereich 2. Referenzierte Dokumente 3. Projektorganisation und Management 4. Dokumentation 5. Standards, Verfahren, Konventionen, Metriken 6. Software-Reviews 7. Softwaretests 8. Problemmelde- und Korrekturverfahren 9. Werkzeuge, Techniken und Methoden 10. Verwaltung der Medien und Datenträger 11. Lieferantenmanagement 12. Qualitätsaufzeichnungen 13. Trainingsmaßnahmen 14. Risikomanagement 15. Glossar 16. Änderungsverfahren und Änderungsverzeichnis Der Detailierungsgrad des Qualitätssicherungsplan bleibt dabei recht grob. Im Rahmen der Testplanung und darauffolgenden Testkonzeptionierung verschärft sich der Detailierungsgrad. 23 3.3.1. Testkonzept Dass das Testen ein umfangreiches Unterfangen darstellt wurde bereits mehrmals dargelegt. Eine der größten Herausforderungen ist somit die Erstellung des Testkonzepts. Wie bereits dargelegt, ist dies die Aufgabe des Testmanagers. Dieser plant so früh wie möglich im Projekt 21 Institute of Electrical and Electronix Engineers. 22 Vgl. Koch, 2003, S. 423. 23 Vgl. Linz; Spillner, 2010, S. 178-179.
10 das Vorgehen des Testings. Weiterhin ist die Aufgabe eine permanente, Testpläne müssen angepasst, Ergebnisse ausgewertet und auf Umwelteinflüsse reagiert werden. Im Rahmen der Testplanungsarbeiten seien fünf besonders wichtige Aufgaben herauszustellen: 1. Festlegung Teststrategie und passenden Testmethoden 2. Koordination und Integration der Testaktivitäten mit anderen Projekt(-test)teilnehmern 3. Erstellung von Vorgaben zur Auswertung, Evaluierung und Überwachung der Testergebnisse und des Testverlaufes 4. Definition der Kriterien für Testende, 5. Schätzung und laufende Aktualisierungen des Testaufwandes und deren Kosten 24 Für den Testmanager ist es wichtig, auch die Nicht-Ziele eines Projektplanes zu definieren. Eine Auflistung der nicht zu testenden Qualitätsmerkmale sowie der Fakten, welche eher der Qualitätssicherung zuzuordnen sind. 25 Die Ergebnisse dessen werden daraufhin im vollständigen Testkonzept festgehalten. Auch dafür hat sich im Rahmen des Testmanagements eine Norm als praxisbewährt bewiesen IEEE829-1998, welche eine Referenzgliederung bereitstellt: 1. Testkonzeptbezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahme- und Testendkriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten/Zuständigkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan/Arbeitsplan 24 Vgl. Linz; Spillner, 2010, S. 179. 25 Vgl. Haberl, P. u.a., 2012, S. 77.
11 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigungen/Frage 26 Diese praxiserprobte Gliederung entwickelt sich über die dargestellte Referenzgliederung hinaus weiter. Es wurde in der weiterführenden Norm IEEE 829-2008 noch der Teststufenplan integriert, dieser unterscheidet zwischen Master Test Plan und `Level Test Plan 27. Auf die Vertiefung dessen wird im Sinne der Hausarbeit nicht weiter eingegangen, die Nennung dient an der Stelle lediglich der Vollständigkeit. 3.3.2. Priorisierung der Tests Da in den seltensten Fällen Projektpläne zu 100% gehalten werden können oder aber auch Testdaten nicht immer im vollem Umfang zur Verfügung stehen werden, ist es von absoluter Wichtigkeit die kritischen Fehler in der Software-Entwicklung zu erörtern. Nachdem die Qualitätssicherungsplanung und die Testkonzeption abgeschlossen ist, ist für den Testmanager nun die Priorisierung der definierten Tests die nächste wichtige Aufgabe. Diese dient dazu, dass die Wichtigsten Testfälle zuerst getestet werden und somit bei einem Abbruch der Testphase die am höchsten priorisierten Testfälle getestet wurden. Folgend wird mit einem Beispiel versucht die Kriterien für die Priorisierung zu erläutern. 1. Nutzungshäufigkeit Erläuterung Beispiel 2. Fehlerrisiko Erläuterung Beispiel 3. Wahrnehmung einer Fehlerwirkung Erläuterung Beispiel 4. In Abhängigkeit der Priorität der Anforderungen Erläuterung Beispiel 5. 26 Vgl. Linz; Spillner, 2010, S. 180. 27 Vgl. Linz; Spillner, 2010, S. 180-181.
12 Erläuterung Beispiel 6. Qualitätsmerkmale Erläuterung Beispiel 7. Priorisierung aus Sicht der Entwicklung oder Systemarchitektur Erläuterung Beispiel 8. Fehlerpriorisierung nach Projektrisiko 28 3.3.3. Kriterien für Teststart und Testende Als letzten Punkt ist nach Abbildung xx zu definieren, wann ein Test startet und wann er endet. Dies ist vor allem wichtig, um beim Teststart zu verhindern, dass durch die Tester bereits mit unvollständigen Testdaten getestet wird und somit Ressourcen unnötig Zeit verschwenden. Anhang folgender Checkliste nach Spillner und Linz lässt sich ein Teststart festmachen: Die Testumgebung ist verfügbar und einsatzbereit. Die Testwerkzeuge sind in der Testumgebung einsatzbereit. Die zu testenden Testobjekte sind in der Testumgebung verfügbar. Die notwendigen Testdaten sind verfügbar. Testendkriterien auf der anderen Seite können bewirken, dass Tests zufällig beendet/abgebrochen werden könnten. Verhindern jedoch auch einen frühzeitigen Abbruch, da das Ende aufgrund von bspw. Ressourcenmangel herbeigeführt wird. Ohne die Erfüllung der Testendkriterien ist ein Ende der Testphase nicht anzuraten. Testendkriterien können dabei sein: Erreichter Testumfang abgedeckte Anforderungen Erreichte Produktqualität Zuverlässlichkeit des Testobjektes Verbleibendes Risiko unvollständige Anforderungen, nicht behobene Defekte Wirtschaftliche Rahmenbedingungen Kostenrahmen, Liefertermine 28 Vgl. Linz; Spillner, 2010, S. 182.
13 Die Testendkriterien sind ebenfalls Teil des Testkonzeptes, welches der Testmanager erstellt. Wie bereits gesagt sind diese Kriterien dem Testverlauf entsprechend anzupassen, da sie dem Test- und Projektmanagement als Entscheidungsgrundlage dienen. 29 3.4. Kosten- und Wirtschaftlichkeitsaspekte Testen hat zwei Primär-Ziele: das erste ist es, Fehler zu finden, damit die Qualität des Software-Produkts durch Korrektur der Fehler erhöht wird. Je früher wir einen Fehler finden, desto größer ist der Nutzen, den wir durch Ersparnis der Fehlerkosten haben. Das zweite Ziel ist es, die Unsicherheit bezüglich der Qualität des Software-Produkts zu minimieren. 30 Die nachfolgende Abbildung zeigt die Beziehung zwischen den Fehlerkosten und den Qualitätskosten. Abbildung 5: Beziehung zwischen Fehlerkosten und Qualitätskosten Quelle: http://qse.ifs.tuwien.ac.at/courses/skriptum/download/06_testen_wid_20031017.pdf, S. 3 Die Aufgabe des Testmanagers ist es, den Punkt zu treffen, wo die Summe von Testkosten und geschätzten Fehlerkosten ein Minimum erreicht. 31 Da die Fehlerkosten nicht genau beziffert, sondern nur geschätzt, werden können, ist in der Abbildung ein ganzer Bereich für das Kostenminimum veranschlagt. In den beiden folgenden Kapiteln werden die Fehler- und Testkosten genauer beschrieben. 29 Vgl. Linz; Spillner, 2010, S. 183. 30 Autor unbekannt: http://qse.ifs.tuwien.ac.at/courses/skriptum/download/06_testen_wid_20031017.pdf (S.3) 31 http://qse.ifs.tuwien.ac.at/courses/skriptum/download/06_testen_wid_20031017.pdf (S.3)
14 3.4.1. Fehlerkosten Aufgrund von eingeschränkten bzw. gar nicht durchgeführten Tests kommt es in der Summe zu mehr unerkannten Fehlerwirkungen und Mängeln. Diese können in der Folge zu den nachfolgend ausgewiesenen Kosten führen. Direkte Fehlerkosten Unter direkten Fehlerkosten werden Kosten verstanden, die direkt durch Fehlerwirkungen beim Einsatz der Software auftreten. Der Hersteller kann für diese Kosten belangt werden. Direkte Fehler können Berechnungsfehler der Software in Form von Datenverlust, Fehlbuchungen oder auch Personenschäden sein. Des Weiteren gehören der Ausfalls von softwaregesteuerten Maschinen, Anlagen oder Geschäftsprozessen sowie das Einspielen neuer Versionen mit einer dafür notwendigen Neueinweisung von Mitarbeitern in diese Fehlerkategorie. Direkte Fehler können aufgrund des daraus resultierenden hohen Aufwands der Beseitigung in Form des Einspielens einer neuen Version bei allen bestehenden Kunden sehr hohe Kosten verursachen. Nichtsdestotrotz denken die meisten Unternehmen nicht an diese eventuell auftretenden Kosten. Indirekte Fehlerkosten Indirekte Fehlerkosten entstehen aufgrund einer Unzufriedenheit des Kunden. Für den Softwarehersteller bedeutet dies zusätzliche Kosten bzw. Umsatzverlust. In die Kategorie indirekte Fehlerkosten fallen Vertragsstrafen oder Minderungen wegen eines nicht erfüllten Vertrages, Imageschaden des Herstellers und im schlimmsten Fall der Verlust der Marktzulassung. Auch der erhöhte Aufwand einer eventuell im Einsatz befindlichen Kundenhotline und des Supports kann in diesem Zusammenhang genannt werden.
15 Fehlerkorrekturkosten Unter Fehlerkorrekturkosten werden alle Kosten zusammengefasst, die bei der Korrektur von aufgetretenen Fehlern auf Seiten des Herstellers entstehen. Dazu zählen folgende Komponenten: Zeit für Fehleranalyse und Korrektur Zeit für Regressionstest, erneute Auslieferung und Installation, Nachschulung des Kunden Verzug bei Neuprodukten wegen Bindung der Entwicklerkapazität Sinkende Konkurrenzfähigkeit Der Testmanager kann nur sehr schwer ermitteln, in welcher Wahrscheinlichkeit und in welcher Höhe die einzelnen zuvor beschriebenen Kostenarten eintreffen. Das Fehlerkostenrisiko ist abhängig von - der Art und der Größe des Softwareproduktes, - der Art und der Branche des Kunden (Vertragsgestaltung, gesetzliche Rahmenbedingungen), - der Art und der Anzahl auftretender Ausfälle und - der Anzahl der betroffenen Produktinstallationen bzw. Endanwender. Vorteilhaft ist es, eine projektspezifische Risikoanalyse durchzuführen, um besser auf die speziellen Gegebenheiten bei einem Projekt bzw. Kunden eingehen zu können. Abbildung 6: Kosten eines Fehlers in Abhängigkeit von der Phase, in der der Fehler gemacht, und der Phase, in der entdeckt wurde Quelle: http://qse.ifs.tuwien.ac.at/courses/skriptum/download/06_testen_wid_20031017.pdf, S. 2
16 Abbildung 6 zeigt die Kosten eines Fehlers in Abhängigkeit von der Phase, in der der Fehler gemacht wurde, und der Phase, in der er entdeckt wurde. Da die Fehlerkosten über die Entwicklungsphasen ansteigen, ist es wichtig, einen Fehler frühzeitig zu erkennen. - Ein Fehler, der sehr früh entsteht, kann, solange er unentdeckt bleibt, in den anschließenden Entwicklungsphasen viele Folgefehler produzieren. - Je später ein Fehler entdeckt wird, umso mehr Korrekturen sind notwendig. Unter Umständen müssen vorangegangene Phasen zumindest teilweise wiederholt werden. 32 3.4.2. Testkosten Um eine Aussagekraft bezüglich der Testkosten machen zu können, muss sich der Testmanager mit den Einflussfaktoren auseinandersetzen, die bei der Aufwandsabschätzung von Tests eine Rolle spielen können. Nachfolgend sind die Einflussfaktoren inklusive Beispielen dargestellt: 32 Spillner, A.; Linz, T., 2010, S.185.
17 Einflussfaktor Beispiele Reifegrad des Entwicklungsprozesses - Stabilität der Organisation - Fehlerhäufigkeit der Entwickler - Rate der Softwareänderungen - Zeitdruck durch unrealistische Pläne - Gültigkeit, Bestand und Aussagekraft von Plänen - Reife des Testprozesses und Disziplin bei Konfigurations-, Änderungs- und Fehlermanagement Qualität und Testbarkeit - Anzahl, Schwere und Verteilung der Fehler der Software - Qualität, Aussagekraft und Aktualität der Dokumentation und anderer testrelevanter Informationen - Größe und Art der Software und Systemumgebung - Komplexität der Anwendungsdomäne und der Software Testinfrastruktur - Verfügbarkeit von Testwerkzeugen - Verfügbarkeit von Testumgebung und Testinfrastruktur - Verfügbarkeit und Bekanntheit von Testprozess, Standards und Verfahren Mitarbeiterqualifikation - Erfahrung und Know-how der Tester bzgl. Testen - Erfahrung und Know-how der Tester bzgl. Testwerkzeugen und umgebung - Erfahrung und Know-how der Tester bzgl. Testobjekt - Zusammenarbeit Tester Entwickler Management Kunde Qualitätsziele - Angestrebte Testabdeckung - Angestrebte Testfehlerrate bzw. Zuverlässigkeit nach dem Test - Anforderungen an die Systemsicherheit - Anforderungen an die Testdokumentation Teststrategie - Testziele und Mittel zur Zielerreichung - Wahl der Testmethoden - Zeitliche Planung der Tests Tabelle 2: Testkostenbeeinflussende Faktoren
Der Testmanager hat nur auf einzelne Faktoren direkten Einfluss. Dieser Einfluss wird in der nachfolgenden Tabelle aufgezeigt: 18 Einflussfaktor Reifegrad des Entwicklungsprozesses Qualität und Testbarkeit der Software Testinfrastruktur Mitarbeiterqualifikation Qualitätsziele Einfluss des Testmanagers Langfristige Beeinflussbarkeit durch ein Prozessverbesserungsprogramm Langfristige Beeinflussbarkeit durch ein Prozessverbesserungsprogramm Mittelfristig beeinflussbar durch gezielten Ausbau der Testinfrastruktur Kurzfristig bedingt beeinflussbar durch Auswahl des Testpersonals Bedingt beeinflussbar durch Priorisierung Teststrategie Frei wählbar und dadurch einzige Stellgröße Tabelle 3: Einfluss des Testmanagers auf die Faktoren 3.4.3. Schätzung des Testaufwands Um mit der Erstellung eines Zeitplanes und mit dem Anfordern von Testressourcen beginnen zu können, muss der Testmanager den tatsächlichen Testaufwand einschätzen. Hierfür gibt es zwei grundsätzliche Herangehensweisen, die nachfolgend kurz erläutert werden. 1. Der Aufwand der Testaufgaben wird für jede Aufgabe separat geschätzt. Die Schätzung wird durch den Tester selbst oder durch einen Experten mit einer entsprechenden Schätzerfahrung durchgeführt werden. 2. Bei der zweiten Herangehensweise wird der Aufwand aus bereits bekannten Aufwandsdaten oder ähnlichen Projekte hinzugezogen. Zusätzlich spielen hierbei typische Kennzahlen (z.b. im Mittel durchgeführte Testfälle pro Stunde) eine bedeutende Rolle. Die erste Herangehensweise ist stark von den in Kapitel 3.3.2 dargestellten Einflussfaktoren abhängig. Durch die wechselseitige Abhängigkeit der einzelnen Faktoren ist es fast unmöglich, eine vollständige Analyse aller Faktoren vorzunehmen. Der aufgabenorientierte Ansatz tendiert zumeist dazu, den Testaufwand zu unterschätzen. Deutlich realistischere Prognosen können mit der zweiten Herangehensweise Aufwand basierend auf Erfahrungswerten, ähnlichen Projekten bzw. Kennzahlen gemacht werden. Sollten keinerlei Erfahrungswerte abrufbar sein, kann die nachfolgende Daumenregel heran-
19 gezogen werden: Der Testaufwand in typischen Anwendungsentwicklungsprojekten beträgt etwa 50% der Gesamtentwicklungsaufwänden. 33 3.5. Wahl der Teststrategie Eine Teststrategie definiert die Testziele und die Maßnahmen, die geeignet scheinen, diese zu erreichen. Sie bestimmt damit den Testaufwand und die Testkosten. Mit der Auswahl der Teststrategie trifft der Testmanager eine seiner wichtigsten Entscheidungen. 34 Mit Hilfe der richtigen Teststrategie soll die Relation zwischen Testkosten und den eventuell anfallenden Fehlerkosten verbessert und das allgemeine Risiko so gering wie möglich gehalten werden. 3.5.1. Vorbeugender vs. reaktiver Ansatz Einen großen Einfluss auf die Teststrategie hat der Zeitpunkt, ab dem der Testprozess in den Entwicklungsprozess integriert wird. Nachfolgend werden die beiden verschiedenen Ansätze vorbeugender und reaktiver Ansatz näher erläutert: Vorbeugender Ansatz Bei diesem Ansatz wird der Tester bereits zu Beginn eines Entwicklungsprozesses in das Projekt integriert. Somit wird sichergestellt, dass die Testplanung und das Testdesign zum frühestmöglichen Zeitpunkt beginnen können. Für den Testmanager ergibt die Möglichkeit, optimierend und kostenreduzierend in das Entwicklungsprojekt einzugreifen. Durch den zeitigen Einstieg in das Projekt können Fehler frühzeitig erkannt und auch behoben werden. Als Grundlage dienen hierfür eine frühzeitige Testspezifikationen, Reviews und statische Analysetechniken. Der vorbeugende Ansatz kann durchaus bei der Entwicklung von sicherheitskritischen Anwendungen verpflichtend sein. Reaktiver Ansatz Beim reaktiven Ansatz werden Tester sowie die Testplanung und der Testentwurf erst nach der Fertigstellung des Softwaresystems in das Projekt integriert. Eine vorbeugende Herangehensweise ist bei der Verwendung dieses Ansatzes nicht möglich. 33 Spillner, A.; Linz, T., 2010, S.188. 34 Spillner, A.; Linz, T., 2010, S.188.
20 3.5.2. Analytischer vs. heuristischer Ansatz Der Testmanager kann bei der Auswahl und Planung von Tests auf unterschiedliche Informationsquellen zurückgreifen. Dies betrifft zum Einen Daten und deren Analyse und zum Anderen Erfahrungswissen. Es gibt daher die beiden nachfolgend thematisierten Herangehensweisen: Analytischer Ansatz: Beim analytischen Ansatz werden Daten und deren mathematische Analyse als Grundlage für die Testplanung genutzt. Die Einflussfaktoren (siehe Testkosten) müssen durch den Testmanager sondiert und ihr wechselseitiger Zusammenhang modelliert werden. Durch die Wahl von Testumfang und Intensität hat der Testmanager weiterhin die Aufgabe einzelne oder mehrere Parameter, wie z.b. Kosten, Zeitbedarf und Testabdeckung, zu optimieren. Heuristischer Ansatz: Aufgrund von nicht verfügbaren Daten (fehlendes Know-how bzw. aufwendige Modellbildungen) stützt sich der heuristische Ansatz im Gegensatz zum analytischen Ansatz auf Erfahrungswerten und Daumenregeln. Die in der Praxis üblichen Herangehensweisen liegen zwischen den beiden Extremen und nutzen analytische und heuristische Elemente:
21 Herangehensweise Modellbasiertes Testen Statistisches (modellbasiertes Testen) Risikoorientiertes Testen Prozess- oder standardkonforme Ansätze Wiederverwendungsorientierter Ansatz Beschreibung Nutzen von abstrakten funktionalen Modellen des Testobjekts zur Ableitung von Testfällen, zur Definition von Testendkriterien und zur Messung der Testabdeckung Heranziehen von statistischen Modellen über Verteilung von Defekten im Testobjekt, über Ausfallraten im Betrieb der Software oder über die statistische Verteilung von Anwendungsfällen sowie Festlegen einer entsprechenden Verteilung der Testaktivitäten und Auswahl der Testmethoden Nutzen von Informationen über Projekt- und Produktrisiken und Festlegen des Testschwerpunktes auf Bereiche hohen Risikos Nutzen von Handlungsanweisungen oder Empfehlungen Übernahme von vorhandenen Tests und Testumgebungen aus früheren Projekten Ziel: schnelle Tests Checklistenorientierter Ansatz Nutzen von Fehlerlisten aus früheren Testzyklen, Listen potenzieller Fehler oder Risiken oder priorisierter Qualitätskriterien und anderer weniger formeller Methoden Expertenorientierter Ansatz Nutzen von Expertisen und des Bauchgefühls beteiligter Experten Tabelle 4: Herangehensweisen - analytischer vs. heuristischer Ansatz 3.5.3. Testen und Risiko Risiko kennzeichnet die Eventualität aus, dass mit einer (ggf. niedrigen, ggf. auch unbekannten) Wahrscheinlichkeit ein (ggf. hoher, ggf. in seinem Ausmaß unbekannter) Schaden bei einer (wirtschaftlichen) Entscheidung eintreten oder ein erwarteter Vorteil ausbleiben kann. 35 Schaden beinhaltet dabei alle [ ] Konsequenzen und Kosten einer Fehlfunktion des Produkts. 36 Risikofaktoren, die für die Wahl der Teststrategie herangezogen werden sollten, können aus dem Entwicklungsprojekt oder aus dem Produkt resultieren. 35 http://wirtschaftslexikon.gabler.de/definition/risiko.html 36 Spillner, A.; Linz, T., 2010, S.191.
22 Projektrisiken Unter Projektrisiken werden Risiken verstanden, die die Auslieferung des Produktes in Gefahr bringen. Risiko Beispiel Lieferantenseitige Risiken - Ausfall des Unterauftragsnehmers - Vertragsstreitigkeiten - Verzögerungen im Projektverlauf - Gerichtliche Auseinandersetzungen Organisationsbezogene Risiken - Ressourcenknappheit - Zwischenmenschliche Probleme - Interne machtpolitische Rangeleien Technische Probleme - Falsche, unvollständige, missverständliche, unrealisierbare Anforderungen - Einsatz neuer Technologien, Werkzeuge, Programmiersprachen oder Methoden ohne ausreichend Erfahrungen - Schlechte Qualität oder Mängel von Zwischenergebnissen - Zu späte Bereitstellung von Testumgebung oder unzureichende Testdaten Tabelle 5: Projektrisiken Produktrisiken Unter Produktrisiken werden Risiken verstanden, die direkt mit Problemen des Produktes in Zusammenhang stehen. Dazu zählen: - Unzureichende Produkteigenschaften in funktionaler und/oder nicht funktionaler Hinsicht; schlecht Qualität, der zu verarbeitenden Daten - Produkt erfüllt nicht den geforderten Einsatzzweck = unbrauchbar - Einsatz führt zu Schäden an Geräten oder zur Gefährdung von Menschenleben Durch permanentes Testen wird das strategische Risikomanagement unterstützt und auf vorhandene Probleme sowie Erfolg oder Misserfolg der Problembehebung hingewiesen. Durch ein gutes Testmanagement kann sich der Testmanager einen Überblick über die even-
tuell auftretenden Risiken machen. Auch hier wird zwischen zwei Herangehensweisen unterschieden. 23 Risikobasiertes Testen Risikobasiertes Testen hilft, Produktrisiken gezielt zu mindern und zu bekämpfen, und zwar vom Beginn des Projektes an. 37 Es werden Informationen über identifizierte Risiken für die Planung, Spezifikation, Vorbereitung und Durchführung der Tests genutzt. Risikoorientierte Testpriorisierung Mit Hilfe einer risikoorientierten Testpriorisierung werden risikoreiche Produktteile in den Mittelpunkt des Testprozesses gestellt. Diese klar definierten Produktteile werden durch die Priorisierung intensiver und früher getestet. Dadurch können schwerwiegende Fehler frühzeitig entdeckt und behoben werden. 3.6. Management der Testarbeiten Je nach Literatur und Definition werden für den Testprozess zwischen 30-50% der Entwicklungskosten aufgewandt. Dieser hohe Anteil macht es zwingend erforderlich, dass der Test strategisch geplant und durchgeführt werden muss. 38 Da ein Testprozess während der Durchführung zyklisch abläuft, z.b. durch das wiederholte Testen von verschiedenen Softwareteilen nach der Beseitigung von Fehlern oder der Änderung von Code-Funktionalitäten, müssen auch diese Zyklen geplant und gemanagt werden. Dies ist die Aufgabe des Testmanagers. 39 Im Folgenden werden die einzelnen Phasen eines Testzyklus detailliert beschrieben. 40 3.6.1. Testzyklusplanung Als Ergänzung zu der initialen Grobplanung des gesamten Testprozess ist es Aufgabe des Testmanagers für den anstehenden Testzyklus eine Feinplanung durchzuführen. Diese Planungen müssen im Verlauf stetig an die aktuelle Projektsituation angepasst werden. Zu berücksichtigen sind dabei folgenden Einflüsse: 41 37 Spillner, A.; Linz, T., 2010, S.193. 38 Vgl. Grechenig, T. u.a., 2009, S.337. 39 Eine detaillierte Aufgabenbeschreibung des Testmanagers erfolgte bereits in Kapitel 3.1 Testorganisation 40 Vgl. Spillner, A.; Linz, T., 2010, S.193. 41 Vgl. Spillner, A.; Linz, T., 2010, S.194.
24 Entwicklungsstand Weicht die verfügbare Software zu Beginn des Zyklus von der ursprünglichen Planung ab, resultiert daraus unter Umständen eine Anpassung der Testspezifikationen oder der Testfälle. Gründe hierfür können eine eingeschränkte Funktionalität der zu testenden Software, falls erst einzelne Teile ausprogrammiert wurden, oder eine veränderte Funktionalität der Software, falls es Änderungen der Anforderungen im Verlauf des Entwicklungsprozesses gab, sein. Testergebnisse Werden während eines Testzyklus Fehler in der zu testenden Software gefunden, hat dies unmittelbare Folgen für die sich anschließenden Testzyklen. Unter Umständen müssen Testfälle nach der Korrektur der Fehler erneut getestet werden oder, je nach Schwere des Fehlers, um priorisiert werden. Zusätzlich können neue Testfälle entstehen, um die Beseitigung von Fehlern zu prüfen oder auch um die Fehler zu reproduzieren bzw. zu analysieren. All dies muss in die Feinplanungen der nächsten Zyklen eingearbeitet werden. Ressourcen Die Planung des Testzyklus muss stets mit den verfügbaren Ressourcen abgeglichen sein. Besonders bei der Anpassung der Planungen durch neue Gegebenheiten (neue bzw. zusätzliche Testfälle, Umpriorisierung von Testfälle usw.) muss darauf geachtet werden, dass die benötigten Ressourcen (Personal, Testumgebung, Testwerkzeuge) zur Verfügung stehen. Unter Berücksichtigung all dieser Aspekte schätzt der Testmanager den Aufwand und den zeitlichen Bedarf für die durchzuführenden Testarbeiten und erstellt eine detaillierte Feinplanung für den anstehenden Zyklus. Diese beschreibt, welche Testfälle in welcher Reihenfolge von wem durchzuführen sind. Das Ergebnis ist der fertige und dokumentierte Testplan. 42 42 Vgl. Spillner, A.; Linz, T., 2010, S.194.
25 3.6.2. Testzyklusüberwachung Während der Durchführung der einzelnen Testzyklen müssen diese überwacht werden. Hierfür werden objektive und im Vorfeld definierte Testmetriken genutzt. Diese sollen nach Möglichkeit regelmäßig, zuverlässig und einfach zu messen sein. 43 Die folgende Tabelle stellt eine Übersicht oft genutzter Metriken dar und beschreibt die zu messenden Kriterien: Metrik Grundlage für die Messung Fehlerbasiert - Anzahl gefundener Fehlerzustände (pro Testobjekt) im jeweiligen Release bezogen auf die Fehlerklasse und des Fehlerstatus Testfallbasiert - Anzahl der Testfälle in einem bestimmten Status Testobjektbasiert - Codeabdeckung, Dialogabdeckung, abgedeckte Installationsvarianten, Plattformen usw. Kostenbasiert - Aufgelaufene Testkosten, Kosten des nächsten Testzyklus bezogen auf den erwarteten Nutzen 44 Tabelle 6: Metriken im Rahmen der Zyklusüberwachung Aus den ermittelten Kennzahlen erstellt der Testmanager nach jedem Testzyklus einen Teststatusbericht. Dieser enthält u.a. Informationen über den Testfortschritt, Fehlerstatus etc., sodass sich ableiten lässt, wie weit der Test vorangeschritten ist. Zusätzlich kann eine Einschätzung gegeben werden, ob der Test rechtzeitig abgeschlossen werden kann. 45 Durch eine engmaschige Erhebung dieser Metriken, deren Auswertung und die je nach Lage erfolgende Anpassung des Testplans entsteht final ein geschlossener Regelkreis der zu einer bestmöglichen Transparenz und Planung führt. 46 3.6.3. Testzyklussteuerung Falls Verzögerungen gegenüber der Projekt- oder Testplanung auftreten, muss durch entsprechende Maßnahmen gegengesteuert werden. Diese einzuleiten ist ebenso die Aufgabe des Testmanagers. 43 Vgl. Spillner, A.; Linz, T., 2010, S.194. 44 Vgl. Spillner, A.; Linz, T., 2010, S.195. 45 Vgl. Spillner, A.; Linz, T., 2010, S. 195. 46 Vgl. Rossner, T. u.a., 2010, S. 26.
26 Im Optimalfall werden bei einem zeitlichen Rückstand gegenüber der ursprünglichen Planung zusätzliche Ressourcen eingeteilt. Oftmals stehen diese jedoch nicht unmittelbar zur Verfügung, sodass der Testplan angepasst werden muss. So können z.b. Testfälle mit niedriger Priorität gestrichen oder Testfälle in weniger Varianten durchgeführt werden als geplant. Hilft auch das nicht, muss die Zeitplanung angepasst werden und die Testdurchführung verlängert werden, was jedoch unter Umständen die pünktliche Auslieferung des Produktes gefährden kann. Deshalb ist es sehr wichtig, dass jede Änderung dokumentiert sowie kommuniziert wird und dadurch stets Transparenz über den aktuellen Status herrscht. 47 3.7. Fehlermanagement 3.7.1. Fehlermeldung Unter dem Begriff Fehlermanagement werden alle Techniken und Methoden zusammengefasst, welche dazu dienen einen strukturierten Umgang mit Software-Anomalien zu gewährleisten. Darunter fallen alle Auffälligkeiten der Software, die von einzelnen oder mehreren Personen als potenzieller Fehler interpretiert werden. 48 Maßgebend hierfür ist ein erwartetes Soll-Verhalten, welche zu Beginn des Tests definiert wurde, und ein abweichendes IST- Verhalten, welches im Rahmen des Tests identifiziert wird. Da nicht jede Auffälligkeit zwingend einen Fehler darstellt, wird oftmals auch von Anomalie oder Problem gesprochen. Letztere Begriffe sind deutlich neutraler in der Formulierung und führen nicht zu einer sofortigen unterbewussten Schuldzuweisung. 49,50 Um im Rahmen des Testens die auftretenden Probleme bzw. Anomalien strukturiert zu erfassen und zu verwalten, wird im Regelfall eine Fehlerdatenbank eingerichtet. Innerhalb dieser werden alle Meldungen dokumentiert. Beteiligte Personen können auf diese Datenbank zugreifen und die gewünschten Daten erfassen oder abrufen, wie in Abbildung 7 dargestellt. 47 Vgl. Spillner, A.; Linz, T., 2010, S. 196f. 48 Vgl. Hoffmann, D. W., 2008, S. 477. 49 Vgl. Spillner, A.; Linz, T., 2010, S. 198. 50 Vgl. Hoffmann, D. W., 2008, S. 477.
27 Damit die Fehlermeldungen standardisiert abgelegt und ausgewertet werden können, muss jede Meldung nach einem einheitlichen Schema abgelegt werden, welches vom Testmanager definiert wird. Dieses Schema enthält alle relevanten Information, die zur Beschreibung, Reproduktion und Lokalisierung des Problems notwendig sind. 51 Die Angaben werden dafür zumeist in die folgenden 3 Kategorien eingeteilt: - Identifikationsmerkmale (z.b. Identifikationsnummer, Name des Testobjektes, Erfassungszeitpunkt, Ersteller usw.) Abbildung 7: Typischer Aufbau einer Fehlerdatenbank Quelle: Hoffmann, D. W., 2008, S. 478. - Klassifikationsmerkmale (z.b. Priorität, Status, Klasse usw.) - Beschreibungsmerkmale (z.b. Testfall, Problembeschreibung usw.) 52 3.7.2. Fehlerklassifikation Um ein gemeldetes Problem richtig beurteilen zu können und darauf aufbauend die richtigen Schritte abzuleiten, ist es wichtig, die Schwere und die Priorität zu bestimmen. Die Schwere beschreibt dabei wie groß die Auswirkungen Schönheitsfehler vs. Systemabsturz - eines Problems sind. Bei der Beurteilung ist stets darauf zu achten, dass diese aus der Sicht des Anwenders bzw. des späteren Nutzers erfolgt. Im Rahmen des Testmanagements sollten im Vorfeld einheitliche Fehlerklassen definiert werden, in welche jedes Problem einsortiert werden kann. 53 51 Vgl. Spillner, A.; Linz, T., 2010, S. 199. 52 Vgl. Hoffmann, D. W., 2008, S. 479. 53 Vgl. Spillner, A.; Linz, T., 2010, S. 200f.
28 Die Priorität eines Fehlers beschreibt wie schnell ein Mangel behoben werden muss. Hier gehen in die Bewertung Anforderungen an den Korrekturaufwand oder die weitere Testdurchführung mit ein. Wie bei der Klassifizierung der Fehlerschwere sollten auch für die Beschreibung der Priorität im Vorfeld einheitliche Kategorien festgelegt werden, sodass jede Fehlermeldung standardisiert bewertet werden kann. 54 Mit Hilfe der Klassifizierung der Fehlerschwere und -priorität wird es letztlich dem Testmanager ermöglicht, Aussagen über den aktuellen Stand und vor allem die Entwicklung des Testprozesses zu treffen. Er kann genau erkennen, in welchen Testobjekten, welche Fehlerkategorien auftreten, Trends ableiten und somit die weiteren Tests steuern. 55 3.7.3. Fehlerstatus Wurde ein Fehler erkannt und dokumentiert, durchläuft dieser ein standardisiertes Stufenmodell, welches, analog der Klassifizierungsstufen für Schwere und Priorität, im Vorfeld definiert wird. Auf diese Weise ist es jederzeit möglich zu erkennen, in welchem Status sich die Korrektur bzw. Abarbeitung des Fehlers befindet und in wessen Verantwortlichkeit der aktuelle Prozessschritt liegt. Abbildung 8 zeigt exemplarisch ein Statusmodell inklusive der jeweiligen verantwortlichen Personen. Wurde eine neue Meldung vom Tester eingestellt, entscheidet NEU (Tester) zunächst der Testmanager, ob das Problem zur Analyse an den Entwickler geht, abgewiesen wird oder zur Beobachtung gekennzeichnet wird. BEOB: (Entwickler) OFFEN (Testmanager) ABGEW (Testmanager) Wird der Fehler zum Entwickler zur Analyse weitergereicht, kann dieser den Fehler entweder abweisen, falls ANALYSE (Entwickler) er der Meinung ist, dass kein Defekt vorliegt, oder im Anschluss an die Fehleranalyse korrigieren. Wurde der KORREKTUR (Entwickler) Defekt korrigiert, ist es Aufgabe des 54 Vgl. Spillner, A.; Linz, T., 2010, S. 200ff. 55 Vgl. Spillner, A.; Linz, T., 2010, S. 201. FLOP (Tester) TEST (Entwickler) ERLEDIGT (Tester) Abbildung 8: Fehlerstatusmodell In Anlehnung an: Vgl. Spillner, A.; Linz, T., 2010, S.203.
29 Testers durch entsprechende Nachtests dies zu validieren und im Optimalfall den Fehler als erledigt zu kennzeichnen. Wurde der Fehler seiner Meinung nach nicht behoben, so ist es erneut Aufgabe des Entwicklers dies zu analysieren. Das dargestellte Statusmodell ist sehr generisch formuliert und auf nahezu jede Projektumgebung übertragbar. Wichtig ist, dass es stets an die im konkreten Projekt vorherrschenden Gegebenheiten angepasst wird. So werden beispielsweise Entscheidungsprozesse häufig nicht durch Einzelpersonen sondern Gremien getroffen, was unter Umständen die Komplexität erhöht und zusätzliche Prozessschritte nach sich zieht. 56 3.8. Konfigurationsmanagement Für das Konfigurationsmanagement ergeben sich nachfolgende Anforderungen: Anforderungen Beschreibung Versionenverwaltung - Katalogisieren, Speichern und Wiederabrufen von unterschiedlichen Versionen eines Konfigurationsobjektes - Mitführen von Kommentaren, aus denen der jeweilige Änderungsgrund hervorgeht Konfigurationsverwaltung - Bestimmen und Verwalten aller Dateien in der jeweils passenden Version, die zusammen ein Teilsystem bilden Statusverfolgung von Fehlern - Aufzeichnen von Problemberichten und Änderungsanforderungen und Änderungen und die Möglichkeit, deren Umsetzung an den Konfigurati- onsobjekten nachzuvollziehen Durchführen von Konfigurationsauditnagement - Prüfen, ob alle Softwarebausteine vom Konfigurationsma- erfasst werden bzw. ob die Konfiguration korrekt identifiziert werden können Tabelle 7: Anforderungen an das Konfigurationsmanagement 56 Vgl. Spillner, A.; Linz, T., 2010, S. 204.
30 3.9. Relevante Normen und Standards Eine weitere Aufgabe des Testmanagers ist die Fertigstellung von relevanten Normen, Standards und Richtlinien für das zu testende Produkt oder Projekt und deren Sicherstellung. 57 Der Testmanager bedient sich dabei den nachfolgenden Quellen: Quelle Firmenstandards Best Practices Qualitätsmanagementstandards Branchenstandards Beispiel Firmeninterne Richtlinien und Verfahrensanweisungen Nicht standardisierte, aber fachlich bewährte Vorgehensweisen und Verfahren, die den Stand der Technik darstellen Branchenübergreifende Standards (z.b. ISO9000) Branchenstandards [DIN 60601-1-4] für Medizinprodukte [RTC-DO 178] für Software in Flugzeugen [EN 50128] für Bahn-Signalsysteme Softwarestandards Prozessstandards (produktunabhängig) [BS 7925-2] [IEEE 829] [IEEE 1028] Tabelle 8: Übersicht Normen und Standards 4. Outsourcing als Möglichkeit der Optimierung Im folgenden Kapital wird das Outsourcing von Testmanagement-Aktivitäten als Alternative zum reinen In-House-Testen vorgestellt. Neben der Beschreibung der Hintergründe und Ziele des Outsourcings soll vor allem auf die aktuelle Verbreitung und die Kernaspekte für eine erfolgreiche Zusammenarbeit zwischen Auftraggeber und Dienstleister eingegangen werden. Grundlage für die Beschreibung dieser Themen ist u.a. die Studie Wachstumsmarkt Software-Testing - Markttrends, Dienstleister und Erfolgsfaktoren, welche im Juni 2011 durch die Pierre Audoin Consultants GmbH, im Auftrag der SQS Software Quality Systems AG, durchgeführt wurde. Im Rahmen dieser Studie wurden 309 Führungskräfte und IT- Entscheider von Unternehmen aller Branchen aus Europa und Nordamerika mit einer Mindestgröße von 1.000 Mitarbeitern und einem IT-Team bestehend aus mindestens 100 Mitarbeitern befragt. 58 57 58 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 5.
31 4.1. Ziele und Hintergründe des Outsourcings Über den gesamten Softwarelebenszyklus hinweg sind Testarbeiten durchzuführen und eng mit den Entwicklungsarbeiten abzustimmen und zu koordinieren. Es muss genau definiert werden, welche Rolle von welchen Personen umgesetzt wird. Um dies effizient und effektiv umzusetzen, haben sich unterschiedliche Modelle etabliert. Eine Variante ist beispielsweise die Durchführung der Testarbeiten durch die Entwickler selbst, wobei jedoch die bereits in Kapitel 3.1 angesprochene Blindheit der Entwickler gegenüber den eigenen Fehlhandlungen ein gewisses Fehlerpotential birgt. Eine weitere Variante ist der Aufbau einer separaten Testorganisation. Eigens für das Testen eingesetztes Personal führt die Tests durch und ist dabei oft objektiver und hinterfragt kritischer (mehr zum Thema Testorganisation unter 3.1.). 59 Sind die hierfür notwendigen Ressourcen für ein qualifiziertes Testmanagement firmenintern nicht vorhanden oder können diese nur mit sehr großem finanziellen Aufwand realisiert werden, kann dies bedeuten, dass das Testen zu wenig oder keine Priorität erhält und folglich zu spät startet, was die Fehlerfindungskosten erhöhen kann. 60 In diesem Fall bietet es sich an, Aufträge an entsprechende Testdienstleister auszulagern. Diese haben oft große Erfahrungen im Bereich des Software- Testens, schlüsselfertige Vorgehensweisen und können den für den speziellen Fall optimalen Testbetrieb sehr schnell aufsetzen. Je nach Wunsch des Auftragsgebers können theoretisch sämtliche Rollen, wie Testmanager, Testdesigner, Testautomatisierer usw., durch den externen Dienstleister besetzt werden. 61 Da das Testen oftmals als lästige Nebenbeschäftigung wahrgenommen wird, können sich dadurch die eigenen Mitarbeiter stärker auf wichtige Kernthemen konzentrieren. 62 Gerade in Projektspitzen wird die Entlastung des eigenen Personals als Vorteil angesehen. 63 Entscheidet sich ein Unternehmen für eine Auslagerung von Testaktivitäten ist ein breites Spektrum zwischen einer gelegentlichen Zusammenarbeit und einer dauerhaften Kooperation möglich. Die Ziele, vor allem bei einer mehrjährigen Zusammenarbeit, sind zumeist die Optimierung und Standardisierung der Testprozesse, die Erhöhung des Testautomatisie- 59 Vgl. Spillner, A.; Linz, T., 2010, S.173f. 60 Vgl. Grechenig, T. u.a., 2009, S.344. 61 Vgl. Spillner, A.; Linz, T., 2010, S. 178. 62 Vgl. Grechenig, T. u.a., 2009, S. 345. 63 Vgl. König, A., 2010.
32 rungsgrads sowie die Anwendung durchgängiger, erprobter Methoden, Best-Practices und geeigneter Testing-Tools. 64 Zudem zeigt die PAC-Studie, dass 85% der Befragten, durch die Zusammenarbeit mit einem Dienstleiter ihre Kosten senken konnten. 65 Schätzungen zufolge sind Einsparungen von 25 % und mehr möglich. 66 An dieser Stelle ist es wichtig, dass die Unternehmen ihre Kosten kennen und somit einen Vergleich herstellen können. Eine Vielzahl von Unternehmen kann, bei einem reinen In-House-Testen, seine Kosten nicht exakt ermitteln und zuordnen, da kein standardisierter Testprozess etabliert ist. 67 Des Weiteren zeigt die PAC- Studie, dass bei einer Vielzahl der Befragten die Testzeiten deutlich verringert und gleichzeitig die Flexibilität erhöht werden kann. 68 Abbildung 9 zeigt zusammenfassend die Ergebnisse der Studie bezüglich der Vorteile und Ziele des Outsourcings. Abbildung 9: Vorteile im Software-Testing durch die Zusammenarbeit mit externen Spezialisten Quelle: Pierre Audoin Consultants GmbH, 2011, S. 11. 64 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 10. 65 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 11. 66 Vgl. Capgemini, 2009, S. 3. 67 Vgl. Grechenig, T. u.a., 2009, S. 344. 68 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 10.
33 4.2. Aktuelle Verbreitung Nach dem die Ziele und Hintergründe beschrieben worden sind, stellt sich die Frage, wie sich das Outsourcing in der Praxis bereits etabliert hat. 66 % der befragten Unternehmen gaben hierbei an, dass sie bereits mit einem externen Dienstleister im Rahmen des Testmanagements zusammenarbeiten. Jedoch ist auch zu erkennen, dass lediglich ein kleiner Teil (3%) der befragten Unternehmen wirklich alle Testaktivitäten auslagert. Über die Hälfte der befragten Unternehmen arbeitet derzeit noch gar nicht bzw. nicht regelmäßig mit externen Dienstleistern zusammen, was zeigt, dass an dieser Stelle noch sehr viel Potential steckt. Abbildung 10 Abbildung 10: Organisation der Testaktivitäten Quelle: Pierre Audoin Consultants GmbH, 2011, S. 10. fasst die Aufteilung zwischen internen und externen Tätigkeiten als Ergebnis der Befragung zusammen. 69 Trotzdem kommt PAC zu dem Ergebnis, dass das Interesse an der Auslagerung von Testaktivitäten sehr groß ist, vor allem für Unternehmen, die sich auf Kernkompetenzen konzentrieren wollen und die eigene IT innovativ sein lassen wollen. Die Möglichkeit, durch die Einbindung eines professionellen Dienstleisters eine hohe Qualität bei gleichzeitiger Steigerung der Effizienz und Effektivität im Testing zu erzielen, lässt das Testing zu einem der weltweit am schnellsten wachsenden Bereiche innerhalb der IT-Services werden. Bereits 30 Milliarden Euro wurden Schätzungen zufolge in 2011 für Testing-Services ausgeben. Besonders längerfristige Testing-Engagements in Form von Managed-Test-Services-Partnerschaften, basierend auf klar definierten Service Level Agreements, nehmen dabei einen immer höher wer- 69 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 10.
34 den Stellenwert mit jährlichen zweistelligen Wachstumsraten ein. 70 Andere Untersuchungen sehen in diesem Bereich sogar Wachstumsraten von 50 % und mehr. 71 Die Gründe für die steigende Nachfrage nach vor allem längerfristigen Vereinbarungen basiert laut PAC auf 3 Trends: - Die Bedeutung des qualitätsorientierten Software-Test- und Qualitätsmanagements ist mit zunehmender Komplexität in IT und Testing gestiegen. - Die langfristige Zusammenarbeit mit externen Dienstleistern ist bei Unternehmen, welche ihre Testorganisation und durchführung verbessern, sollen sowieso hoch im Kurs. - Strategische Überlegungen gewinnen zunehmend an Bedeutung. 72 Ein weiterer Grund für die Zunahme der Zusammenarbeit mit spezialisierten Partnern im Rahmen von Software-Testing ist die Tatsache, dass die Kunden immer öfter unabhängige Tests der Anwendungslandschaft fordern. 73 Eine weitere Studie aus dem deutschsprachigen Raum von Mai 2011, welche in Kooperation der Hochschulen Bremen und Bremerhaven, der Fachhochschule Köln, der ANECON Software Design und Beratung G.m.b.H., dem German Testing Board e.v. (GTB) und dem Swiss Testing Board (STB) durchgeführt worden ist, zeigt eine deutliche geringere Verbreitung. Als Ergebnis gaben nur 15% der befragten Unternehmen an, externe Dienstleister für die Testdurchführung einzusetzen. 74 Auch kommt diese Studie dem Ergebnis, dass kein Trend für die Verlagerung von Testaktivitäten zu externen Dienstleistern erkennbar ist, da nur zu geringen Teilen Berater und Anbieter von Testdienstleistungen mit der Durchführung von Tests betraut werden. 75 Somit bleibt zusammenfassend abzuwarten, wie sich der Trend wirklich in der Praxis entwickelt. 70 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 9. 71 Vgl. Capgemini, 2009, S. 3. 72 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 9. 73 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 12. 74 Vgl. Haberl, P. u.a., 2012, S. 15. 75 Vgl. Haberl, P. u.a., 2012, S. 33.
35 4.3. Auswahlkriterien und Aspekte für eine erfolgreiche Zusammenarbeit Schon im Auswahlprozess eines externen Dienstleisters ist es wichtig, die Entscheidung auf Basis vordefinierter Kriterien zu treffen. Besondern wenn der Fokus auf eine mehrmalige und mehrjährige Zusammenarbeit gelegt wird, gilt es DEN geeignetsten Anbieter auszuwählen. Abbildung 11 zeigt die im Rahmen der PAC-Studie ermittelten Anforderungen und Auswahlkriterien. Deutlich zu erkennen ist dabei, dass Themen wie die Kernkompetenz im Testen, eine hohe Qualitätsorientierung und Branchenkenntnis des Dienstleisters sehr wichtig sind. Abbildung 11: Priorisierte Kompetenzen der Testing-Dienstleister Quelle: Pierre Audoin Consultants GmbH, 2011, S. 21. Hat sich ein Unternehmen entschieden Bereiche seines Testmanagements auszulagern, stellt sich die Frage, was letztlich zu einem erfolgreichen Zusammenarbeiten zwischen Auftraggeber und Dienstleister führt. Die folgenden Punkte werden dabei als wichtige Kriterien angesehen: - Schnelligkeit und Flexibilität der Testing-Aktivitäten - Enge Abstimmung und sehr gute Kommunikation zwischen Auftraggeber und Dienstleister (sofortiges und direktes Feedback) - Fachliche Kompetenz des Dienstleisters
- Regelmäßige Erfolgsmessung durch entsprechende KPIs und Abrechnung auf Basis von tatsächlichen Ergebnissen wichtig 76 36 Jedoch zeigt die Studie auch, dass besonders das Aufsetzen eines geeigneten Kennzahlensystems noch nicht flächendeckend etabliert ist. Wie Abbildung 12 verdeutlicht, hat lediglich ein Viertel der Unternehmen, welche bereits externe Dienstleistungen in Anspruch nehmen, detaillierte KPIs zur Erfolgsmessung etabliert. Abbildung 12: Aspekte zur Messung der Zielerreichung des Testing-Teams Quelle: Pierre Audoin Consultants GmbH, 2011, S. 18. Zusammenfassend kann gesagt werden, dass für ein erfolgreiches Zusammenarbeiten folgende Faktoren wichtig sind: - Auswahl des geeigneten Delivery Modells - eine serviceorientierte Organisation des Kunden-Lieferanten-Verhältnisses - praktikable Service Level Agreements und - die Festlegung messbarer Ziele. 77 76 Vgl. Pierre Audoin Consultants GmbH, 2011, S. 17ff. 77 Vgl. König, A., 2010.
5. Fallbeispiel 37 Zwei Beispiele aus dem beruflichen Alltag der Studenten 6. Fazit - It compiles! Let s ship it! - - Verfasser unbekannt - Doch kann Software ohne ausführliche Tests veröffentlicht werden? Die Antwort auf diese Frage kann ganz klar mit einem Nein beantwortet werden. Die Anforderungen an ein intensives Testmanagement steigen zunehmend. Ziel der vorliegenden Arbeit war es aufzuzeigen, welche Managementtätigkeiten im Rahmen des Testens notwendig sind, neben dem Test selbst. Software begleitet uns heutzutage nahezu im gesamten Alltag und nimmt einen größer werden Stellenwert ein. Schon kleinste Fehler können schwerwiegenden Folgen, sei es finanzieller oder auch menschengefährdender Art sein. Beispiele wie der Komplettausfall der Telefonanlage in den USA 1991 belegen dies eindrucksvoll. Zudem führen Gründe wie die stetige Kostenoptimierung, Prozessoptimierung und standardisierung sowie die Erwartungshaltung des Kunden einer immer schnelleren Auslieferung der Software dazu, dass das Testen gut geplant und gemanagt werden muss. Aspekte, wie den Aufbau der Testorganisation, die Planung und Steuerung des Tests aber auch ein effizientes Fehler- und Konfigurationsmanagement gilt es zu bewältigen und effizient umzusetzen. Als Alternative für die reine In- House-Durchführung dieser Aufgaben wurde das Outsourcing von Testmanagement vorgestellt. Spezielle Dienstleister bieten flexible Lösungen, bezogen auf die Dauer aber auch auf die Aufgaben, an und können die Firmen unterstützen und entlasten. Besonders für Firmen die nicht primär auf Softwareentwicklung als Kernkompetenz setzen oder ihre eigenen Ressourcen lieber für innovative Arbeiten einsetzen bietet das Outsourcing interessante Möglichkeiten. Ob sich dieser Trend in der Praxis durchsetzen wird und die derzeit starken Wachstumsraten in diesem Dienstleistungsbereich anhalten, werden die nächsten Jahre zeigen. Abschließend sollten die beiden dargestellten Fallbeispiele zeigen, wie sehr Theorie und Praxis noch auseinander liegen können. Oftmals sind aus Zeit- oder Kostengründen noch keine standardisierten Prozesse und Vorgehensweise aufgesetzt.
V. Literaturverzeichnis 38 Fachliteratur: Grechenig, T.; Bernhart, M.; Breiteneder, R.; Kappel, K. (2009): Softwaretechnik Mit Fallbeispielen aus realen Entwicklungsprojekten. 1. Aufl. München: Person Studium. Haberl, P.; Spillner, A.; Vosseberg, K.; Winter, M. (2012): Umfrage 2011: Softwaretest in der Praxis. 1. Aufl. Heidelberg: dpunkt.verlag GmbH. Hoffmann, D. W. (2008): Software-Qualität. 1. Aufl. Berlin, Heidelberg: Springer Verlag. Rossner, T.; Brandes, C.; Götz, H.; Winter, M. (2010): Basiswissen Modellbasierter Test. 1. Aufl. Heidelberg: dpunkt.verlag GmbH. Wiender, L. (1994): Digitales Verhängnis: Gefahren der Abhängigkeit von Computern und Programmen. 1. Auflage. Addison-Wesley. Autor Unbekannt: http://qse.ifs.tuwien.ac.at/courses/skriptum/download/ 06_testen_wid_ 20031017.pdf Studien: Capgemini (2009): Softwaretest, die letzte Outsourcing-Domäne, verfügbar unter: http://www.sogeti.de/fileadmin/user_upload/buecher/sogeti- Gti_Flyer_whitepaper_091113 2 D.pdf (letzter Zugriff: 29. Oktober 2012). König, A. (2010): Wie Outsourcing von Software-Tests funktioniert, verfügbar unter: http://www.cio.de/knowledgecenter/outsourcing/2216976/index2.html (letzter Zugriff: 29. Oktober 2012). Pierre Audoin Consultants GmbH (2011): Wachstumsmarkt Software-Testing Markttrends, Dienstleister und Erfolgsfaktoren, verfügbar unter: http://ict-researchboard.de/files/pac_positioning_paper_testing_final_de_110608.pdf (letzter Zugriff: 29. Oktober 2012). Autor Unbekannt: http://wirtschaftslexikon.gabler.de/definition/risiko.html; (letzter Zugriff: 23. Oktober 2012). Internetquellen: Autor unbekannt: Softwarefehler im historischen Ablauf, Quelle: Softwarefehler im historischen Ablauf, Quelle: http://www.certitudo-gmbh.de/g_geschichte.html; 28.10.2012 Autor unbekannt: http://www.ferchau.de/news/archiv/details/idc-studie-vieleunternehmen-sind-testmuffel-1082/; 18.10.2012
39 VI. Ehrenwörtliche Erklärung Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Es wurden keine anderen als die angegebenen Stellen und Hinweise verwandt. Alle Quellen, die dem World Wide Web entnommen oder in einer sonstigen digitalen Form verwendet wurden, sind der Arbeit beigefügt. Der Durchführung einer elektronischen Plagiatsprüfung stimme ich hiermit zu. Die eingereichte Datei entspricht der eingereichten Druckfassung. Die vorliegende Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Julia Volkmer, Michael Zschintzsch, Sebastian Ballert Berlin, den 18.11.2012
VII. Anhang 40 Anhang 1: Prozessuale Sicht auf die Kernbereiche der IT-Governance... Fehler! Textmarke nicht definiert.