Leitfaden für die Einführung einer Testautomation zur effizienten Qualitätssicherung von Softwareprodukten

Inhaltsverzeichnis

Abkürzungsverzeichnis

Symbolverzeichnis

Abbildungsverzeichnis

Formelverzeichnis

Tabellenverzeichnis

1 Einführung
1.1. Forschungsinteresse
1.2. Bergriffserklärung
1.3. Themenabgrenzung
1.3.1. ISO 9000 Norm
1.3.2. Tests im Kontext der Qualitätssicherung
1.3.3. Qualitätsmanagement für Softwareprodukte
1.3.4. Testautomation
1.4. Zielsetzung und Aufbau des Leitfadens

2 Entscheidungsprozess für die Testautomatisierung
2.1. Anstoß für die Einführung einer Testautomation
2.2. Ziele
2.3. Rahmenbedingungen
2.3.1. Ist-Analyse
2.3.2. Unternehmensgröße und Wachstum
2.3.3. Marktstudie
2.3.4. Organisation
2.3.5. Qualitätsanspruch
2.3.6. Analyse der Testobjekte
2.3.7. Grenzen der Testautomation
2.4. Auswahl der Softwarelösung
2.4.1. Risikoanalyse
2.4.2. Entscheidungsmatrix
2.4.3. Kosten-Nutzen-Analyse
2.5. Erwerb der Software
2.6. Projektauftrag verfassen

3 Einführung der Testautomation
3.1. Projektvorbereitung
3.1.1. Zielvorstellung
3.1.2. Machbarkeitsstudie
3.1.3. Wirtschaftlichkeitsprüfung
3.1.4. Projektplanung
3.2. Konzeption
3.3. Spezifikation
3.4. Realisierung
3.4.1. Umsetzung der Testautomation
3.4.2. Umsetzung Testfallbeschreibung in automatisierte Tests
3.4.3. Test und Qualitätssicherung
3.4.4. Dokumentation
3.5. Inbetriebnahme
3.6. Wartung

4 Einsatz der Automatisierungssoftware

5 Praxisfall
5.1. Rahmenbedingungen
5.2. Projektvorbereitung
5.3. Projektverlauf

6 Zusammenfassung und Fazit

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Symbolverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Abhängigkeiten der Testphasen: V-Modell

Abbildung 2: Automated Testing Life-Cycle Methodology

Abbildung 3: Magisches Dreieck: Ziel, Zeit und Kosten

Abbildung 4: Beispiel Qualitätsanspruch und Fehlerkosten

Abbildung 5: Magisches Dreieck: Qualität, Zeit und Budget

Formelverzeichnis

Formel 1: Berechnung der Amortisationszeit

Formel 2: Beispiel für die Berechnung der Amortisationszeit

Formel 3: Berechnung der Amortisationszeit in Tagen

Formel 4: Berechnung der Amortisationszeit ohne Fixkosten

Formel 5: Berechnung der Amortisationszeit in Tagen für Anwendung 1

Tabellenverzeichnis

Tabelle 1: Testphasen

Tabelle 2: Projektphasen

Tabelle 3: Vergleich der Projektorganisationen

Tabelle 4: Beispiel für eine Risikoanalyse

Tabelle 5: Beispiel Entscheidungsmatrix

Tabelle 6: Beispiel Gewichtete Entscheidungstabelle

Tabelle 7: Beispiel Versionierung des Projektplans

Tabelle 8: Beispiele Amortisationszeit in Tagen

Tabelle 9: Ergebnis für die Beispiele der Amortisationszeit in Tagen

Tabelle 10: Beispiel Risikoanalyse im Praxisfall

1 Einführung

1.1. Forschungsinteresse

Bei der Planung und Vorstudie eines Großprojektes für die Einführung einer Testautomatisierung fehlte dem Autor eine geeignete Vorlage für die Umsetzung dieses Projektes. Beschreibungen der Softwareunternehmen, die geeignete Anwendungen anbieten um Testfälle zu automatisieren, reichten nicht aus um Entscheidungen treffen zu können. Alternativen zu vergleichen bzw. Abläufe zu planen war mit den frei verfügbaren Dokumentationen nicht möglich. Typische Fragestellungen für die Projektplanung konnten mit Hilfe der Herstellerinformationen ebenfalls nicht geklärt werden. Allgemeine Vorgehensmodelle für vergleichbare Vorhaben werden bei den führenden Unternehmensberatungen in diesem Bereich nur intern und nicht öffentlich zugänglich weiter gegeben. Einige der Literaturquellen dieser Arbeit verdeutlichen zwar das allgemeine Vorgehen, sind allerdings nicht mit praxisnahen Informationen versehen um in einem hektischen Projektumfeld Hilfestellung leisten zu können. Dieser Leitfaden soll diese Lücke schließen und die Projektleitung sowie die Entscheidungsebene bei der Auswahl einer Anwendung und der Umsetzung der Einführung einer Testautomation unterstützen. Klassische Projektmanagementmethoden werden mit Erfahrungswerten des Autors ergänzt und geben die Möglichkeit Anwendungen schnell und einfach zu vergleichen. Entscheidungen können Bedarfsgerecht getroffen und die einzelnen Module des Leitfadens einzeln genutzt werden. Der anschließende Praxisteil weist auf typische Problemstellungen hin und unterstreicht die Bedeutung der vorangegangenen Kapitel und deren Auswirkung.

1.2. Bergriffserklärung

Im Umfeld der Qualitätssicherung von Softwareprodukten insbesondere dem professionellen Testmanagement und dem Projektmanagement werden einige Begriffe verwendet, die an dieser Stelle erklärt werden.

- Testfall – „Umfasst folgende Angaben: die für die Ausführung notwendigen Vorbedingungen, die Menge der Eingabewerte (ein Eingabewert je Parameter des Testobjekts) und die Menge der erwarteten Sollwerte, die Prüfanweisung … sowie erwarteten Nachbedingungen.“^[1]
- Teststep – Ein Ausführungsschritt innerhalb eines Testfalls, kann im Falle einer Fehlerdokumentation den Schritt des Fehlereintritts bestimmen
- Testphase bzw. Teststufe – Abstufung der Anforderung an die Testtiefe von Testfällen zu einem bestimmten Entwicklungsstand (s. Kapitel 1.3.3)
- Meilensteine – Ein Zwischenstand im Projektablauf, der zum Ende eines bestimmten Projektabschnitts erreicht werden muss. Die Erreichung des Meilensteins ist Vorraussetzung für den Beginn der folgenden Projektphase oder eines weiteren Meilensteins.^[2]Der Meilenstein definiert ein Ergebnis und ist in der Regel mit einem festen Termin gekoppelt.
- Testmanagement – „Das Testmanagement befasst sich mit der Planung und Steuerung der Aktivitäten im Testprozess während der gesamten…[Testphase].“^[3]
- Projektleiter – „Die Projektleiterin bzw. der Projektleiter leitet das Projekt. Diese Person trägt die Verantwortung dafür, dass die Projektziele in der vorgesehenen Zeit und mit dem geplanten Budget erreicht werden.“^[4]
- Auftraggeber – Ist im Projektumfeld derjenige, der den Auftrag zum Projekt erteilt und in der Regel auch das Budget zur Verfügung stellt.^[5]
- Release – „Bei einem Release muss es sich nicht um ein fertiges Produkt handeln…“^[6]. Es ist eine Art Zwischenstand bei der Entwicklung eines Produktes. Es wird zwischen internen Releasen für die Entwicklung oder eine Produktpräsentation und externen Releasen für die Endkundenauslieferung unterschieden.^[7]
- Migration – Ist die Übertragung einer Software auf ein anderes System bzw. die Übertragung von bestehenden Daten in ein neues System.^[8]Im Zusammenhang mit dieser Arbeit fällt im Rahmen von Migrationsprojekten oft ein hoher Testaufwand an.

1.3. Themenabgrenzung

Wichtiger Bestandteil für das ökonomische Handeln eines produzierenden Unternehmens ist es, die hergestellten Produkte in einer für den Kunden als gebrauchstauglich eingestuften Qualität herzustellen.^[9]Um die Bedürfnisse aller Interessengruppen zu befriedigen und die Qualität zu gewährleisten ist die Einrichtung eines Qualitätsmanagements notwendig.^[10]Als Standard haben sich die internationalen Normen DIN EN ISO 9000 ff entwickelt, welche die notwendigen Schritte für ein Qualitätsmanagement beschreiben.^[11]Darüber hinaus sind auch weitere Projekt- und Qualitätsmanagementmethoden mit ähnlichen Vorgehensweisen, wie Prince2 als Projektmanagementmethode für Dienstleistungsunternehmen, entstanden. Das Qualitätsmanagement ist häufig Bestandteil des Projektmanagements, im Fall des Themas dieser Arbeit ist der Projektinhalt ein Teil des Qualitätsmanagements anderer Projekte. Das Testen der Anwendung bedeutet die Qualitätssicherung der Inhalte und Ergebnisse für ein Projekt, das eine Software entwickelt hat. Diese Testfälle sollen zukünftig von der Testautomation abgearbeitet werden, sodass die Ergebnisse des Projektes für die Einführung der Testautomation Bestandteile des Qualitätsmanagementprozesses sind. Zugleich muss innerhalb der Projektumsetzung auch qualitätsgesichert werden, während die Funktion und die Ergebnisse der Software geprüft werden. Der Qualitätsmanagementprozess begleitet das Projekt aber auch während der Umsetzung, z.B. nachdem Dokumentationen erstellt sind, in Form von einer Überprüfung der Inhalte. Wenn dieses Projekt Vorläufer für weitere Projekte sein soll, ist dieser Punkt noch wichtiger, damit Dokumentenvorlagen für Nachfolgeprojekte nutzbar sind. Die Dokumentenvorlagen erhöhen dann die Dokumentenqualität der Folgeprojekte und helfen als Checkliste Vollständigkeit herzustellen.^[12]

1.3.1. ISO 9000 Norm

Der ISO Standard 9000 und folgende Normen berücksichtigen, neben den Interessen, beispielsweise der Mitarbeiter oder Aktionäre, auch die kundenorientierte Produktion und Sicherstellung der geforderten Qualität eines Produktes. Im Jahr 2000 wurden die ISO Normen 9000 überarbeitet. Zum einen mit dem Hintergrund den Focus auf das Prozessmanagement zu lenken und zum anderen das Managementsystem effektiv zu halten.^[13]Die aktuelle vorliegende Version ISO 9001:2008/Cor.1:2009 enthält im Wesentlichen textliche Korrekturen, die Methoden entsprechen allerdings weiter der ISO 9001:2000 Norm, die im Jahr 2008 leicht verändert wurde (ISO 9001:2008)^[14]. Im Kontext dieser Arbeit wird die Produktion bzw. Entwicklung von Anwendungen und deren Qualitätssicherung betrachtet. Grundlage für die Definition von Anforderungen an ein Produkt ist die ISO Norm 9001:2000. Da sich die Normen ISO 9000 und die Neuauflage 9000:2008 auf materielle und immaterielle Güter beziehen und der Zusammenhang zu der Softwareentwicklung nicht immer leicht adaptierbar war, wurde für den Bereich Softwareentwicklung die Norm ISO/IEC 90003:2004 von dem JTC SC7 entwickelt. Das Joint Technical Committee ist für alle Standards der Informationstechnologie zuständig, das Subcommittee 7 im speziellen für den Bereich Software- und System-Engineering.^[15]Die ISO/IEC 90003:2004 Norm erklärt die Anwendung der ISO 9001:2000 Norm während der Softwareentwicklung. Daher lassen sich die Anforderungen im Allgemeinen aus der ISO 9001:2000 Norm ableiten. Zum Teil werden Bestandteile dieser Norm im Kontext dieser Arbeit mit aufgenommen oder zumindest in abgewandelter Form genutzt. Dabei handelt es sich um Randthemen wie Dokumentation, Ressourcenplanung, Risikomanagement und Projektplanung, die in einem gut strukturierten Unternehmen vorausgesetzt werden. Der Focus des Leitfadens liegt auf der effizienten Durchführung von Produkttests als Bestandteil der Qualitätssicherung in Form von automatisierten Testfällen und die Einführung dieser Vorgehensweise. In der ISO 9001:2000 Norm wird beschrieben, dass eine neue Software erst nach Validierung freigegeben werden darf. Das bedeutet, dass eine Software den Anforderungen des Auftraggebers oder zukünftigen Kunden entspricht.^[16]Erfolgt die Validierung über eine Software, ist ebenfalls die Effektivität bei der Ermittlung der Anforderungskonformität zu berücksichtigen. Ob eine Automatisierungssoftware für den Einsatz effektiv ist, wird in den folgenden Kapiteln für den Einzelfall ermittelbar.

1.3.2. Tests im Kontext der Qualitätssicherung

Um die vom Kunden geforderte Qualität zu prüfen muss zunächst feststehen, welche Anforderungen an das Produkt gestellt werden.^[17]In der Fertigungsindustrie kann dies z.B. die Reißfestigkeit eines Sicherheitsgurtes für ein Auto sein, die sich aus der üblichen Nutzung des Sicherheitsgurtes ergibt. Am Markt ist nur ein Produkt erfolgreich, das den Eigenschaften der üblichen Nutzung entspricht. In diesem Beispiel bedeutet das, dass der Sicherheitsgurt im Falle eines Unfalls den Fahrer vor dem Herausschleudern aus dem Auto schützt. Es wird in Folge dessen definiert, wie viel Belastung ein Sicherheitsgurt aushalten muss. Ob das Produkt diese Eigenschaften aufweist, kann durch einen Produkttest geprüft werden. Die Belastung des Gurtes ist ein Teil der Anforderung. Weitere Anforderungen werden mit folgenden Produkttests nachgewiesen. Der Tragekomfort könnte eine weitere Eigenschaft sein. Die Produkttests sind die Überprüfungen der Anforderungen durch einen Test. Ein Test ist definiert als ein, nach einer genau durchdachten Methode vorgenommener Versuch bzw. Prüfung zur Feststellung der Eignung, der Eigenschaften, einer Leistung oder einer Person. Dies bedeutet, in dem oben genannten Beispiel, dass definiert wird, dass ein Sicherheitsgurt für ein Auto, zum Beispiel 1 Tonne Gewicht aushalten muss. Wird in einem Produkttest diese Belastung simuliert und der Gurt reißt nicht, ist dessen Eignung für diese definierte Anforderung bewiesen. Reißt der Gurt, ist die Ware fehlerhaft bzw. entspricht nicht dieser Anforderung. Im Positivfall muss die Erfüllung der einen Eigenschaft noch lange nicht bedeuten, dass das gesamte Produkt mangelfrei ist. Ist der Gurt zwar reißfest, wiegt aber über hundert Kilogramm, ist die Anforderung nach einem angemessenen Tragekomfort nicht gegeben. Das bedeutet, dass das Produkt mit der Gesamtheit an Eigenschaften am Markt nicht absetzbar ist.^[18]

Im Bereich der Softwareentwicklung bedeutet dies: „Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen.“^[19]Anders als bei Industrieprodukten, kann man die Erfordernisse nicht durch Belastbarkeit definieren. Allgemein kann man die Erfordernisse oder Eigenschaften einer Software wie folgt unterteilen:

- Funktionalität – Was muss die Software können?
- Effizienz (Ressourcenverbrauch, Serverauslastung) – Wie viel Rechenleistung, Arbeitsspeicher oder Festplattenspeicher benötigt die entwickelte Software?
- Zuverlässigkeit – Wann ist die Software verfügbar und ist das System im Betrieb stabil?
- Änderbarkeit (Anpassbar) – Können bei veränderten Prozessen im Unternehmen Anpassungen an der Software vorgenommen werden?
- Benutzbarkeit (Bedienbarkeit) – Kann ein Bediener die Software ohne übermäßig viele Schulungen, möglichst intuitiv bedienen?
- Fehlertoleranz (Vorhandensein von Fehlermeldungen) – Stürzt die Software ab oder werden falsche Ergebnisse ausgegeben?

Die Eigenschaften können durch Anwendungstests in mehreren aufeinander folgenden Testphasen während der Softwareentwicklung und im Anschluss sichergestellt werden.^[20]Die Anforderungen an die Detailtiefe der Testfälle steigen mit jeder Testphase an. Parallel zu der Entwicklung der Anwendung werden durch die Testdurchläufe sichergestellt, dass die bis dahin entwickelte Anwendung den Anforderungen der entsprechenden Testphase gerecht wird.^[21]Dieses Vorgehen stellt sicher, dass Abweichungen und Fehler frühzeitig erkannt und die Qualität der Anwendung sukzessive gesteigert werden kann. Würde erst zum Ende der Entwicklung eine Qualitätskontrolle erfolgen, würden viele nachfolgende Prozesse, die auf den fehlerhaften Code aufbauen, ebenfalls neu entwickelt werden müssen. Der Stufenweise-Test verhindert das Verwenden von fehlerhaften Programmbestandteilen bei der weiteren Entwicklung. Und je früher dies vermieden wird, desto weniger Kosten fallen für die Beseitigung des Fehlers an.^[22]Die Koordination der Testphasen erfolgt im Rahmen des Qualitätsmanagements. Dies kann ebenfalls von dem Projektmanager übernommen werden, wenn keine entsprechende Institution aufgebaut ist. Die automatisierten Testfälle, die Bestandteil anderer Projekte sind, können an anderer Stelle verwaltet werden.

1.3.3. Qualitätsmanagement für Softwareprodukte

Um die Testphasen für die Qualitätssicherung zu koordinieren, ist eine Integration der Testprozesse in den Projektablauf notwendig. Qualitätsmanagement für Softwareprodukte „… ist eine Managementdisziplin, die versucht, den Faktor Qualität durch geeignete Vorgehensweisen (Prozesse), Hilfsmittel und Verfahren sowie durch geplante und systematische Anwendung des Systems, Projekt- und Software Engineering im Lifecycle von Softwareprodukten bewusst zu gestalten.“^[23]Für die Terminplanung der Testphasen sind zunächst die Anforderung an die jeweilige Testphase und der Zusammenhang zu den bestehenden Projektphasen zu betrachten. Die einzelnen Testphasen, mit den geforderten Eigenschaften, werden in der Tabelle 1 beschrieben. Über die beschriebenen Anforderungen der Testphasen hinaus, sollte der Entwickler die Grundfunktionen der Anwendungen in Form von Entwicklertests auf seine Qualität hin geprüft haben, bevor er den Code für folgende Testphasen freigibt.^[24]

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung: Teichreber, P.E. (2008) S. 44

Tabelle 1: Testphasen

Die zeitliche Reihenfolge der Testphasen richtet sich nach den Meilensteinen und Terminen der Projektphasen. In den definierten Projektphasen werden Dokumente erstellt, die in den einzelnen Testphasen als Anforderungen gesetzt und im Rahmen von Anwendungstests getestet werden.^[25]Die Testphasen müssen wiederholt werden, wenn Fehler gefunden und einzeln behoben sowie erneut getestet wurden.

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung: Teichreber, P.E. (2008) S. 43 f

Tabelle 2: Projektphasen

Die Zusammenhänge zwischen den Projektphasen und den Testphasen sind in dem V-Modell in der Abbildung 1 dargestellt. Das Vorgehen ist Entwicklungsstandard für die IT-Systeme sowie die Projektdurchführung des Bundes und ist konsistent zu dem Standard DIN EN ISO 9001.^[26]

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Teichreber, P.E. (2008) S. 44

Abbildung 1: Abhängigkeiten der Testphasen: V-Modell

In den Projektphasen eins bis vier werden die Anforderungen mit steigender Detailtiefe definiert und in der fünften Projektphase, in den Testphasen: Modultest, Integrationstest und Akzeptanztest bzw. Abnahmetest, überprüft. Vorraussetzung für die Testphasen ist die Fertigstellung des Codes.^[27]Jede Testphase basiert auf einem, in den vorherigen Projektphasen, definierten Dokument. Der Modul Test überprüft die Beschreibungen des Modul Designs, der Integrationstest das DV-Konzept und der Akzeptanztest oder Abnahmetest den Fachentwurf und die vorangegangenen Anforderungsdefinitionen. Wird im Ablauf der Testphasen eine Abweichung oder ein Fehler festgestellt, folgt eine Anpassung des Codes und eine Wiederholung der fehlerhaften Testphase, nachdem jeder einzelne Fehler erfolgreich nachgetestet ist. Für die spätere Nachvollziehbarkeit der Testergebnisse, wird jeder Testfall innerhalb einer Testphase mit seinem Ergebnis dokumentiert. Die Dokumentation beschreibt im Gesamtablauf der Testphasen zu welchem Zeitpunkt welche Qualität der Anwendung erreicht wurde.^[28]Ist die Qualität durch den erfolgreichen Abschluss alle Testphasen bewiesen und die Anwendung abgenommen, kann mit der Implementierungsphase begonnen werden.^[29]Bei einer bestehenden Anwendung, die erweitert wird, muss zusätzlich zu den neuen Anwendungsbestandteilen auch das Zusammenspiel mit den bereits bestehenden Komponenten getestet werden. Daraus ergeben sich eine Reihe von Testanforderungen, die in der Realisierungsphase durchzuführen sind. In den jeweiligen Testphasen wurden die Testanforderungen in Testfällen beschrieben. Dabei handelt es sich um technische oder fachliche Ausführungen, welche die Funktion der Anwendung im Kontext der gerade betrachteten Testphase beschreibt. Alle Tests werden dokumentiert und auftretende Fehler zusätzlich an die Entwicklung zwecks Anpassung weiter gegeben. Im Falle eines Fehlers wird dieser gesondert dokumentiert um zu einem späteren Zeitpunkt nachzuvollziehen, in welcher Testphase welche Fehler aufgetreten sind. Es gibt zwei Arten von Testfällen. Zum Einen die Progressionstestfälle, für alle neuen Anwendungsbestandteile und zum Anderen die Regressionstestfälle der bestehenden und unveränderten Anwendungsbestandteile.^[30]Diese Aufteilung ermöglicht dem Entwickler zu differenzieren in welchen Modulen der Fehler vermutet werden kann. Außerdem kann je nach Anforderung des Unternehmens eine Regressionstestreihe für eine Anwendung mit einem geringeren Aufwand ausgeführt werden als bei dem erstmaligen Test dieses Anwendungsbestandteiles. Der Hintergrund ist, dass wenn eine Anwendung oder ein Teil dieser bereits erfolgreich getestet wurde, die Wahrscheinlichkeit geringer ist, dass ein Fehler gefunden wird als bei einer ganz neuen Anwendung. Dennoch kann es vorkommen, dass durch eine Änderung an einer zentralen Stelle oder durch Verwendung einer anderen Komponente bestehende Funktionen Fehler aufweisen. Wenn den Entwicklern bzw. den Projektleitern bekannt ist, in wie weit einzelne Komponenten mit anderen verknüpft sind, kann die Testtiefe der Regressionstestfälle entsprechend gering oder hoch ausfallen. In der Praxis ist dies bewusst weggelassen worden, wenn das Budget für die Umsetzung einer Neuerung so gering ausfällt, dass der Fokus der Tests auf den Neuerungen und nicht auf den bestehenden Funktionen gesetzt werden muss. Sollte dann ein Fehler vorhanden sein, wird er erst bei dem Einsatz der Software auffallen. Die Abbildung 4 zeigt den unterschiedlichen Qualitätsanspruch an die erstellte Software. Sind die Kosten, die ein Fehler in Produktion verursachen kann gering, wird häufig auf umfangreiche Qualitätssicherungsmaßnahmen verzichtet.^[31]

Komplexe Anwendungen oder häufige Anpassungen einer Anwendung führen dazu, dass einzelne Testfälle mehrfach zu wiederholen sind. Das manuelle Abarbeiten dieser Testfälle bedeutet einen hohen Zeit- und Kostenaufwand. Sind die Zeiträume für einen intensiven Test zu kurz um die definierten Funktionalitäten zu testen, leidet die Qualität der Ergebnisse. Daher stellt sich die Frage, ob Teile der Testfälle maschinell abgearbeitet werden können. Der Zeitaufwand für einen automatisierten Testdurchlauf ist im Verhältnis zu manuellen Tests in der Regel sehr gering und die Testergebnisse sind kurzfristig verfügbar. Das führt dazu, dass entweder die gleiche Testqualität in kürzerer Zeit oder eine höhere Testqualität in der gleichen Zeit erreicht wird.^[32]

1.3.4. Testautomation

„Das automatisierte Testen ist die Verwaltung und Durchführung von Testaktivitäten einschließlich der Entwicklung und Ausführung von Testskripts zur Überprüfung der Testanforderung mit Hilfe eines automatisierten Testwerkzeugs.“^[33]

Für einen manuellen Test muss ein Tester die Anforderung eines Tests verstehen, eine Aktion innerhalb der zu testenden Anwendung durchführen, eine Reaktion oder Funktion überprüfen und im Testfall den erfolgreichen Test oder einen Fehler dokumentieren. Ersetzt man diese Abläufe durch eine Automatisierungssoftware, wird der manuelle Aufwand je Testphase reduziert. Um die Schritte manueller Testfälle automatisiert durchführen zu lassen, muss die Automatisierungssoftware den Umgang mit der zu testenden Anwendung erlernen. Für Umsetzung der Testautomatisierung für komplexe Anwendungen empfiehlt sich eine gründliche Vorbereitung damit die Funktion und die Ergebnisse rechtzeitig bereit stehen. Je nach Organisation des Unternehmens kann die Umsetzung Teil eines laufenden Projekts oder ein eigenes Projekt sein. In jedem Fall sollten die Qualität der automatisierten Tests aber auch die Grenzen der verwendeten Automatisierungsanwendung vor der Einführung feststehen. Der Aufwand von der Vorbereitung bis zum automatisierten Test ist höchst unterschiedlich aber in der Regel höher als das einmalig manuelle Testen. Aus diesem Grund steht am Anfang der Entscheidung eine Kosten-Nutzen-Analyse des Vorhabens. Bei häufig wiederholten Tests überwiegt der Nutzen gegenüber dem Initialen Aufwand.^[34]Im Bereich der webbasierten Anwendungen, die einen Internetbrowser als Plattform nutzen, hat sich als Praxiswert ein doppelter Aufwand gegenüber dem manuellen Testen herausgestellt. Bei einem einmaligen Testdurchlauf ist demnach das manuelle Testen dem automatisierten Test vorzuziehen.

1.4. Zielsetzung und Aufbau des Leitfadens

Dieser Leitfaden beschreibt die Besonderheiten eines Projektes zur Einführung einer Testautomation für Softwareprodukte. Neben klassischen Projektleitungsmethoden sollen die Erfahrungen des Autors zukünftigen Projektleitern die Durchführung eines vergleichbaren Projekts erleichtern. Gleichzeitig dient der Aufbau als Vorlage für eine Dokumentation. Eine Checkliste, die man anhand der Gliederung erstellen kann, hilft alle Fragestellungen vor der Einführung zu betrachten, der Leitfaden beschreibt die einzelnen Punkte der Liste dann im Detail. Die Gliederungspunkte können im „Baukastenprinzip“ individuell genutzt werden. Ist ein Punkt für ein Unternehmen nicht relevant oder von außen vorgegeben, kann zu jedem beliebigen Gliederungspunkt übergegangen werden. Für die Einführung einer Testautomation ist eine klassische Projektplanung sinnvoll.^[35]Dieser Leitfaden übernimmt einzelne Methoden des Projektmanagements, die um die Besonderheiten des Themas dieser Arbeit ergänzt werden. Das weitere Vorgehen soll den unternehmensüblichen Projektabläufen folgen. In dem Kapitel 2.5 ist der Erwerb der Software beschrieben. Das Kapitel 3.1 beschreibt die Projektvorbereitung für die Einführung einer Testautomation. Es werden neben üblichen Fragestellungen und Analysen auch die notwendigen Vorbereitungen erläutert. Das Kapitel 3 als Ganzes, beschreibt die Umsetzung des Projektes für die Einführung einer Testautomatisierung. Der Aufbau der Kapitel richtet sich nach den Phasen der „Automated Testing Life-Cycle Methodology“.^[36]Innerhalb des 3. Kapitels orientiert sich der Aufbau an den Projektphasen (s. Abbildung 2) für die Umsetzung eines Projektes und ist somit chronologisch aufgebaut. Jeder Unterpunkt bezieht sich auf, in der Literatur beschriebene, Vorgänge und Methoden, die um die Erfahrungen des Autors ergänzt sind.

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Dustin, E., Rashka, J., Paul, J. (2000) S. 11

Abbildung 2: Automated Testing Life-Cycle Methodology

Das ATLM beschreibt die sechs Phasen für die Einführung einer Testautomation. In der ersten Phase wird eine Entscheidung für eine Testautomatisierung getroffen. Diese Phase ist im Kapitel 2 beschrieben. Die zweite Phase findet sich in dem Kapitel 2.5 wieder und beschreibt den Erwerb der Software. Die dritte Phase und auch der Fokus dieser Arbeit ist das Projekt um die Einführung der Softwarelösung und wird in dem Kapitel 3 behandelt. In den Phasen vier bis sechs werden die nachfolgenden planerischen Schritte, die Nutzung und eine Bewertung der Ergebnisse behandelt.^[37]Eine grobe Zusammenfassung ist im Kapitel 4 zu finden. Um die Vorgehensweise besser nachvollziehen zu können, wird im Kapitel 5 der theoretische Teil anhand eines Praxisbeispiels nachvollzogen und an manchen Stellen vertieft.

[...]

---

^[1]Spillner, A., Linz, T. (2005) S. 254

^[2]Vgl. DIN 69 900

^[3]Beims, M. (2009) S. 118

^[4]Brandt-Pook, H., Kollmeier, R. (2008) S. 128

^[5]Vgl. Bendisch, R., Kern, U. (2006) S. 19

^[6]Versteegen, G. (Hrsg.), Hindel, B., Meier, E., Vlasan, A. (2005) S. 125

^[7]Vgl. Versteegen, G. (Hrsg.), Hindel, B., Meier, E., Vlasan, A. (2005) S. 125

^[8]Vgl. Hoffmann, D. W. (2008) S. 9

^[9]Vgl. Kamiske, G. F., Brauer, J.-P. (2008) S. 1

^[10]Vgl. Pfeifer, T. (2001) S. 4

^[11]Vgl. Timischl, W. (2007), S. 1

^[12]Vgl. Albers, S., Wolf, J. (Hrsg.) (2003) S. 104

^[13]Vgl. Wagner, K. W., Käfer, R. (2008) S. 128

^[14]Vgl. Kraus, G., Westermann, R. (2010) S. 178

^[15]Vgl. Williams, B. (2008) S. 760

^[16]Vgl. Zauner, M., Schrempf, A. (2009) S. 197

^[17]Vgl. Timischl, W. (2007) S. 20

^[18]Vgl. Timischl, W. (2007) S. 1

^[19]Vigenschow, U. (2004), S. 15

^[20]Vgl. Teichreber, P. E. (2008) S. 42 ff

^[21]Vgl. Franz, K. (2007) S. 194

^[22]Vgl. Teichreber, P. E. (2008) S. 45

^[23]Vigenschow, U. (2004) S. 15

^[24]Vgl. Stang, K. (2002) S. 165

^[25]Vgl. Teichreber, P.E. (2008) S. 44

^[26]Vgl. Liggesmeyer, P. (2009) S. 385

^[27]Vgl. Teichreber, P. E. (2008) S. 43

^[28]Vgl. Liggesmeyer, P. (2009) S. 381

^[29]Vgl. Teichreber, P. E. (2008) S. 44

^[30]Vgl. Franz, K. (2007) S. 208

^[31]Vgl. Bea, F. X., Scheurer, S., Hesselmann, S. (2008) S. 333

^[32]Vgl. Dowie, U. (2009) S. 23

^[33]Dustin, E., Rashka, J., Paul, J. (2000), S. 4

^[34]Vgl. Frühauf, K., Ludewig, J., Sandmayr, H. (2002) S. 92 ff

^[35]Vgl. Dustin, E., Rashka, J., Paul, J. (2000) S. 125 f

^[36]Vgl. Dustin, E., Rashka, J., Paul, J. (2000) S. 8

^[37]Vgl. Dustin, E., Rashka, J., Paul, J. (2000) S. 11