Einführung von Testsoftware im IT-Bereich. Eine organisatorisch betriebswirtschaftliche Betrachtung

Inhalt

1 Einleitung

2 Definitionen

3 Was ist Testen
3.1 Definition Qualität
3.2 Definition Testen
3.3 Warum testen
3.4 Das V-Modell
3.5 Relative Kosten der Fehlerbehebung

4 Automatisiertes Testen
4.1 Definition: Automatisiertes Testen
4.2 Wann ist Testautomatisierung sinnvoll
4.3 Anwendungsgebiete von Testautomatisierung
4.4 Warum automatisiertes Testen
4.5 Praxis

5 Automatisierte oder manuelle Tests
5.1 Standards für das Design automatisierter Tests
5.1.1 Wann sollte das Design erfolgen?
5.1.2 Was sollte entworfen werden?
5.1.3 Wie erstellt man ein Design?
5.1.4 Modularität der Testfälle
5.1.5 Unabhängigkeit von Testfällen
5.1.6 Skriptsprache
5.1.7 Datenbanken von Testwerkzeugen
5.1.8 Vorlagen für Testfälle
5.1.9 Namenskonventionen
5.2 Standards für das Design manueller Tests
5.2.1 Namenskonventionen
5.2.2 Detailliertheit des Testfalls
5.2.3 Erwartetes Ergebnis
5.3 Wann rentiert sich Testautomatisierung?
5.4 Beispiel: Unterschied manueller und automatisierter Test
5.4.1 Feststellen des Aufwands für Testautomatisierung
5.4.2 Schätzung der reinen Ausführungszeit
5.4.3 Erstellen einer Schätzung für folgende Voraussetzungen
5.4.4 Berechnen des möglichen Zeitgewinns
5.4.5 Schätzen der Kosten und des Nutzens eines Tools
5.4.6 Erstellen eines vollständigen Kosten-Nutzen-Vergleichs

6 Kosten-Nutzen-Analyse
6.1 Erfassung der Kosten des Qualitätsmanagements
6.1.1 Grundproblematik der Kostenerfassung
6.1.1.1 Isolierte Qualitätsaktivitäten:
6.1.1.2 Integrierte Qualitätsaktivitäten:
6.2 Erfassung des Nutzens des Qualitätsmanagements
6.2.1 Grundproblematik der Nutzenerfassung
6.2.2 Erfassung des internen Nutzens
6.2.3 Erfassung des externen Nutzens
6.3 Einflüsse bei der Berücksichtigung des Nutzens
6.4 Bewertung in der Kosten-Nutzen- Matrix für Geschäftsfälle
6.5 Projektsteuerung mit Hilfe des Kosten-Nutzen-Koeffizienten
6.6 Veränderungen der Kosten-Nutzen-Matrix im Projektverlauf
6.7 ROI Berechnung:
6.7.1 Klassische ROI Analyse
6.7.2 Arten um den Nutzen von Funktionstests zu berechnen
6.7.3 ROI für einen einzelnen Testfall berechnen
6.7.4 Gesamtzahl von Probeläufen kalkulieren
6.7.5 Kombination von ROI für einen einzelnen Testfall und Anzahl der Testläufe
6.7.6 Berechnen von ROI für mehrere Testskripts
6.8 Praxis
6.9 Conclusio

7 Entscheidung zur Automatisierung
7.1 Allgemeine Erwartungen an automatisierte Tests
7.2 Mögliche Erwartungen, die das Testwerkzeug nicht erfüllt
7.2.1 Automatische Erstellung des Testplans
7.2.2 Automatische Erstellung der Testfälle
7.2.3 Es gibt ein ultimatives Testwerkzeug
7.2.4 Unmittelbare Verringerung des Testaufwands
7.2.5 Unmittelbare Verkürzung des Zeitplans
7.2.6 Benutzerfreundlichkeit des Testwerkzeugs
7.2.7 Automatisierung ist universell einsetzbar
7.2.8 Erreichung einer 100 %igen Testcoverage
7.2.9 Testautomatisierung findet mehr Fehler als manuelle Tests
7.3 Probleme beim Automatisieren
7.3.1 Unrealistische Erwartungen
7.3.2 Schlechte manuelle Tests
7.3.3 Wiederverwendbarkeit und Adaptierbarkeit der Tests
7.3.4 Technische Probleme
7.3.5 Organisatorische Probleme
7.4 Vorteile automatisierter Tests
7.4.1 Erstellung eines zuverlässigen Systems
7.4.2 Verbesserung der Testqualität
7.4.3 Reduzierung des Testaufwands und des Zeitplans
7.4.4 Vermeidung von Qualitätseinbrüchen bei einer neuen Lieferung
7.5 Unterstützung durch die Geschäftsführung
7.6 Zeitrahmen
7.7 Risiken in der Entscheidungsphase
7.8 Praxis
7.9 Conclusio

8 Auswahl des Testwerkzeugs
8.1 Anforderungen
8.1.1 Umgebung
8.1.2 Welche Probleme im Testprozess sollen gelöst werden?
8.1.3 Herausfinden von möglichen Lösungen
8.1.3.1 Manuelle Testprobleme
8.1.3.2 Keine Zeit für Regressionstests
8.1.3.3 Fehleranfälligkeit beim Erstellen von Testdaten und Testfällen
8.1.3.4 Mangelhafte Testdokumentation
8.1.4 Richtige Zeit für die Einführung
8.1.5 Wie viel Hilfe bringt das Testwerkzeug?
8.2 Beschränkungen
8.2.1 Hardware und Software
8.2.2 Einschränkungen des Anbieters
8.2.3 Kosteneinschränkung
8.2.4 Politische Einschränkung
8.2.5 Qualitätseinschränkung
8.3 Selbst entwickeln oder kaufen?
8.4 Bewertungskriterien
8.5 Marktübersicht
8.5.1 Mercury Interactive:
8.5.2 Rational:
8.5.3 Compuware:
8.5.4 Segue Software:
8.6 Welche Werkzeuge gibt es?
8.6.1 Testmanagement:
8.6.2 Capture-Replay:
8.6.3 Fehlermanagement:
8.6.4 Load-Tests:
8.6.5 Testfallgeneratoren:
8.6.6 Testdatengeneratoren:
8.6.7 Wartungskosten:
8.6.8 Vermietung von Software:
8.6.9 Überblick Anbieter:
8.7 Entscheidungsprozess
8.7.1 Vorauswahl
8.7.2 Produktpräsentationen
8.7.3 Auswahl
8.8 Pilotprojekt
8.9 Schulung
8.10 Zeitrahmen
8.11 Risiken in der Auswahlphase
8.12 Praxis
8.13 Conclusio

9 Einführung des automatisierten Testens
9.1 Analyse des Testprozesses
9.1.1 Analyse des bestehenden Prozesses
9.1.2 Testziele definieren
9.1.3 Teststrategien implementieren
9.1.3.1 Strategien zur Fehlervermeidung
9.1.3.2 Strategien zur Fehlererkennung
9.2 Überlegungen zum Testwerkzeug
9.2.1 Überprüfung der Systemanforderungen
9.2.2 Überprüfung des Projektzeitplans
9.2.3 Vorführung des Werkzeugs für das Projektteam, Umgang mit den Erfahrungen
9.2.4 Überblick über die zu testende Anwendung
9.2.5 Rollen und Verantwortlichkeiten
9.2.6 Schulungsanforderungen
9.3 Projektteam
9.3.1 Struktur des Testteams
9.3.1.1 Durchgangs-Testteam
9.3.1.2 Zentrales Testteam
9.3.1.3 UVV-Testteam (Unabhängiges Verifizieren und Validieren)
9.3.1.4 SMT-Testteam (System Methodology and Test)
9.3.2 Umfang des Testaufwands
9.3.2.1 Testreife Ebene 1 (Performed):
9.3.2.2 Testreife Ebene 2 (Managed):
9.3.2.3 Testreife Ebene 3 (Defined):
9.3.2.4 Testreife Ebene 4 (Quantitatively Managed):
9.3.2.5 Testreife Ebene 5 (Optimizing):
9.3.3 Bestimmung der Testteamgröße
9.3.4 Faktoren mit Einfluss auf den Testaufwand
9.3.5 Wichtigste Eigenschaften von Testingenieuren
9.3.6 Rollen und Verantwortlichkeiten im Testteam
9.4 Intern oder extern ?
9.5 Zeitrahmen
9.6 Risiken in der Einführungsphase
9.7 Praxis
9.8 Conclusio

10 Planung, Design und Entwicklung von Tests
10.1 Testplanung
10.1.1 Testplanungsaktivitäten
10.1.2 Anwendungsbereich der Tests
10.1.3 Testanforderungsmanagement
10.1.4 Beurteilen der Risiken von Testanforderungen
10.1.5 Prioritäten festlegen
10.1.6 Ereignisse, Aktivitäten und Dokumentation des Testprozesses
10.1.6.1 Ereignisse:
10.1.6.2 Aktivitäten:
10.1.6.3 Dokumentation:
10.1.7 Testumgebung
10.1.7.1 Vorbereitung der Testumgebung
10.1.7.2 Integration und Einrichtung der Testumgebung
10.1.8 Dokumentation des Testplans
10.1.9 Kriterien für die Akzeptanz der Testergebnisse
10.2 Testanalyse und –design
10.2.1 Analyse der Testanforderungen
10.2.2 Testdesign
10.2.2.1 White-Box-Techniken:
10.2.2.2 Black-Box-Techniken:
10.2.3 Testfälle entwerfen
10.2.3.1 Definition von Testfällen:
10.3 Entwicklung von Tests
10.3.1 Entwicklungsarchitektur für Tests
10.3.2 Richtlinien für das Entwickeln von Testfällen
10.3.3 Automatisierungsinfrastruktur
10.3.4 Testdaten
10.4 Zeitrahmen
10.5 Risiken in der Planungs-, Design- und Entwicklungsphase
10.6 Praxis
10.7 Conclusio

11 Ausführen und Verwalten von automatisierten Tests
11.1 Durchführung und Bewertung der Testphasen
11.2 Fehlerverfolgung
11.3 Verfolgung des Testfortschritts, Testabdeckung und Qualität des Testablaufs
11.4 Zeitrahmen
11.5 Risiken in der Ausführungs- und Verwaltungsphase
11.6 Praxis
11.7 Conclusio

12 Bewertung und Verbesserung des Testprozesses
12.1 Korrektur- und Verbesserungsmaßnahmen
12.2 Bewertung der Tests
12.3 Zeitrahmen
12.4 Risiken in der Bewertungsphase
12.5 Praxis
12.6 Conclusio

13 Leitfaden
13.1 Vorbedingungen
13.1.1 Tätigkeiten:
13.2 Entscheidungsphase
13.2.1 Tätigkeiten:
13.2.2 Zeitrahmen: (Kapitel 7.6)
13.2.3 Risiken: (Kapitel 7.7)
13.2.4 Möglichkeiten:
13.3 Auswahlphase
13.3.1 Tätigkeiten:
13.3.2 Zeitrahmen: (Kapitel 8.10)
13.3.3 Risiken: (Kapitel 8.11)
13.3.4 Wichtig:
13.3.5 Auswahl des Testwerkzeugs:
13.4 Einführungsphase
13.4.1 Tätigkeiten:
13.4.2 Zeitrahmen: (Kapitel 9.5)
13.4.3 Risiken: (Kapitel 9.6)
13.4.4 Wichtig:
13.4.5 Möglichkeiten:
13.5 Planungs-, Design- und Entwicklungsphase
13.5.1 Tätigkeiten:
13.5.2 Zeitrahmen: (Kapitel 10.4)
13.5.3 Risiken: (Kapitel 10.5)
13.5.4 Wichtig:
13.6 Durchführungsphase
13.6.1 Tätigkeiten:
13.6.2 Zeitrahmen: (Kapitel 11.4)
13.6.3 Risiken: (Kapitel 11.5)
13.6.4 Wichtig:
13.7 Bewertungsphase
13.7.1 Tätigkeiten:
13.7.2 Zeitrahmen: (Kapitel 12.3)
13.7.3 Risiken: (Kapitel 12.4)
13.7.4 Wichtig:
13.7.5 Möglichkeiten:
13.8 Projektplan

14 Conclusio

15 Quellen
15.1 Literaturverzeichnis
15.1.1 Bücher
15.1.2 Präsentationen
15.1.3 Zeitschriften
15.1.4 Internet
15.1.5 Produktbeschreibungen
15.2 Interviews

16 Anhang
16.1 Beispiel
16.1.1 Entscheidungsphase
16.1.2 Auswahlphase
16.1.3 Einführungsphase
16.1.4 Planungs-, Design- und Entwicklungsphase
16.1.5 Durchführungsphase
16.1.6 Wartungsarbeiten
16.1.7 Conclusio
16.2 Zusammenfassung der Interviews
16.2.1 Allgemein:
16.2.2 An Anwender gestellte Fragen:
16.2.3 An Anbieter gestellte Fragen:
16.3 Abbildungsverzeichnis

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 in dieser Leseprobe nicht enthalten

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 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.“^[4]

„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.“^[5]

„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.“^[6]

„Codierung: Der Vorgang des Umsetzens von Zeichen von einem Code in einen anderen Code, wobei sich die Bedeutung der Zeichen nicht ändert.“^[7]

„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.“^[8]

„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.“^[9]

„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.“^[10]

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.“^[11]

GUI: (graphical user interface) Grafische Benutzeroberfläche^[12]

„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.“^[13]

„Integration: Im allg. Sprachgebrauch die Herstellung oder Wiederherstellung eines Ganzen durch Vereinigen oder Verbinden logisch zusammengehörender Teile.“^[14]

„Integrationstest: Test mit dem Ziel, Fehlerwirkungen in Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten zu finden.“^[15]

„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.“^[16]

Komponententest: Test einer Softwareeinheit^[17]

Lasttest: Ein Lasttest dient zur „Messung des Systemverhaltens in Abhängigkeit steigender Systemlast (z.B.: Anzahl parallele Benutzer, Anzahl Transaktionen).“^[18]

„Metrik: Größe zur Messung einer bestimmten Eigenschaft eines Programms oder einer Komponente. Die Ermittlung von Metriken ist Aufgabe der statischen Analyse.“^[19]

„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.“^[20]

„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.“^[21]

„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.“^[22]

„Performanztest (engl. performancetest): Prüfung der Verarbeitungsgeschwindigkeit bzw. Antwortzeit für bestimmte Anwendungsfälle, in der Regel in Abhängigkeit steigender Last.“^[23]

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.“^[24]

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.”^[25]

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”.^[26]

„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.“^[27]

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.”^[28]

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.”^[29]

„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.“^[30]

„Quellcode (Code, Sourcecode): Mit Quellcode bezeichnet man den vom Programmierer (bzw. vielen Programmierern) erstellten Programmcode einer Software als editierbare Datei beispielsweise von ASCII-Zeichen.“^[31]

„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.“^[32]

„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.“^[33]

„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.“^[34]

„Software: (engl. Software) ist der Sammelbegriff für die Systemprogramme (engl. system program) und die Anwendungsprogramme (engl. application program; user program) von Rechnern.“^[35]

„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.“^[36]

„Software-Test: Ein Software-Test dient der Qualitätssicherung eines neu erstellten oder geänderten Softwareprogramms.“^[37]

„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.“^[38]

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.“^[39]

„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.“^[40]

„Tool: Als Tool bezeichnet man ein Programm, das für eine bestimmte Aufgabe erstellt wurde.“^[41]

„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.“^[42]

„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.“^[43]

„Wartung: Die Maßnahmen zur Erhaltung oder Wiederherstellung der Funktionsfähigkeit und Leistungsfähigkeit von Betriebsmitteln ohne grundlegende Änderung von Funktionalität und Leistung.“^[44]

„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.“^[45]

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 in dieser Leseprobe nicht enthalten

Abbildung 2: Testprozess^[46]

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.^[47]

D.h. ob ein Produkt „gute Qualität“ besitzt, entscheidet grundsätzlich allein der Kunde.

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.“^[48]

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.“^[49]

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.“^[50]

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“.

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 in dieser Leseprobe nicht enthalten

Abbildung 3: Das Wasserfall-Modell^[51]

Das V-Modell (Abbildung 4) vermeidet diese Probleme, da es die Testaktivitäten vom ersten Tag an berücksichtigt.^[52]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Das V-Modell^[53]

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.^[54]

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.

3.5 Relative Kosten der Fehlerbehebung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Relative Kosten der Fehlerbeseitigung^[55]

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 100-fachen der Kosten, die bei frühzeitigem Auffinden und Beheben des Fehlers aufgetreten wären. Hier besteht ein, zumeist nicht genutztes Einsparungspotential.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Fehlerverteilung nach Phasen^[56]

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).

4 Automatisiertes Testen

„Der Dumme macht immer die gleichen Fehler.

Der Kluge macht keine Fehler.

Der Intelligente lernt aus den Fehlern, die

andere machen.“

- Plato

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.“^[57]

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.“^[58]

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.

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.^[59]

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.

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.“^[60] Während der Systemtests ist dies weitaus komplexer.

Um zu analysieren, was automatisiert wird, sollte das Testteam folgende Punkte beachten:^[61]

- 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
- 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.^[62]

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.

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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Testskript mit Winrunner^[63] erstellt

5.1.5 Unabhängigkeit von Testfällen

Das Testteam sollte Datenabhängigkeiten zwischen Testfällen vermeiden. Ein Scheitern der Durchführung datenabhängiger Testfälle beeinflusst nachfolgende Testfälle. Es ist zwar nicht immer möglich, dass alle Testfälle an der selben Stelle beginnen, es sollte aber trotzdem versucht werden. Die Testausführung könnte stocken, wenn die Ausführung eines Testfalls nicht abgeschlossen wird und der nächste Testfall vom vorherigen Ergebnis abhängt.

5.1.6 Skriptsprache

Automatisierte Testwerkzeuge liefern meist mehrere Skriptsprachen (z.B.: Das Testwerkzeug SQA Suite unterstützt die Programmiersprachen SQA Basic und Visual Basic). Das Testteam entscheidet welche Skriptsprachen es verwenden möchte und dokumentiert diese Wahl in den Testdesignstandards. Es wählt eine Standardsprache, damit alle Mitglieder des Teams den Code lesen und deuten können.

5.1.7 Datenbanken von Testwerkzeugen

Automatisierte Testwerkzeuge verwenden unterschiedliche Datenbanken (z.B.: Das Testwerkzeug Teststudio verwendet die Datenbanken MS Access und SQL Anywhere). Das Testteam beurteilt die Vor- und Nachteile der unterschiedlichen Datenbanken. Wenn viele Testingenieure gleichzeitig auf die Datenbank zugreifen, empfiehlt es sich eine stabilere Datenbank (z.B.: SQL Anywhere) zu wählen. Falls nur wenige Testingenieure auf die Datenbank zugreifen, reicht auch eine Access-Datenbank.

5.1.8 Vorlagen für Testfälle

Die Vorlage für Testfälle liefert die Struktur für die noch zu erstellenden Tests, vereinfacht das Testdesign und fördert die Konsistenz (d.h. macht es für den nachfolgenden Tester leichter zu lesen) der automatisierten Tests untereinander. Das Testteam erstellt die Vorlage und nimmt sie in die Dokumentation auf.

5.1.9 Namenskonventionen

Komplexe Anwendungen benötigen eine große Anzahl von Testfällen (z.B.: Kunden anlegen). Die Erstellung einer Namenskonvention erleichtert die Verwaltung der Testfälle. Zusätzlich enthält die Namenskonvention möglicherweise auch das geplante Resultat (z.B.: „Kundeanlegen_ok“ oder „Kundeanlegen_nok“).

5.2 Standards für das Design manueller Tests

Wie beim automatisierten Test legt das Testteam auch beim manuellen Test Standards fest und muss sich danach richten.

5.2.1 Namenskonventionen

Auch die automatisierten Testfälle benötigen, wie die manuellen Testfälle, eine Namenskonvention.

5.2.2 Detailliertheit des Testfalls

Das Dokument der Designstandards für manuelle Testfälle enthält eine genaue Beschreibung der Testfälle. Dieses inkludiert auch ein Beispiel wie detailliert ein Testfall zu beschreiben ist. Falls die Zeit für eine ausführliche Beschreibung der Testfälle nicht ausreicht, kann der Testfall auch nur eine kurze Beschreibung enthalten.

5.2.3 Erwartetes Ergebnis

Das Designstandarddokument enthält auch Leitlinien wie das Testteam die erwarteten Ergebnisse dokumentiert.

5.3 Wann rentiert sich Testautomatisierung?

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Return on Investment von Testautomatisierung^[64]

Anhand der Grafik (Abbildung 8) erkennt man, dass Testautomatisierung zu Beginn mehr kostet als das manuelle Testen. Allerdings ändert sich dies ab dem 1. Regressionstest, da das Testteam die bereits erstellten Skripts einfach nochmals startet und der manuelle Aufwand nur geringfügig kleiner wird. Je mehr Regressionstests das Testteam durchführt, desto mehr rentiert sich Testautomatisierung.

Das Testteam erachtet Testautomatisierung als sinnvoll bei einer technischen Machbarkeit der Automatisierung unter vertretbaren Aufwänden. Jedoch treffen manche Unternehmen strategische Entscheidungen, die trotzdem für eine Testautomatisierung sprechen.

Die befragten Hersteller gaben an, dass in der Praxis das Testteam den ROI (Return on Investment, Kapitalrentabilität) berechnet um die Effektivität der Testsoftware festzustellen. Die genaue Berechnung befindet sich im Kapitel 6. Sie gaben weiters an, dass die Kosten des Testens im Allgemeinen zwischen 10 und 30 Prozent (Österreich ca. 10%) des Entwicklungsaufwands betragen. Hier besteht auch das Einsparungspotential, da man mit 10% manuellem Testaufwand und Testautomatisierung, die gleichen Ergebnisse wie bei 30% manuellen Testaufwand erzielt.

5.4 Beispiel: Unterschied manueller und automatisierter Test

Das folgende kleine Beispiel hilft, den Unterschied zwischen dem Aufwand eines manuellen Tests und dem automatisierten Test zu erkennen. Das Beispiel unterteilt sich in folgende Punkte:^[65]

5.4.1 Feststellen des Aufwands für Testautomatisierung

Zu Beginn stellt das Testteam den Aufwand der Testautomatisierung fest. Unter der Annahme, dass das Team vier Regressionstests pro Jahr durchführt, bei denen jeweils vier Personen drei Wochen lang ganztägig arbeiten, errechnet sich folgender Aufwand für die Automatisierung:

Abbildung in dieser Leseprobe nicht enthalten

5.4.2 Schätzung der reinen Ausführungszeit

Bei der reinen Ausführungszeit handelt es sich um die Zeit, in der ein Tester Testfälle ausführt und versucht Unterschiede mit den Anforderungen festzustellen. Nicht zur reinen Ausführungszeit gehören die Analyse der Unterschiede und die Suche nach der Ursache. Im Beispiel von 240 Arbeitstagen jährlich wird die reine Ausführungszeit auf ein Viertel geschätzt, also auf 60 Arbeitstage im Jahr.

5.4.3 Erstellen einer Schätzung für folgende Voraussetzungen

Die automatisierte Durchführung des ersten Tests kostet durchschnittlich X-mal soviel Zeit wie eine manuelle Durchführung (im Beispiel nehmen wir X=2, also automatisiert = manuell * 2), dafür ist automatisiertes Regressionstesten Y-mal schneller als manuelles Testen (im Beispiel nehmen wir Y=4, automatisiert = manuell / 4).

5.4.4 Berechnen des möglichen Zeitgewinns

Um den Zeitgewinn zu berechnen, benötigt das Testteam folgende Angaben:

- manuell = 60 Arbeitstage pro Jahr oder 15 Arbeitstage je Regressionstest
- automatisiert = (erster Teil kostet doppelt soviel: 15*2) + (Regressionstests sind viermal schneller: 3x15/4) = 41 Arbeitstage im ersten Jahr und (4x15/4) = 15 Arbeitstage in jedem weiteren Jahr
- Der Nutzen ist der Unterschied, also 19 Arbeitstage (60-41) im ersten Jahr und 45 Arbeitstage (60-15) in jedem weiteren Jahr.

Durch die grafische Darstellung der Berechnungen kann das Testteam den Break-Even-Punkt bestimmen. Aus der Grafik (Abbildung 9) geht hervor, ab wann sich Testautomatisierung im Vergleich zum manuellen Testen rentiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Kosten der Testdurchführung^[66]

5.4.5 Schätzen der Kosten und des Nutzens eines Tools

Zu den Kosten gehören die Anschaffung des Tools, Schulungen, das Einrichten des Tools und die Aktualisierung der Skripts bei Änderungen (Aktualisierung von automatisierten Skripts braucht weniger Zeit als die Aktualisierung von manuellen Skripts).

Zum Nutzen gehören die höhere Qualität von automatisierten Tests (Verlust der Aufmerksamkeit bei der Durchführung des x-ten Regressionstests), höhere Motivation und Produktivität des Personals (ein Tool verleiht dem Testen eine neue Dimension, es macht möglicherweise mehr Spaß) sowie die schnellere Durchlaufzeit.

Zu den Aufgaben des Testteams gehört das Einschätzen dieser Faktoren, wobei das Aktualisieren viel Aufwand erfordert und auch schwer vorhersehbar ist.

5.4.6 Erstellen eines vollständigen Kosten-Nutzen-Vergleichs

Der Vergleich beinhaltet viele Annahmen, vermittelt jedoch ebenfalls eine Grundlage für eine weitere Begründung. Häufig stellen sich die Erwartungen als viel zu hoch heraus. Allerdings kann der Vergleich auch für normale Tests anstelle von Regressionstests durchgeführt werden. Zu berücksichtigen ist dabei, dass die erste Testdurchführung in der Regel zweimal solange dauert wie ein erneuter Test und dass nicht alle Tests einen erneuten Test zur Folge haben werden.

Es ist wichtig, dass Kosten und Nutzen in regelmäßigen Zeitabständen überprüft werden. Dabei muss angegeben werden, ob der Break-Even-Point bereits erreicht worden ist oder nicht. Zu veranschlagen sind dafür Kosten wie Einrichtung des Tools und Ausbildungen sowie die für den Einsatz des Tools bestimmten Gemeinkosten und den Zeitgewinn.

6 Kosten-Nutzen-Analyse

Die Entscheidung zur Durchführung eines Projekts wird nach dem Vergleich des zu erwartenden Nutzens und der erwarteten Kosten getroffen. Üblicherweise muss sich ein neues Softwaresystem in fünf Jahren amortisiert haben. In der Startphase wird ein bestimmter Nutzen angenommen und während des Projekts nicht weiter verfolgt. Ein Change-Management-Verfahren macht Veränderungen bei den Kosten nachvollziehbar. Für den Nutzen fehlt diese Möglichkeit allerdings.^[67]

Eine Kosten-Nutzen-Analyse des Qualitätsmanagements dient der Bewertung der Wirtschaftlichkeit des Qualitätsmanagements durch die Gegenüberstellung der Kosten als negative und des Nutzens als positive finanzielle Konsequenzen.^[68]

6.1 Erfassung der Kosten des Qualitätsmanagements

Die Kosten des Qualitätsmanagements entstehen aufgrund von Aktivitäten zur Gewährleistung einer Leistungserstellung gemäß den Kundenanforderungen.^[69]

6.1.1 Grundproblematik der Kostenerfassung

Um die Kosten qualitätsbezogen zu erfassen, müssen die Aktivitäten im Unternehmen verursachungsgerecht bewertet werden. Dabei unterscheidet man zwei Arten von qualitätsbezogenen Aktivitäten. Dies sind die isolierten Qualitätsaktivitäten und die integrierten Qualitätsaktivitäten.

6.1.1.1 Isolierte Qualitätsaktivitäten:

Isolierte Qualitätsaktivitäten dienen nur dem Qualitätsmanagement. Die daraus entstehenden Kosten können leicht identifiziert und direkt den Kosten des Qualitätsmanagement zugerechnet werden.^[70]

6.1.1.2 Integrierte Qualitätsaktivitäten:

Der größte Teil der qualitätsbezogenen Aktivitäten im Unternehmen sind integrierte Qualitätsaktivitäten. Die darauf zurückführbaren Kosten können in direkte und indirekte Kosten unterteilt werden.^[71]

Die direkten Kosten des Qualitätsmanagements lassen sich auf qualitätsbezogene Aktivitäten in der entsprechenden Abteilung zurückführen (z.B.: Durchführung einer Kundenbefragung durch die Marktforschung).^[72]

Die indirekten Kosten des Qualitätsmanagements entsprechen Kosten, die aufgrund der Durchführung qualitätsbezogener Aktivitäten in der jeweiligen Abteilung (z.B.: Arbeitsausfall von Mitarbeitern, die an einer qualitätsbezogenen Schulungsmaßnahme teilnehmen) auftreten. Die Kosten, die bei den integrierten Qualitätsaktivitäten anfallen, unterteilt man in qualitätsbezogene Einzel- und Gemeinkosten.^[73]

Die qualitätsbezogenen Einzelkosten (z.B.: Kosten aufgrund des Zeitaufwands zu schulender Mitarbeiter) können der Kostenstellenrechnung entnommen werden. Im Gegensatz dazu lassen sich die qualitätsbezogenen Gesamtkosten (z.B.: Kosten, die durch den Zeitaufwand der Mitarbeiter für Qualitätsprüfungen entstehen) nicht aus der Kostenstellenrechnung entnehmen, da die anfallenden Kosten von den Kostenstellenkosten nicht getrennt betrachtet werden können. Außerdem können die einzelnen Tätigkeiten nicht detailliert analysiert werden um Ansatzpunkte für eine Kostenoptimierung und eine Wirtschaftlichkeitsverbesserung zu identifizieren.

Die Kostenstellenrechnung ist zur Erfassung und Optimierung der Kosten des Qualitätsmanagements nur teilweise geeignet. Aufgrund des Gemeinkostencharakters eines Teils der Kosten des Qualitätsmanagements, stellt die qualitätsbezogene Prozesskostenrechnung ein weiteres Instrument zu ihrer Ermittlung dar.^[74]

[...]

---

^[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.

^[4] Pol, Martin / Koomen, Tim / Spillner, Andreas : Management und Optimierung des Testprozesses, 1.A., Heidelberg, dpunkt.verlag, 2000, S. 523.

^[5] Net-Lexikon: http://www.net-lexikon.de (13.04.2004)

^[6] Pol / Koomen / Spillner (2000), S. 523.

^[7] Heinrich, Lutz / Heinzl, Armin / Roithmayr, Friedrich : Wirtschaftsinformatik, 7.A., München / Wien, R. Oldenbourg Verlag, 2004, S. 151.

^[8] Pol / Koomen / Spillner (2000), S. 524.

^[9] Heinrich / Heinzl / Roithmayr (2004), S. 662.

^[10] Wallmüller, Ernest : Software-Qualitätsmanagement in der Praxis, München, Hanser, 2001, S. 441.

^[11] Spillner, Andreas / Linz, Tilo : Basiswissen Softwaretest, 2. Auflage, Heidelberg, dpunkt.verlag, 2004, S. 203.

^[12] Spillner / Linz (2004), S. 204.

^[13] Net-Lexikon: http://www.net-lexikon.de (13.04.2004)

^[14] Heinrich / Heinzl / Roithmayr (2004), S. 333.

^[15] Spillner / Linz (2004), S. 204.

^[16] Gates / Bill : Digitales Business – Wettbewerb im Informationszeitalter, München, Hanser Verlag, 1999.

^[17] Spillner / Linz (2004), S. 205.

^[18] Spillner / Linz (2004), S. 206.

^[19] Spillner / Linz (2004), S. 207.

^[20] Pol / Koomen / Spillner (2000), S. 526.

^[21] Heinrich / Heinzl / Roithmayr (2004), S. 466.

^[22] Net-Lexikon: http://www.net-lexikon.de (13.04.2004)

^[23] Spillner / Linz (2004), S. 208.

^[24] Zehnder, Carl August : Informatik-Projektentwicklung, vdf Hochschulverlag AG, Zürich, 2001, S. 19.

^[25] Deutsche Gesellschaft für Qualität (1995) S.141.

^[26] Deutsche Gesellschaft für Qualität (1995) S.97.

^[27] Wallmüller (2001), S. 442.

^[28] Deutsche Gesellschaft für Qualität (1995) S.95.

^[29] Deutsche Gesellschaft für Qualität (1995) S.108.

^[30] Wallmüller (2001), S. 443.

^[31] Net-Lexikon: http://www.net-lexikon.de (13.04.2004)

^[32] Pol / Koomen / Spillner (2000), S. 527.

^[33] Wallmüller (2001), S. 443.

^[34] Spillner / Linz (2004), S. 210.

^[35] Hansen, Hans Robert: Wirtschaftsinformatik I, 7.A., Stuttgart: Lucius & Lucius 1996, S.170

^[36] Net-Lexikon: http://www.net-lexikon.de (13.04.2004)

^[37] Net-Lexikon: http://www.net-lexikon.de (13.04.2004)

^[38] Pol / Koomen / Spillner (2000), S. 527.

^[39] Pol / Koomen / Spillner (2000), S. 529.

^[40] Pol / Koomen / Spillner (2000), S. 529.

^[41] Net-Lexikon: http://www.net-lexikon.de (13.04.2004)

^[42] Wallmüller (2001), S. 445.

^[43] Wallmüller (2001), S. 446.

^[44] Heinrich / Heinzl / Roithmayr (2004), S. 707.

^[45] Pol / Koomen / Spillner (2000), S. 530.

^[46] Spillner / Linz (2004), S. 18.

^[47] Vgl. Bartsch-Beuerlein, Sandra : Qualitätsmanagement in IT-Projekten, München/Wien, Hanser, 2000, S. 19.

^[48] Myers, G. J. : Methodisches Testen von Programmen, München, Oldenbourg 1989, S. 4.

^[49] Pol / Koomen / Spillner (2000), S. 9.

^[50] Einstieg zum Thema Testen: http://www.visek.de/?10759 (01.03.2004).

^[51] Spillner / Linz (2004), S. 17.

^[52] Vgl. Siedersleben, Johannes : Softwaretechnik, 2. Auflage, München / Wien, Carl Hanser Verlag, 2003, S. 290.

^[53] V-Modell, 1997: Entwicklungsstandard für IT-Systeme des Bundes, Vorgehensmodell, Allgemeiner Umdruck Nr.250/1, BWB IT 15, Juni 1997

^[54] Vgl. Pol / Koomen / Spillner (2000), S. 19.

^[55] Piesche, Manfred / Muhr Wilfried : Testautomatisierung am Beispiel von Rational Teamtest, TÜV Informationstechnik GmbH (25.09.2003), S. 5.

^[56] Bender, Richard : The business case for software quality: www.benderrbt.com/Bender-Business Case For Software Quality-061703-Distribution.pdf (31.03.2004).

^[57] Dustin, Elfriede / Rashka, Jeff / Paul, John : Software automatisch testen, Berlin / Heidelberg / New York, Springer, 2001, S. 4.

^[58] Dustin / Rashka / Paul (2001), S. 4.

^[59] Vgl. Dustin / Rashka / Paul (2001), S. 4.

^[60] Dustin / Rashka / Paul (2001), S. 302.

^[61] Vgl. Dustin / Rashka / Paul (2001), S. 305-306.

^[62] Vgl. Dustin / Rashka / Paul (2001), S. 308-311.

^[63] Winrunner ist ein Produkt von Mercury-Interactive

^[64] Piesche / Muhr (2003), S. 13.

^[65] Vgl. Pol / Koomen / Spillner (2000), S. 120-122.

^[66] Pol / Koomen / Spillner (2000), S. 121.

^[67] Vgl. Gesellschaft für Informatik e.V. : Softwaretechnik-Trends, Band 23 Heft 4, November 2003, S. 7.

^[68] Vgl. Bruhn, Manfred : Wirtschaftlichkeit des Qualitätsmanagement, Berlin, Springer, 1998, S. 104.

^[69] Vgl. Stauss, B. : Dienstleistungsqualität contra Kostensenkung?, in: Betriebswirtschaftliche Blätter, 41. Jg., Nr. 2, 1992, S. 112.

^[70] Vgl. Bruhn, Manfred / Georgi, Dominik : Kosten und Nutzen des Qualitätsmanagements, München / Wien, Hanser, 1999, S. 99.

^[71] Vgl. Bruhn (1998), S. 167.

^[72] Vgl. Bruhn / Georgi (1999), S. 100.

^[73] Vgl. Bruhn / Georgi (1999), S. 100.

^[74] Vgl. Porter, L.J. / Rayner, R. : Quality Costing for Total Quality Management, in: International Journal of Productuin Economics, Vol. 27, 1992, S. 75.