Einführung von Testsoftware im IT-Bereich
Diplomarbeit, 2004, 161 Seiten
i
1 Einleitung 1
2 Definitionen 5
3 Was ist Testen 11
3.1 Definition Qualität 11
3.2 Definition Testen 12
3.3 Warum testen 12
3.4 Das V-Modell 13
3.5 Relative Kosten der Fehlerbehebung 15
4 Automatisiertes Testen 17
4.1 Definition: Automatisiertes Testen 17
4.2 Wann ist Testautomatisierung sinnvoll 17
4.3 Anwendungsgebiete von Testautomatisierung 18
4.4 Warum automatisiertes Testen 19
4.5 Praxis 19
5 Automatisierte oder manuelle Tests 21
5.1 Standards für das Design automatisierter Tests 22
5.1.1 Wann sollte das Design erfolgen? 22
5.1.2 Was sollte entworfen werden? 23
5.1.3 Wie erstellt man ein Design? 23
5.1.4 Modularität der Testfälle 23
5.1.5 Unabhängigkeit von Testfällen 24
5.1.6 Skriptsprache 24
5.1.7 Datenbanken von Testwerkzeugen 25
5.1.8 Vorlagen für Testfälle 25
5.1.9 Namenskonventionen 25
5.2 Standards für das Design manueller Tests 25
5.2.1 Namenskonventionen 25
5.2.2 Detailliertheit des Testfalls 25
5.2.3 Erwartetes Ergebnis 26
5.3 Wann rentiert sich Testautomatisierung? 26
5.4 Beispiel: Unterschied manueller und automatisierter Test 27
5.4.1 Feststellen des Aufwands für Testautomatisierung 27
5.4.2 Schätzung der reinen Ausführungszeit 28
5.4.3 Erstellen einer Schätzung für folgende Voraussetzungen 28
5.4.4 Berechnen des möglichen Zeitgewinns 28
5.4.5 Schätzen der Kosten und des Nutzens eines Tools 29
5.4.6 Erstellen eines vollständigen Kosten-Nutzen-Vergleichs 30
ii
6 Kosten-Nutzen-Analyse 31
6.1 Erfassung der Kosten des Qualitätsmanagements 31
6.1.1 Grundproblematik der Kostenerfassung 31
6.1.1.1 Isolierte Qualitätsaktivitäten: 31
6.1.1.2 Integrierte Qualitätsaktivitäten: 32
6.2 Erfassung des Nutzens des Qualitätsmanagements 33
6.2.1 Grundproblematik der Nutzenerfassung 33
6.2.2 Erfassung des internen Nutzens 33
6.2.3 Erfassung des externen Nutzens 34
6.3 Einflüsse bei der Berücksichtigung des Nutzens 34
6.4 Bewertung in der Kosten-Nutzen- Matrix für Geschäftsfälle 35
6.5 Projektsteuerung mit Hilfe des Kosten-Nutzen-Koeffizienten 36
6.6 Veränderungen der Kosten-Nutzen-Matrix im Projektverlauf 37
6.7 ROI Berechnung: 38
6.7.1 Klassische ROI Analyse 39
6.7.2 Arten um den Nutzen von Funktionstests zu berechnen 39
6.7.3 ROI für einen einzelnen Testfall berechnen 40
6.7.4 Gesamtzahl von Probeläufen kalkulieren 41
6.7.5 Kombination von ROI für einen einzelnen Testfall und Anzahl der
Testl äufe 42
6.7.6 Berechnen von ROI für mehrere Testskripts 42
6.8 Praxis 43
6.9 Conclusio 43
7 Entscheidung zur Automatisierung 44
7.1 Allgemeine Erwartungen an automatisierte Tests 44
7.2 Mögliche Erwartungen, die das Testwerkzeug nicht erfüllt 44
7.2.1 Automatische Erstellung des Testplans 45
7.2.2 Automatische Erstellung der Testfälle 45
7.2.3 Es gibt ein ultimatives Testwerkzeug 45
7.2.4 Unmittelbare Verringerung des Testaufwands 45
7.2.5 Unmittelbare Verkürzung des Zeitplans 45
7.2.6 Benutzerfreundlichkeit des Testwerkzeugs 46
7.2.7 Automatisierung ist universell einsetzbar 46
7.2.8 Erreichung einer 100 igen Testcoverage 46
7.2.9 Testautomatisierung findet mehr Fehler als manuelle Tests 47
7.3 Probleme beim Automatisieren 47
7.3.1 Unrealistische Erwartungen 47
7.3.2 Schlechte manuelle Tests 47
7.3.3 Wiederverwendbarkeit und Adaptierbarkeit der Tests 47
iii
7.3.4 Technische Probleme 48
7.3.5 Organisatorische Probleme 48
7.4 Vorteile automatisierter Tests 48
7.4.1 Erstellung eines zuverlässigen Systems 49
7.4.2 Verbesserung der Testqualität 49
7.4.3 Reduzierung des Testaufwands und des Zeitplans 49
7.4.4 Vermeidung von Qualitätseinbrüchen bei einer neuen Lieferung 50
7.5 Unterstützung durch die Geschäftsführung 50
7.6 Zeitrahmen 51
7.7 Risiken in der Entscheidungsphase 51
7.8 Praxis 51
7.9 Conclusio 52
8 Auswahl des Testwerkzeugs 53
8.1 Anforderungen 55
8.1.1 Umgebung 55
8.1.2 Welche Probleme im Testprozess sollen gelöst werden? 55
8.1.3 Herausfinden von möglichen Lösungen 55
8.1.3.1 Manuelle Testprobleme 56
8.1.3.2 Keine Zeit für Regressionstests 56
8.1.3.3 Fehleranfälligkeit beim Erstellen von Testdaten und Testfällen 56
8.1.3.4 Mangelhafte Testdokumentation 56
8.1.4 Richtige Zeit für die Einführung 57
8.1.5 Wie viel Hilfe bringt das Testwerkzeug? 57
8.2 Beschränkungen 57
8.2.1 Hardware und Software 58
8.2.2 Einschränkungen des Anbieters 58
8.2.3 Kosteneinschränkung 59
8.2.4 Politische Einschränkung 59
8.2.5 Qualitätseinschränkung 60
8.3 Selbst entwickeln oder kaufen? 60
8.4 Bewertungskriterien 61
8.5 Marktübersicht 62
8.5.1 Mercury Interactive: 62
8.5.2 Rational: 63
8.5.3 Compuware: 63
8.5.4 Segue Software: 63
8.6 Welche Werkzeuge gibt es? 64
8.6.1 Testmanagement: 64
8.6.2 Capture-Replay: 65
iv
8.6.3 Fehlermanagement: 65
8.6.4 Load-Tests: 66
8.6.5 Testfallgeneratoren: 66
8.6.6 Testdatengeneratoren: 67
8.6.7 Wartungskosten: 67
8.6.8 Vermietung von Software: 68
8.6.9 Überblick Anbieter: 68
8.7 Entscheidungsprozess 68
8.7.1 Vorauswahl 69
8.7.2 Produktpräsentationen 69
8.7.3 Auswahl 69
8.8 Pilotprojekt 69
8.9 Schulung 70
8.10 Zeitrahmen 70
8.11 Risiken in der Auswahlphase 70
8.12 Praxis 71
8.13 Conclusio 72
9 Einführung des automatisierten Testens 73
9.1 Analyse des Testprozesses 74
9.1.1 Analyse des bestehenden Prozesses 75
9.1.2 Testziele definieren 76
9.1.3 Teststrategien implementieren 77
9.1.3.1 Strategien zur Fehlervermeidung 78
9.1.3.2 Strategien zur Fehlererkennung 78
9.2 Überlegungen zum Testwerkzeug 79
9.2.1 Überprüfung der Systemanforderungen 79
9.2.2 Überprüfung des Projektzeitplans 79
9.2.3 Vorführung des Werkzeugs für das Projektteam, Umgang mit den
Erfahrungen 80
9.2.4 Überblick über die zu testende Anwendung 80
9.2.5 Rollen und Verantwortlichkeiten 80
9.2.6 Schulungsanforderungen 81
9.3 Projektteam 81
9.3.1 Struktur des Testteams 82
9.3.1.1 Durchgangs-Testteam 82
9.3.1.2 Zentrales Testteam 82
9.3.1.3 UVV-Testteam (Unabhängiges Verifizieren und Validieren) 82
9.3.1.4 SMT-Testteam (System Methodology and Test) 83
9.3.2 Umfang des Testaufwands 83
9.3.2.1 Testreife Ebene 1 (Performed): 84
v
9.3.2.2 Testreife Ebene 2 (Managed): 84
9.3.2.3 Testreife Ebene 3 (Defined): 85
9.3.2.4 Testreife Ebene 4 (Quantitatively Managed): 85
9.3.2.5 Testreife Ebene 5 (Optimizing): 85
9.3.3 Bestimmung der Testteamgröße 85
9.3.4 Faktoren mit Einfluss auf den Testaufwand 86
9.3.5 Wichtigste Eigenschaften von Testingenieuren 87
9.3.6 Rollen und Verantwortlichkeiten im Testteam 87
9.4 Intern oder extern ? 89
9.5 Zeitrahmen 90
9.6 Risiken in der Einführungsphase 90
9.7 Praxis 90
9.8 Conclusio 90
10 Planung, Design und Entwicklung von Tests 92
10.1 Testplanung 92
10.1.1 Testplanungsaktivitäten 93
10.1.2 Anwendungsbereich der Tests 94
10.1.3 Testanforderungsmanagement 95
10.1.4 Beurteilen der Risiken von Testanforderungen 96
10.1.5 Prioritäten festlegen 96
10.1.6 Ereignisse, Aktivitäten und Dokumentation des Testprozesses 97
10.1.6.1 Ereignisse: 97
10.1.6.2 Aktivitäten: 97
10.1.6.3 Dokumentation: 97
10.1.7 Testumgebung 98
10.1.7.1 Vorbereitung der Testumgebung 98
10.1.7.2 Integration und Einrichtung der Testumgebung 99
10.1.8 Dokumentation des Testplans 100
10.1.9 Kriterien für die Akzeptanz der Testergebnisse 100
10.2 Testanalyse und -design 101
10.2.1 Analyse der Testanforderungen 102
10.2.2 Testdesign 103
10.2.2.1 White-Box-Techniken: 104
10.2.2.2 Black-Box-Techniken: 104
10.2.3 Testfälle entwerfen 105
10.2.3.1 Definition von Testfällen: 105
10.3 Entwicklung von Tests 106
10.3.1 Entwicklungsarchitektur für Tests 107
10.3.2 Richtlinien für das Entwickeln von Testfällen 107
10.3.3 Automatisierungsinfrastruktur 108
10.3.4 Testdaten 109
vi
10.4 Zeitrahmen 109
10.5 Risiken in der Planungs-, Design- und Entwicklungsphase 109
10.6 Praxis 109
10.7 Conclusio 110
11 Ausführen und Verwalten von automatisierten Tests 112
11.1 Durchführung und Bewertung der Testphasen 112
11.2 Fehlerverfolgung 112
11.3 Verfolgung des Testfortschritts, Testabdeckung und Qualität des
Testablaufs 114
11.4 Zeitrahmen 114
11.5 Risiken in der Ausführungs- und Verwaltungsphase 115
11.6 Praxis 115
11.7 Conclusio 115
12 Bewertung und Verbesserung des Testprozesses 117
12.1 Korrektur- und Verbesserungsmaßnahmen 117
12.2 Bewertung der Tests 118
12.3 Zeitrahmen 118
12.4 Risiken in der Bewertungsphase 118
12.5 Praxis 119
12.6 Conclusio 119
13 Leitfaden 120
13.1 Vorbedingungen 120
13.1.1 Tätigkeiten: 120
13.2 Entscheidungsphase 121
13.2.1 Tätigkeiten: 121
13.2.2 Zeitrahmen: (Kapitel 7.6) 121
13.2.3 Risiken: (Kapitel 7.7) 121
13.2.4 Möglichkeiten: 121
13.3 Auswahlphase 122
13.3.1 Tätigkeiten: 122
13.3.2 Zeitrahmen: (Kapitel 8.10) 122
13.3.3 Risiken: (Kapitel 8.11) 123
13.3.4 Wichtig: 123
13.3.5 Auswahl des Testwerkzeugs: 124
13.4 Einführungsphase 125
vii
13.4.1 Tätigkeiten: 125
13.4.2 Zeitrahmen: (Kapitel 9.5) 125
13.4.3 Risiken: (Kapitel 9.6) 125
13.4.4 Wichtig: 126
13.4.5 Möglichkeiten: 126
13.5 Planungs-, Design- und Entwicklungsphase 127
13.5.1 Tätigkeiten: 127
13.5.2 Zeitrahmen: (Kapitel 10.4) 127
13.5.3 Risiken: (Kapitel 10.5) 127
13.5.4 Wichtig: 127
13.6 Durchführungsphase 129
13.6.1 Tätigkeiten: 129
13.6.2 Zeitrahmen: (Kapitel 11.4) 129
13.6.3 Risiken: (Kapitel 11.5) 129
13.6.4 Wichtig: 129
13.7 Bewertungsphase 131
13.7.1 Tätigkeiten: 131
13.7.2 Zeitrahmen: (Kapitel 12.3) 131
13.7.3 Risiken: (Kapitel 12.4) 131
13.7.4 Wichtig: 131
13.7.5 Möglichkeiten: 131
13.8 Projektplan 132
14 Conclusio 133
15 Quellen I
15.1 Literaturverzeichnis I
15.1.1 Bücher I
15.1.2 Präsentationen II
15.1.3 Zeitschriften III
15.1.4 Internet IV
15.1.5 Produktbeschreibungen V
15.2 Interviews VII
16 Anhang VIII
16.1 Beispiel VIII
16.1.1 Entscheidungsphase VIII
16.1.2 Auswahlphase VIII
16.1.3 Einführungsphase VIII
16.1.4 Planungs-, Design- und Entwicklungsphase IX
16.1.5 Durchführungsphase X
16.1.6 Wartungsarbeiten XI
16.1.7 Conclusio XI
viii
16.2 Zusammenfassung der Interviews XII
16.2.1 Allgemein: XII
16.2.2 An Anwender gestellte Fragen: XII
16.2.3 An Anbieter gestellte Fragen: XIV
16.3 Abbildungsverzeichnis XVI
1 Einleitung
Software wird immer komplexer, Terminvorgaben und Qualitätsansprüche steigen. Allerdings herrscht durch den Kostendruck Ressourcenknappheit. Dies wiederum wirkt sich auf die Qualität der Software aus, weil Unternehmen zumeist im Qualitätsmanagement sparen.
Die Grundparameter eines Projekts umfassen Leistung, Zeit und Einsatzmittel. Balzert leitet aus diesen Parametern die drei wesentlichen Anforderungen an jegliche industrielle Entwicklung ab: Funktionstreue, Termintreue und Kostentreue. In der Software-Entwicklung kommt zu diesen drei Parametern oft eine vierte Größe, die Qualität des Software-Produktes, hinzu. 1 Diese vier Zielsetzungen werden als Teufelsquadrat (Abbildung 1) bezeichnet: „Sie konkurrieren um eine begrenzte Kapazität und Produktivität eines Betriebes, die durch das innere Viereck dargestellt werden“ 2 und verhalten sich wie vier Parameter in einer quadratischen Gleichung mit jeweils zwei unabhängigen und zwei abhängigen Variablen.
Abbildung 1. Teufelsquadrat 3
Aus Zeit und Kosten ergeben sich beispielsweise Funktionsumfang und Qualität. Zwischen Funktionsumfang und Qualität besteht allerdings ein Zielkonflikt: je
1 Vgl. Sneed, H. : SW-Management, Köln, R. Müller Verlag, 1987, S. 42.
2 Sneed (1987), S. 170.
3 Sneed (1987), S. 171.
größer der Software-Umfang bei gleichbleibender Produktivität ist, desto geringer ist die Qualität.
Ziel der Arbeit ist es, die Aspekte der Einführung und des Betreibens von Testautomatisierungs-Verfahren in einem IT-Unternehmen aus organisatorischer und betriebswirtschaftlicher Sicht zu untersuchen. Darüber hinaus soll sie einen Leitfaden (Kapitel 13) für Unternehmen darstellen, die eine Testsoftware in ihrem Unternehmen einführen wollen. Die Arbeit beinhaltet alle Phasen der Einführung von Testsoftware von der Entscheidung zur Testautomatisierung bis hin zur Analyse der Testergebnisse, ohne jedoch auf das manuelle Testen einzugehen.
Des weiteren sucht die vorliegende Arbeit nach Gründen für den relativ geringen Verbreitungsgrad von Testautomatisierung in der IT-Industrie. Speziell wird hier auf die Frage eingegangen, warum Testautomatisierung auf der einen Seite eingeführte Praxis ist, jedoch auf der anderen Seite nach zaghaften Versuchen oft scheitert. Dann wird eine Vorgehensweise bei der Einführung und dem Betrieb von Testautomatisierung vorgestellt. Diese beruht auf Erkenntnissen über die Erfolgsfaktoren bei Testautomatisierung, die auf Erfahrungen verschiedener Firmen mit Testautomatisierung basieren.
Die Verfahren zur Testautomatisierung haben zwar in letzter Zeit einen hohen Reifegrad erreicht, werden aber in großem Stil nur in sicherheitsrelevanten Bereichen z.B. der Medizin- und Verkehrstechnik eingesetzt. Kurze Entwicklungszyklen und ungenau definierte Anforderungen stellen die größten Hindernisse bei der erfolgreichen Einführung von Testautomatisierung in frühen Entwicklungsphasen dar.
Testautomatisierung ermöglicht es zwar den Testzyklus zu verkürzen und gleichzeitig zu verbessern, erfordert jedoch eine Investition, deren Umfang von Faktoren wie der Art der durchgeführten Tests, der Anzahl der erwarteten
Änderungen der Applikation (GUI und System) und der Eignung der Tools für einen bestimmten Testprozess abhängig ist.
Zu diesem Thema habe ich Experten verschiedener Firmen nach ihren Erfahrungen mit Testautomatisierung befragt, um Argumente für und wider Testautomatisierung zu sammeln. Zu diesen Experten gehören Hersteller und Anwender von Testsoftware bzw. Consulting Unternehmen die Unterstützung bei der Einführung bieten. Diese Erfahrungsberichte sollen dem Leser Aufschlüsse über die Schwierigkeiten, Gefahren, aber auch über die Vorzüge der Automatisierung von Tests bringen. Insbesondere wird auf die Kosten- / Nutzen-Aspekte eingegangen. Dies ermöglicht dem Leser die Probleme und Schwierigkeiten, die auf ihn und sein Projekt zukommen, schon vor dem Auftreten zu erkennen und diesen gezielt entgegenzusteuern.
Meine Erfahrungen zu dem Thema sind zweigeteilt. Auf der einen Seite sind diese sehr positiv, da der Stellenwert vom Testen in den letzten Jahren gestiegen ist und die Unternehmen in den Kauf von Testsoftware investieren, da sie erkannt haben, welche Vorteile Testautomatisierung bringt. Auf der anderen Seite planen die Unternehmen immer noch zu wenig die Einführung der Testsoftware, so dass Testautomatisierung nicht effizient genug arbeiten kann. Außerdem sind die Erwartungen an Testsoftware zumeist unrealistisch.
Die Arbeit gliedert sich in folgende Abschnitte: Kapitel 3 handelt vom Testen im Allgemeinen. Es beinhaltet die Definitionen für Qualität und Testen und erklärt warum und wie man testet. Zusätzlich beschreibt es wie wichtig die frühe Fehlererkennung ist. Kapitel 4 beschäftigt sich mit dem Thema automatisiertes Testen. Kapitel 5 vergleicht manuelles und automatisiertes Testen. Das sechste Kapitel liefert die Theorie zur Kosten-Nutzen-Analyse des Qualitätsmanagements und Testautomatisierung sowie ein Beispiel zur Berechung des ROI.
Ab dem Kapitel 7 beginnen die Phasen der Einführung von Testsoftware. Kapitel 7 beschäftigt sich mit der Entscheidung zur Testautomatisierung. Kapitel 8 beantwortet die Frage nach der Auswahl des Testwerkzeugs. Kapitel 9 beschreibt die Einführung des zuvor ausgewählten Testwerkzeugs. Nach der Einführung folgt die Planungs-, Design- und Entwicklungsphase, die im Kapitel 10 näher besprochen wird. Kapitel 11 beschreibt die Ausführungsphase. Die Bewertungsphase bildet die letzte Phase bei der Einführung von Testsoftware, die im Kapitel 12 genauer beleuchtet wird. Ausserdem beinhaltet die Arbeit noch eine Zusammenfassung (Kapitel 14), einen Leitfaden (Kapitel 13) und ein Beispiel der Kosten einer Einführung (Kapitel 15). Dieses Beispiel soll eine Idee geben, wie viel die Einführung in der Praxis kostet.
2 Definitionen
„Abnahmetest: Der von dem oder den künftigen Anwender(n) und Verwaltern in einer möglichst „produktionsnahen“ Umgebung ausgeführte Test, mit dem nachgewiesen werden soll, dass das entwickelte System den funktionalen und qualitativen Anforderungen entspricht.“ 1
„Anwendung (engl. application): Unter einer Anwendung versteht man jegliche Art von Software, die auf einem Rechner oder Rechnersystem läuft und dem Nutzer bei der Bewältigung bestimmter Aufgaben hilft.“ 2
„Black-Box-Testtechnik: Eine Kategorie von Testtechniken bei denen Testfälle, ohne Kenntnisse des internen Konzepts eines Objekts, von den extern sichtbaren Eigenschaften eines Objekts abgeleitet werden.“ 3
„Codierung: Der Vorgang des Umsetzens von Zeichen von einem Code in einen anderen Code, wobei sich die Bedeutung der Zeichen nicht ändert.“ 4
„Coverage / Deckungsgrad: Das Verhältnis zwischen dem, was getestet werden kann (Anzahl möglicher Testziele), und dem, was getestet wird; der Deckungsgrad wird häufig in Beziehung zum Programmcode angegeben, ist aber auch für funktionale Spezifikationen möglich.“ 5
„Debugging: Als Debugging wird das Testen bezeichnet, bei dem die Ursache eines Fehlers lokalisiert, die Folgen der Korrektur geprüft und die Korrektur durchgeführt wird.“ 6
„Fehler: Ein Fehler ist die Abweichung zwischen dem berechneten, beobachteten oder gemessenen Wert oder einem Zustand der Betrachtungseinheit und dem entsprechenden spezifizierten oder theoretisch richtigen Wert.“ 7
1 Pol, Martin / Koomen, Tim / Spillner, Andreas : Management und Optimierung des Testprozesses, 1.A., Heidelberg,
dpunkt.verlag, 2000, S. 523.
2 Net-Lexikon: http://www.net-lexikon.de (13.04.2004)
3 Pol / Koomen / Spillner (2000), S. 523.
4 Heinrich, Lutz / Heinzl, Armin / Roithmayr, Friedrich : Wirtschaftsinformatik, 7.A., München / Wien, R. Oldenbourg Verlag,
2004, S. 151.
5 Pol / Koomen / Spillner (2000), S. 524.
6 Heinrich / Heinzl / Roithmayr (2004), S. 662.
7 Wallmüller, Ernest : Software-Qualitätsmanagement in der Praxis, München, Hanser, 2001, S. 441.
Funktionstest / Funktionaler Test: „Dynamischer Test, bei dem die Testfälle unter Verwendung der funktionalen Spezifikation des Testobjekts hergeleitet werden und die Vollständigkeit der Prüfung (Überdeckungsgrad) anhand der funktionalen Spezifikation bewertet werden.“ 1
GUI: (graphical user interface) Grafische Benutzeroberfläche 2
„Implementierung: Unter Implementierung oder Implementation versteht man das Hinzufügen von Funktionen, Software, Hardware usw. in eine schon vorhandene Anwendung, ein Programm oder einen Computer.“ 3
„Integration: Im allg. Sprachgebrauch die Herstellung oder Wiederherstellung eines Ganzen durch Vereinigen oder Verbinden logisch zusammengehörender Teile.“ 4
„Integrationstest: Test mit dem Ziel, Fehlerwirkungen in Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten zu finden.“ 5
„Intranet: Ein Netzwerk für die Organisation und den Austausch von Informationen und die Durchführung digitalisierter Geschäftstransaktionen innerhalb eines Unternehmens. Ein Intranet nutzt mit dem Internet verwandte Anwendungen, wie Internetseiten, Browser, E- Mails, Newsgroups und Mailing-Listen, die aber nur für die Personen innerhalb der Organisation zugänglich sind.“ 6
Komponententest: Test einer Softwareeinheit 7
Lasttest: Ein Lasttest dient zur „Messung des Systemverhaltens in Abhängigkeit steigender Systemlast (z.B.: Anzahl parallele Benutzer, Anzahl Transaktionen).“ 8
„Metrik: Größe zur Messung einer bestimmten Eigenschaft eines Programms oder einer Komponente. Die Ermittlung von Metriken ist Aufgabe der statischen Analyse.“ 9
1 Spillner, Andreas / Linz, Tilo : Basiswissen Softwaretest, 2. Auflage, Heidelberg, dpunkt.verlag, 2004, S. 203.
2 Spillner / Linz (2004), S. 204.
3 Net-Lexikon: http://www.net-lexikon.de (13.04.2004)
4 Heinrich / Heinzl / Roithmayr (2004), S. 333.
5 Spillner / Linz (2004), S. 204.
6 Gates / Bill : Digitales Business - Wettbewerb im Informationszeitalter, München, Hanser Verlag, 1999.
7 Spillner / Linz (2004), S. 205.
8 Spillner / Linz (2004), S. 206.
9 Spillner / Linz (2004), S. 207.
„Modultest: Ein von einem Entwickler unter Laborbedingungen ausgeführter Test, der nachweisen soll, dass ein Modul (oder eine Einheit) den in den technischen Spezifikationen festgelegten Anforderungen entspricht.“ 1
„Objekt: Im Sinne des objektorientierten Ansatzes die Beschreibung sowohl von physisch existenten Dingen (z.B.: Produkte, Lieferanten, Mitarbeiter, Rechnungen) als auch von Vorgängen, Prozessen, Beziehungen usw., über die Information verfügbar sein muss und deren dynamisches Verhalten von Interesse ist.“ 2
„Opportunitätskosten: Unter Opportunitätskosten versteht man in der Wirtschaftswissenschaft Kosten, die dadurch entstehen, dass Möglichkeiten (Opportunitäten) zur maximalen Nutzung von Ressourcen nicht wahrgenommen wurden.“ 3
„Performanztest (engl. performancetest): Prüfung der
Verarbeitungsgeschwindigkeit bzw. Antwortzeit für bestimmte Anwendungsfälle, in der Regel in Abhängigkeit steigender Last.“ 4
Projekt: „Ein Projekt ist ein zeitlich begrenztes Entwicklungsvorhaben zum Lösen von Problemen innerhalb eines vorgegebenen Zielsystems. Es umfasst die Gesamtheit der für die Problemlösung notwendigen Entwicklungsarbeiten.“ 5
Qualität: (Definition in Kapitel 3.1)
Qualitätsaudit: Ein Qualitätsaudit wird nach den DIN ISO Normen grundsätzlich definiert als “systematische und unabhängige Untersuchung, um festzustellen, ob die qualitätsbezogenen Tätigkeiten und damit zusammenhängenden Ergebnisse den geplanten Anordnungen entsprechen, und ob diese Anordnungen wirkungsvoll verwirklicht und geeignet sind, die Ziele zu erreichen.” 6
1 Pol / Koomen / Spillner (2000), S. 526.
2 Heinrich / Heinzl / Roithmayr (2004), S. 466.
3 Net-Lexikon: http://www.net-lexikon.de (13.04.2004)
4 Spillner / Linz (2004), S. 208.
5 Zehnder, Carl August : Informatik-Projektentwicklung, vdf Hochschulverlag AG, Zürich, 2001, S. 19.
6 Deutsche Gesellschaft für Qualität (1995) S.141.
Qualitätslenkung: Die Qualitätslenkung beinhaltet sämtliche “vorbeugenden, überwachenden und korrigierenden Tätigkeiten bei der Realisierung einer Einheit mit dem Ziel, unter Einsatz von Qualitätstechnik die Qualitätsforderung zu erfüllen”. 1
„Qualitätsmanagement: Alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen, sowie diese durch Mittel der Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen.“ 2
Qualitätsplanung: Als Qualitätsplanung bezeichnet man alle Maßnahmen des “Auswählens, Klassifizierens und Gewichtens der Qualitätsmerkmale sowie eines schrittweisen Konkretisierens aller Einzelforderungen an die Beschaffenheit einer Dienstleistung zu Realisierungsspezifikationen, und zwar im Hinblick auf die durch den Zweck der Einheit gegebenen Erfordernisse, auf die Anspruchsklasse und unter Berücksichtigung der Realisierungsmöglichkeiten.” 3
Qualitätsprüfung: In der Phase der Qualitätsprüfung gilt es für das Unternehmen festzustellen, “inwieweit eine Einheit die Qualitätsforderung erfüllt.” 4
„Qualitätssicherung: Qualitätssicherung ist die Gesamtheit aller geplanten Maßnahmen und Hilfsmittel, die bewusst dazu eingesetzt werden, um die geforderten Anforderungen an den Entwicklungs- und Pflegeprozess und an das Software-Produkt zu erreichen.“ 5
„Quellcode (Code, Sourcecode): Mit Quellcode bezeichnet man den vom Programmierer (bzw. vielen Programmierern) erstellten Programmcode einer Software als editierbare Datei beispielsweise von ASCII-Zeichen.“ 6
1 Deutsche Gesellschaft für Qualität (1995) S.97.
2 Wallmüller (2001), S. 442.
3 Deutsche Gesellschaft für Qualität (1995) S.95.
4 Deutsche Gesellschaft für Qualität (1995) S.108.
5 Wallmüller (2001), S. 443.
6 Net-Lexikon: http://www.net-lexikon.de (13.04.2004)
„Regressionstest: Mit Regression wird das Phänomen bezeichnet, dass sich die Qualität eines Systems infolge individueller Anpassungen verringern kann. Ein Regressionstest zielt darauf ab zu kontrollieren, ob alle Elemente eines Systems nach einer Änderung noch konkret funktionieren.“ 1
„Review: Ein Review ist ein mehr oder weniger formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesem kommentiert oder genehmigt werden.“ 2
„Smoke-Test: In der Regel automatisierter Test, der möglichst alle Hauptfunktionen des Testobjekts auslöst, ohne die Ausgaben des Testobjekts mit vorgegebenen Sollergebnissen zu vergleichen. Stattdessen wird versucht, offensichtliche Fehlerwirkungen des Testobjekts zu erzeugen. Dient vorwiegend zur Prüfung der Robustheit.“ 3
„Software: (engl. Software) ist der Sammelbegriff für die Systemprogramme (engl. system program) und die Anwendungsprogramme (engl. application program; user program) von Rechnern.“ 4
„Softwareentwicklung: Der nicht näher definierte Begriff Softwareentwicklung umschreibt die Prinzipien, Funktionen, Verfahren, Organisationsstrukturen und Werkzeuge, die im Rahmen der Erzeugung von Software zur Verfügung stehen.“ 5
„Software-Test: Ein Software-Test dient der Qualitätssicherung eines neu erstellten oder geänderten Softwareprogramms.“ 6
„Systemtest: Ein Systemtest ist ein von einem Entwickler unter (gut kontrollierbaren) Laufbedingungen ausgeführter Test, der nachweisen soll, dass das entwickelte System oder Teile davon den in den funktionalen und qualitativen Spezifikationen (Fachkonzept und DV-Konzept) festgelegten Anforderungen entspricht.“ 7
1 Pol / Koomen / Spillner (2000), S. 527.
2 Wallmüller (2001), S. 443.
3 Spillner / Linz (2004), S. 210.
4 Hansen, Hans Robert: Wirtschaftsinformatik I, 7.A., Stuttgart: Lucius & Lucius 1996, S.170
5 Net-Lexikon: http://www.net-lexikon.de (13.04.2004)
6 Net-Lexikon: http://www.net-lexikon.de (13.04.2004)
7 Pol / Koomen / Spillner (2000), S. 527.
Testautomatisierung: (Definition in Kapitel 4.1)
Testen: (Definition in Kapitel 3.2)
„Testprozess: Die Sammlung von Aktivitäten, Prozeduren und Hilfsmittel, die zur Durchführung eines Tests erforderlich sind.“ 1
„Testskript: Aufzählung von zusammenhängenden Aktionen und Kontrollen, bezogen auf konkrete Testfälle, deren auszuführende Reihenfolge angegeben ist. Eine Beschreibung dessen, wie zu testen ist.“ 2
„Tool: Als Tool bezeichnet man ein Programm, das für eine bestimmte Aufgabe erstellt wurde.“ 3
„Validierung / Validation: Unter Validierung/Validation verstehen wir die Prüfung und die Bewertung eines Software-Produkts am Ende des Entwicklungsprozesses, um die Übereinstimmung der Produktionsanforderungen mit dem Produkt nachzuweisen.“ 4
„Verifikation: Unter Verifikation verstehen wir Prüfungen und Bewertungen, mit denen die Übereinstimmung von Zwischen- und Endergebnissen einer Phase im Lifecycle mit Ergebnissen der vorangegangenen nachgewiesen wird.“ 5
„Wartung: Die Maßnahmen zur Erhaltung oder Wiederherstellung der Funktionsfähigkeit und Leistungsfähigkeit von Betriebsmitteln ohne grundlegende Änderung von Funktionalität und Leistung.“ 6
„White-Box-Testtechnik: Eine Kategorie von Testtechniken, bei denen Testfälle mit Kenntnissen der internen Struktur des Objekts von den internen Eigenschaften eines Objekts abgeleitet werden.“ 7
1 Pol / Koomen / Spillner (2000), S. 529.
2 Pol / Koomen / Spillner (2000), S. 529.
3 Net-Lexikon: http://www.net-lexikon.de (13.04.2004)
4 Wallmüller (2001), S. 445.
5 Wallmüller (2001), S. 446.
6 Heinrich / Heinzl / Roithmayr (2004), S. 707.
7 Pol / Koomen / Spillner (2000), S. 530.
3 Was ist Testen
Testen ist der Prozess des Vergleichens des Ist-Zustands mit den Anforderungen. Testen von Software im kommerziellen Bereich eingesetzt verbessert die Qualität der Software-Produkte, steigert die Zufriedenheit der Anwender und senkt die Wartungskosten. Im Bereich der Wissenschaft resultiert gutes Testen in genaueren und zuverlässigeren Ergebnissen. Fehlendes oder ineffektives Testen führt logischerweise zu den entgegengesetzten Ergebnissen - schlechtere Qualität der Produkte, Unzufriedenheit der Anwender, höhere Wartungskosten, unzuverlässige und ungenaue Ergebnisse. Aus der folgenden Grafik (Abbildung 2) geht hervor, wie ein Testablauf aussehen kann.
Abbildung 2: Testprozess 1
3.1 Definition Qualität
Nach DIN ISO 8402 bedeutet Qualität (ob positiv oder negativ gesehen) die Gesamtheit von Merkmalen und Merkmalswerten einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. 2
D.h. ob ein Produkt „gute Qualität“ besitzt, entscheidet grundsätzlich allein der Kunde.
1 Spillner / Linz (2004), S. 18.
2 Vgl. Bartsch-Beuerlein, Sandra : Qualitätsmanagement in IT-Projekten, München/Wien, Hanser, 2000, S. 19.
3.2 Definition Testen
Myers hat schon 1989 das Testen von Software definiert:
„Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden.“ 1
Eine etwas neuere Definition von Testen bieten Martin Pol, Tim Koomen und Andreas Spillner:
„Unter Testen versteht man den Prozess des Planens, der Vorbereitung und der Messung, mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen und den Unterschied zwischen dem tatsächlichen und dem erforderlichen Zustand aufzuzeigen.“ 2
3.3 Warum testen
Systematisches Testen von Software stellt, neben verifizierenden Aktivitäten wie z.B. Inspektionen und Reviews, einen wichtigen Beitrag zur Qualitätssicherung der Software-Entwicklung dar. Schlecht oder nicht getestete Software führt im harmlosesten Fall zur Verärgerung des Kunden, im schlimmsten Fall allerdings zu großen Verlusten. „Software muss deswegen im erforderlichen Umfang getestet werden und sollte nicht als notwendiges Übel am Schluss des Entwicklungsprozesses „ad-hoc“ ohne vorherige Planung durchgeführt werden.“ 3
Wenn man die Fehler früher entdeckt, reduzieren sich auch die Kosten für deren Beseitigung (Kapitel 3.5). Zu den schlimmsten Fehlern gehören die, die beim Testen unentdeckt bleiben und deshalb noch existieren, wenn das System „ins Leben hinaustritt“.
1 Myers, G. J. : Methodisches Testen von Programmen, München, Oldenbourg 1989, S. 4.
2 Pol / Koomen / Spillner (2000), S. 9.
3 Einstieg zum Thema Testen: http://www.visek.de/?10759 (01.03.2004).
3.4 Das V-Modell
Je früher man das Testen in den Entwicklungsprozess einbindet, desto besser. Der Integrations- und Systemtest gilt im klassischen Wasserfall-Modell (Abbildung 3) als separate Stufe nach der Implementierung. Dies bedeutet, dass alle diesbezüglichen Aktionen erst bei oder nach der Implementierung beginnen, der Test zum Engpass wird und Synergien in der Entwicklungsphase ungenutzt bleiben.
Abbildung 3: Das Wasserfall-Modell 1
Das V-Modell (Abbildung 4) vermeidet diese Probleme, da es die Testaktivitäten vom ersten Tag an berücksichtigt. 2
Abbildung 4: Das V-Modell 3
1 Spillner / Linz (2004), S. 17.
2 Vgl. Siedersleben, Johannes : Softwaretechnik, 2. Auflage, München / Wien, Carl Hanser Verlag, 2003, S. 290.
3 V-Modell, 1997: Entwicklungsstandard für IT-Systeme des Bundes, Vorgehensmodell, Allgemeiner Umdruck Nr.250/1, BWB
IT 15, Juni 1997
Auf der linken Seite des Modells befinden sich die Phasen von der Anforderungsanalyse bis zur Realisierung des Programms. Auf der rechten Seite steht der dazugehörige Testvorgang. Die strichlierte Linie deutet eine Trennung zwischen den Zuständigkeiten an: Auftraggeber, Anwender, Manager und Rechenzentrum oberhalb der Linie, Systementwickler, Zulieferer und Entwickler unterhalb der Linie. Das Testteam muss feststellen wo die Zuständigkeiten liegen. Zu den Punkten gehört das Feststellen des Auftraggebers für das Testen und wer den Qualitätsbericht einfordert. Jeder Phase stehen eine oder mehrere Testarten gegenüber. 1
Die Durchführungsphasen, in der Grafik als Kästchen dargestellt, bedeuten 40 % des gesamten Aufwands einer solchen Testart. Die Pfeile deuten den Pfad von der Ausgangsdokumentation zur Durchführung des Tests an. 60 % bestehen aus Planungs- und Vorbereitungsaktivitäten, welche abgeschlossen sein müssen, bevor das Testteam mit der Testdurchführung beginnt.
1 Vgl. Pol / Koomen / Spillner (2000), S. 19.
3.5 Relative Kosten der Fehlerbehebung
Abbildung 5: Relative Kosten der Fehlerbeseitigung 1
Das Diagramm (Abbildung 5) zeigt die Wichtigkeit der Spezifikationsphase. Anhand empirischer Daten aus zahlreichen Projekten wurde ermittelt, dass die Kosten für die Beseitigung eines Fehlers exponentiell mit dem Abstand von der Spezifikationsphase steigen. Ein in der Spezifikationsphase entdeckter und behobener Fehler kostete 1,7, ein ähnlicher erst in der Integrationsphase gefundener, Fehler kostete bereits 28, bei einem Auffinden während des Betriebs fallen sogar 170 an. Dies entspricht dem 100fachen der Kosten, die bei frühzeitigem Auffinden und Beheben des Fehlers aufgetreten wären. Hier besteht ein, zumeist nicht genutztes Einsparungspotential.
1 Piesche, Manfred / Muhr Wilfried : Testautomatisierung am Beispiel von Rational Teamtest, TÜV Informationstechnik GmbH
(25.09.2003), S. 5.
Abbildung 6: Fehlerverteilung nach Phasen 1
Die Grafik (Abbildung 6) zeigt deutlich, dass die meisten Fehler (56 %) in der Phase der Anforderungserstellung (engl. requirements) passieren. Nach dieser Phase treten die zweithäufigsten Fehler (27 %) in der Designphase auf. Nur 7 % der Fehler passieren in der Entwicklungsphase.
Dies ergibt ein großes Verbesserungspotential, da das Testteam bisher zu spät in den Entwicklungsprozess eingebunden wurde. Wenn man das Testteam bereits in der Phase der Anforderungserstellung einbindet, besteht die Möglichkeit die Fehler bereits in dieser Phase zu beheben, da es die Anforderungen genau analysieren muss, um Testautomatisierung einzuführen, was weitaus kostengünstiger wäre, als zu einem späteren Zeitpunkt (Abbildung 5).
1 Bender, Richard : The business case for software quality: www.benderrbt.com/Bender-Business Case For Software Quality-
061703-Distribution.pdf (31.03.2004).
4 Automatisiertes Testen
Immer wieder in der Geschichte streben Menschen danach bestimmte Abläufe und Verfahren zu automatisieren, um schneller und rationeller produzieren zu können und dadurch nicht zuletzt Kosten einzusparen. Dies entspricht auch den Grundbedürfnissen im Software-Qualitätsmanagement.
4.1 Definition: Automatisiertes Testen
„Automatisiertes Testen ist die Verwaltung und Durchführung von Testaktivitäten einschließlich der Entwicklung und Ausführung von Testskripts zur Überprüfung der Testanforderungen mit Hilfe eines automatisierten Testwerkzeugs.“ 1
4.2 Wann ist Testautomatisierung sinnvoll
„Testautomatisierung ist dort am sinnvollsten eingesetzt, wenn Testskripts wiederholt oder Subroutinen für Testskripts erstellt und von einer Reihe Testskripts wiederholt aufgerufen werden. Dies zahlt sich besonders während der Entwicklungs-und Integrationsphase aus, wenn wiederverwendbare Skripts sehr häufig ausgeführt werden können.“ 2
In der Praxis wird Testautomatisierung dann als sinnvoll erachtet, wenn das Unternehmen eine stabile Umgebung besitzt und häufig dieselben Tests durchführt. Zu den weiteren sinnvollen Einsatzgebieten zählen Loadtests. Wenn man die Loadtests manuell durchführt, benötigt das Testteam viele Ressourcen. Loadtests können nur automatisiert durchgeführt werden, da man hier viele gleichzeitig agierende User simuliert.
1 Dustin, Elfriede / Rashka, Jeff / Paul, John : Software automatisch testen, Berlin / Heidelberg / New York, Springer, 2001,
S. 4.
2 Dustin / Rashka / Paul (2001), S. 4.
Außerdem können durch Loadtests zeitaufwendige Sequenzen in einem Testablauf eruiert und möglicherweise optimiert werden.
4.3 Anwendungsgebiete von Testautomatisierung
Zu den Anwendungsgebieten von Testautomatisierung gehören Integrations-, Regressions-, Komponenten-, Last- (engl. Load-) und Performancetests.
Die Unterstützung durch das automatisierte Testwerkzeug steigert die Leistung von Integrationstests für nachfolgende Softwarebuilds, da jede neue Softwareversion eine beträchtliche Anzahl von Tests verursacht. Es besteht aber auch die Möglichkeit, bereits vorhandene Testskripts mehrfach zu verwenden. Automatisierte Softwaretests dienen als wichtiger Kontrollmechanismus zur Gewährleistung der Korrektheit und Stabilität der Software in allen neuen Builds.
Regressionstests auf Systemtestebene stellen eine effiziente Anwendung automatisierter Tests dar und garantieren, dass die von einem neuen System bereitgestellten Funktionen wie festgelegt arbeiten und keinerlei unbeabsichtigte Änderungen auftreten. 1
Komponententests gelten als ein wichtiges Anwendungsgebiet der
Testautomatisierung. Komponententests ermöglichen Programmierfehler früher zu finden. Dies hilft bei der Reduzierung der Kosten (Kapitel 3.5).
Last- und Performance-Tests können nur automatisiert durchgeführt werden, da man hier viele gleichzeitig agierende User simuliert.
1 Vgl. Dustin / Rashka / Paul (2001), S. 4.
4.4 Warum automatisiertes Testen
Softwareprojektmanager und -entwickler werden gedrängt, ihre Produkte in immer kürzerer Zeit und mit immer weniger Ressourcen zu entwickeln. Ein Produkt möglichst schnell auf den Markt zu bringen entscheidet über Erfolg oder Misserfolg eines Unternehmens. Viele Projekte überschreiten die geplanten Liefertermine der Entwickler. Da aber zumeist der Produktivstellungstermin feststeht, bleibt dem Testteam weniger Zeit um das Produkt sorgfältig zu testen.
Zusätzlich versuchen die Firmen ihre Kosten, durch Automatisierung und
Rationalisierung von Geschäftsprozessen mit Hilfe von Softwareanwendungen, zu reduzieren. Durch das Bestreben auch mit geringeren finanziellen Mitteln Software mit hoher Qualität zu erstellen, wollen die Firmen ihre Software gut, aber in möglichst kurzer Zeit testen. Um dies zu erreichen gehen sie zum automatisierten Testen über.
4.5 Praxis
Testautomatisierung dient als wichtiges Tool für das Testmanagement in Bezug auf Planung und Reporting. Das Testteam achtet darauf, dass die Geschäftsführung nicht zu hohe Erwartungen hat. Der Einsatz der Testautomatisierung hängt von den durchgeführten Tests ab. Weiters muss sich das Testteam Gedanken über die Kosten und den Nutzen der Testautomatisierung machen.
Die befragten Unternehmen sehen Testautomatisierung als absolut sinnvollen Weg um hohe Qualität zu erreichen. Vor allem Regressionstests gelten als gute Anwendung für die Automatisierung von Tests. Bei einer komplizierten Umgebung überprüft man mittels Testautomatisierung, ob durch die neue Version nichts kaputt gemacht wurde. Zu den, von den befragten Personen festgestellten, Problemen von Testautomatisierung gehört die schlechte Wartbarkeit, die nur durch konsequente Dokumentation verbessert werden kann. Bei längerfristigen Projekten und größerer Anzahl involvierter Personen empfiehlt es sich Testautomatisierung einzusetzen. Im Gegensatz dazu rentiert sich die Anwendung bei kurzfristigen und kleinen
Projektgruppen nur selten, da die Zeit und der Aufwand, die notwendig sind, um Testautomatisierung einzusetzen ein kleines Projekt übersteigen würden.
5 Automatisierte oder manuelle Tests
Dieses Kapitel beschreibt den Ansatz für die Entscheidung über automatisiertes oder manuelles Testen. Das Testteam führt Automatisierung schrittweise ein statt alles gleichzeitig zu automatisieren. Das Testteam sollte die Automatisierungsarbeit an den Zeitplan anpassen und beachten, dass die Erstellung eines automatisierten Testskripts für komplexe Funktionalitäten genauso lange dauert wie die Erstellung des Codes. Wenn der zuvor analysierte Automatisierungsaufwand zu groß ist, empfiehlt es sich manuell zu testen. Ein weiterer zu beachtender Punkt ist die Wiederverwendbarkeit der Testskripts, da sonst ein zusätzlicher Aufwand auftritt.
Das Testteam konzentriert sich bei der Automatisierungsarbeit auf wiederholende Aufgaben, welche Zeitersparnis für manuelle Tests bringen und es den Testingenieuren ermöglicht, sich auf wichtigere Aufgaben zu konzentrieren.
„Ein Teil der Definition von Testverfahren besteht in der Entscheidung, ob ein Test manuell oder automatisiert ausgeführt wird. Während der Einheitentests, ist es möglich eine Vielzahl unterschiedlicher Tests zu automatisieren.“ 1 Während der Systemtests ist dies weitaus komplexer.
Um zu analysieren, was automatisiert wird, sollte das Testteam folgende Punkte beachten: 1
• Nicht alles auf einmal automatisieren
• Es ist nicht möglich alles zu testen
• Testziele nicht aus den Augen verlieren
• Analyse des Automatisierungsaufwands und Wiederverwendungspotentials
• Automatisierung auf wiederholende und datenorientierte Aufgaben konzentrieren
1 Dustin / Rashka / Paul (2001), S. 302.
• Möglichkeiten der Testwerkzeuge beachten
• Testanforderungen in Abhängigkeit vom Risiko automatisieren
Das Anwenden dieser Leitlinien erleichtert dem Testteam die Entscheidung welche Testfälle automatisiert und welche besser manuell getestet werden sollten.
5.1 Standards für das Design automatisierter Tests
Das folgende Kapitel basiert auf dem Buch „Software automatisch testen“ von Dustin, Rashka, und Paul. 2
Um einen wiederholbaren und wiederverwendbaren Prozess zu entwickeln, muss ein Standard für das Design von Testverfahren erstellt werden. Alle am Testdesign partizipierenden Personen sind an diesen Standard gebunden. Dies fördert die Konsistenz und erleichtert die Integration der verschiedenen Testfälle in das behandelte Testrahmenwerk. Ziel des Designs automatisierter Testfälle ist die Reduzierung der Skriptentwicklungsarbeit, die Minimierung der Pflege und die Förderung der Wiederverwendbarkeit und Flexibilität der Skripts, um spätere Änderungen an der zu testenden Anwendung leichter einarbeiten zu können.
5.1.1 Wann sollte das Design erfolgen?
Mit den Testanforderungen und dem Testdesign ist bereits während der Phase des Sammelns der Anwendungsanforderungen zu beginnen. Während der Phase der Einheiten- und Integrationsentwicklung werden Testanforderungen (Welche Funktionen sollen getestet werden? Z.B.: Reparaturauftrag erstellen) gesammelt und mit dem Testdesign begonnen. Den höchsten Effektivitätsgrad erreicht man, wenn Testentwicklung und Testdesign parallel zur Anwendungsentwicklung stattfinden. Unumgänglich ist, dass die Arbeit am Testdesign die Anwendungsentwicklung nicht unterbricht.
1 Vgl. Dustin / Rashka / Paul (2001), S. 305-306.
2 Vgl. Dustin / Rashka / Paul (2001), S. 308-311.
5.1.2 Was sollte entworfen werden?
Zu den Zielen des Testens gehört das Aufdecken von Fehlern in der zu testenden Anwendung und zu überprüfen, ob die Systemanwendung die Testanforderungen erfüllt. Ein gutes Testdesign deckt erwartete Ein- und Ausgaben ab und versucht, unerwartete Ein- und Ausgaben zu berücksichtigen. Daher sollten die Tests auch das Verhalten unter unerwarteten Bedingungen prüfen.
5.1.3 Wie erstellt man ein Design?
Das Testteam muss Tests entwickeln, welche die wichtigsten Aspekte der Anwendung abdecken und sich an die zuvor erstellten Designstandards halten. Bevor dies passiert, erstellt das Testteam die Testanforderungen, um diese danach als Grundspezifikation bzw. Baseline für das Design von Testfällen zu nutzen. Dies macht die automatisierten Tests wiederverwendbar und wiederholbar. Außerdem entwickelt das Testteam zuerst die Aufgaben mit hoher Priorität. Durch Einbeziehung der Kunden und Benutzer in das Testdesign lassen sich Überraschungen bei der Implementierung der Tests vermeiden.
5.1.4 Modularität der Testfälle
Standards für das Design von Testverfahren berücksichtigen den Umfang eines Tests. Zu diesen Standards gehören die Höchstzahl der zulässigen Testfälle bzw. Testskripts (Abbildung 7). Um die Verwaltung zu vereinfachen, reduziert man am Besten die Testfälle auf eine einzige Funktion.
Arbeit zitieren:
Michael Menzel, 2004, Einführung von Testsoftware im IT-Bereich, München, GRIN Verlag GmbH
Dieser Text kann über folgende URL aufgerufen und zitiert werden:
Einbetten
DOI
Vergleich von Methoden für die Wirtschaftlichkeitsanalyse von Informat...
Informatik - Wirtschaftsinformatik
Seminararbeit, 26 Seiten
Organisatorische Eingliederung des IT-Controlling in ein Unternehmen
Seminararbeit, 21 Seiten
DV-Revision hinsichtlich Ordnungsmäßigkeits- und Sicherheitsanforderun...
Diplomarbeit, 136 Seiten
Kostentreiber Softwarequalität – Optimierung von Testmanagement und Te...
Informatik - Wirtschaftsinformatik
Diplomarbeit, 72 Seiten
Personalbeurteilung und Beurteilungsgespräch als Bestandteil der Führu...
BWL - Personal und Organisation
Studienarbeit, 52 Seiten
Einsatz neuronaler Netze zur Mustererkennung
Informatik - Wirtschaftsinformatik
Seminararbeit, 24 Seiten
Michael Menzel hat den Text Einführung von Testsoftware im IT-Bereich veröffentlicht
Michael Menzel hat einen neuen Text hochgeladen
Werkzeuge zur Testautomatisierung
Informatik - Angewandte Informatik
Studienarbeit, 71 Seiten
Vergleich von Methoden für die Wirtschaftlichkeitsanalyse von Informat...
Informatik - Wirtschaftsinformatik
Seminararbeit, 26 Seiten
Organisatorische Eingliederung des IT-Controlling in ein Unternehmen
Seminararbeit, 21 Seiten
DV-Revision hinsichtlich Ordnungsmäßigkeits- und Sicherheitsanforderun...
Diplomarbeit, 136 Seiten
Kostentreiber Softwarequalität – Optimierung von Testmanagement und Te...
Informatik - Wirtschaftsinformatik
Diplomarbeit, 72 Seiten
Visuelle Wahrnehmung im zweidimensionalen Bereich
Elementare Phänomene der zweid...
Moritz Zwimpfer, Schule für Gestaltung Basel
Einführung in die Anglo-Amerikanische Rechtssprache (Introduction to A...
Introduction to Anglo-American...
B. Sharon Byrd
Eine Einführung in die Typografie. Une Initiation à la Typographie. An...
Anne Denestas, Camille Gallet, Maria Hoffmann-Dartevelle, Bruce Mayo
Einführung in die Phänomenologie der Erkenntnis. Vorlesung 1909
Edmund Husserl, Elisabeth Schuhmann
0 Kommentare