Methoden und Vorgehensweisen im Softwaretestprozess
Literaturauswertung für das Schwerpunktprojekt „V²b IT“
am IWT im Rahmen der kooperativen Forschung
Maximilian Köppel (B.Eng.)
IWT Wirtschaft und Technik GmbH
Friedrichshafen, den 01.04.2014
Gefördert von der Zeppelin-Stiftung im Rahmen des
Innovationszentrums Fallenbrunnen
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
I
Kurzfassung
Im Rahmen der kooperativen Forschung am Innovationszentrum Fallenbrunnen entstand
das Schwerpunktprojekt „Verifikation und Validation bedienergeführter IT unter
Wirtschaftlichkeitsaspekten“. Als Basis für dieses Projekt ist die einschlägige Literatur
hinsichtlich anerkannter Methoden und Best-Practice-Ansätze rund um das Thema
Softwaretest und Testautomatisierung zu sichten. In dieser Veröffentlichung sollen nun
ausgewählt Vorgehensweisen und Denkarten innerhalb von Softwaretestprojekten vorgestellt
werden.
Ein wesentlicher Schwerpunkt des Textes ist zuerst die Identifizierung verschiedener
Faktoren, die Einflüsse auf die Teilprozesse bei der Entwicklung von Software ausüben. Es
wird herausgestellt, welche Kriterien sich auf die Testkosten und auf die Fehlerkosten
auswirken. Auch vorwiegend qualitative Einflussnehmer werden erläutert und abschließend
das Risiko für alle Bereiche bewertet.
Ein weiterer Schwerpunkt liegt auf einer Methode zur Schätzung der Aufwände für den Test,
da hier durch den langen Personaleinsatz schnell hohe Kosten entstehen. Die vorgestellte
Vorgehensweise ist die COCOMO-II Methode, die anhand verschiedener, unternehmens-
und projektspezifisch zu ermittelnder Faktoren eine detaillierte und quantifizierte Aussage
zum Testaufwand macht.
Einen abschließenden Blick wirft diese Veröffentlichung auf die Einschätzung des
Testprozesses selbst. Mit dem sogenannten Test Maturity Model (TMM), einem Modell zur
Beurteilung des Reifegrades, wird eine Aussage gemacht, wie sicher und systemisch der
Testprozess implementiert ist. Eine detaillierte und spezifisch anpassbare Aktivitätenliste
zum Thema Softwaretest, Testautomatisierung und auch zu deren Einführung rundet dieses
Kapitel ab. Der Ansatz der Aufwands- und Tätigkeitsverteilung innerhalb eines Projektes zur
Prozessabbildung wird auch im Forschungsvorhaben des IWT umgesetzt.
Abschließend lässt sich sagen, dass die Mehrzahl der Guidelines, Methoden und
Vorgehensweisen sehr stark auf qualitativen Aussagen beruht. Es werden wenige, valide
und exakt quantifizierte Kalkulationshilfen oder Formeln vorgestellt. Ein weiteres Fazit ist der
systemische Ansatz: Softwaretest ist Teil des Entwicklungsprojektes, keine nachgeschaltete
Aktivität. Nur bei der Abstimmung des gesamten Produktentwicklungsprozesses auf den
Test und die Testautomatisierung, ist ein Projekterfolg wahrscheinlich.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
II
Inhaltsverzeichnis
1. Einleitung ........................................ .............................................................................. 1
2. Literaturübersicht - Fachbücher ................... .............................................................. 3
2.1. A. Spiller/T. Linz „Basiswissen Softwaretest“ ........................................................... 3
2.1.1. Testkostenbeeinflussende Faktoren: ................................................................ 3
2.1.2. Fehlerkosten .................................................................................................... 4
2.1.3. Qualitative Faktoren mit Einfluss auf die Testautomatisierung .......................... 5
2.1.4. Risikoanalyse ................................................................................................... 6
2.2. Sneed/Baumgartner „Der Systemtest“ ..................................................................... 7
2.2.1. Einführung in den Systemtest ........................................................................... 7
2.2.2. Notwendigkeit des Testens .............................................................................. 7
2.2.3. Testplanung ..................................................................................................... 9
2.2.4. Schätzung der Testaufwände mit COCOMO-II ................................................10
2.2.5. Wartung und Weiterentwicklung ......................................................................14
2.2.6. Testautomatisierung – Ausbaustufen und Alternativen ....................................14
2.2.7. Testmanagement ............................................................................................16
2.3. Seidl/Baumgartner „Basiswissen Testautomatisierung“ ..........................................17
2.3.1. Der fundamentale Testprozess .......................................................................17
2.3.2. Automatisierte Testdurchführung ....................................................................17
2.3.3. Softwarequalitätskriterien ................................................................................18
2.3.4. Integration von Testautomatisierung in die Organisation .................................20
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
III
2.4. Dustin/Rashka/Paul „Software automatisch testen“ ................................................24
2.4.1. Test Maturity Model (TMM) .............................................................................24
2.4.2. Testteam-Management ...................................................................................26
2.4.3. Wartungsfreundliche Testverfahren .................................................................30
2.4.4. Aufgaben im Softwaretest ...............................................................................32
2.5. Dowie „Testaufwandsschätzung in der Softwareentwicklung“ ................................39
3. Literaturübersicht – Paper und Fachartikel ........ .......................................................41
3.1. Hoffman – „Cost Benefits Analysis of Test Automation“ .........................................41
3.2. Schmid et. al – „Wann lohnt sich die Automatisierung von Tests?“ .........................44
4. Zusammenfassung ................................... ...................................................................47
5. Literaturverzeichnis .............................. ......................................................................48
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
1
1. Einleitung
IT-Systeme müssen heute kostengünstig und zuverlässig getestet werden können. Ein
Ansatz hierfür ist der Einsatz von geeigneten Testwerkzeugen und die zunehmende
Automatisierung.
Nicht selten wird dabei jedoch der tatsächlich entstehende Testaufwand für manuelle wie
automatisierte Tests falsch eingeschätzt. Somit kann der Break-Even einer möglichen oder
ggf. erweiterten Testautomatisierung nicht valide eingeschätzt werden.
Eine zentrale Frage, die sich stellt ist also folgende: In welchem Umfang sollte manuell oder
automatisiert getestet werden und wie erreicht man das optimale Verhältnis von
Ressourceneinsatz zu Testergebnis?
Um diese Fragestellung aussagekräftig zu beantworten, fehlt es an praxisnahen,
verwendbaren Leitlinien für den automatisierten Softwaretest. Bestehende Ansätze in der
Literatur haben sich vorwiegend qualitativ an das Thema Wirtschaftlichkeit der
Testautomatisierung angenähert. Das IWT als Träger des Innovationszentrums
Fallenbrunnen an der DHBW Ravensburg Campus Friedrichshafen hat es sich ausgehend
von dieser Problemsituation zur Aufgabe gemacht, bedarfsorientierte und valide Guidelines
für den automatisierten Softwaretest unter Wirtschaftlichkeitsaspekten zu entwickeln.
Um einen Einstieg in dieses Forschungsvorhaben zu finden, und die angestrebte Praxisnähe
und Umsetzbarkeit der Ergebnisse zu gewährleisten, wurden in Interviews mit
Industrieunternehmen Fragestellungen ermittelt, die im Zusammenhang mit der
Projektierung von Softwaretests entstehen. Im Folgenden sind einige dieser Fragestellungen
aufgelistet:
• Wie erstellt man eine belastbare Kalkulation der Budgets bezogen auf ein
Testautomatisierungsprojekt?
• Welche Faktoren spielen dabei eine Rolle?
• Wie oft muss ein automatisierter Test wiederholt werden, bis sich der
Automatisierungsaufwand amortisiert?
• Wie findet man leicht zu automatisierende und somit sich schnell amortisierende
Testfälle?
• Gibt es „best-practice“ Empfehlungen zur Projektierung von Softwaretest und
Testautomatisierung?
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
2
• Was sind besonders starke Kostentreiber?
• Welche Faktoren bergen das höchste Risiko für das Projekt?
• Wie gestalten sich die tatsächlichen Aufwände der Testaktivitäten?
• Wie viel Testaufwand ist angemessen?
• Wann übersteigt der Aufwand den möglichen Nutzen?
• Welche Fehlerkosten zieht ein Verzicht auf weitere Prüfungen und Tests nach sich?
[SPIL]
Um ein erstes Bild über das angestrebte Forschungsfeld zu gewinnen, ist ein detaillierter
Blick auf die fragenrelevante Fachliteratur zu werfen. Zu diesem Zweck wurden zum einen
Fachbücher mit Zusammenhang zu den Bereichen Softwaretest, Testautomatisierung,
Softwarequalität und Testaufwandsschätzung ausgewertet. Darüber hinaus existiert auch
eine Vielzahl an Fachartikeln, White Paper und sonstigen Werken in Vortrags- oder
Tagungsbänden. Informationstechnologie ist ein sich schnell entwickelnder Sektor, sodass
diese in kürzeren Zyklen erscheinenden Beiträge mindestens ebenso wertvolle
Informationen liefern und daher in dieser Übersicht nicht fehlen dürfen.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
3
2. Literaturübersicht - Fachbücher
2.1. A. Spiller/T. Linz „Basiswissen Softwaretest“
Für die Prozesse rund um den Softwaretest, bzw. die Testautomatisierung im Speziellen,
fehlen vielfach Normen und Standards. Es gibt geradezu eine Vielzahl von Modellen zur
Prozessstrukturierung und zur Art und Weise der Projektierung.
2.1.1. Testkostenbeeinflussende Faktoren:
Nach Spillner und Linz 2010 mit dem Titel „Basiswissen Softwaretest“, nachzulesen auf den
Seiten 186f:
Reifegrad des Entwicklungsprozesses
• Stabilität der Organisation
• Fehlerhäufigkeit der Entwickler
• Rate der Softwareänderungen
• Zeitdruck durch unrealistische Pläne
• Gültigkeit, Bestand und Aussagekraft von Plänen
• Reife des Testprozesses und Disziplin bei Konfigurations-, Änderungs- und
Fehlermanagement
Qualität und Testbarkeit der Software
• Anzahl, Schwere und Verteilung der Fehler in der Software
• Qualität, Aussagekraft und Aktualität der Dokumentation und anderer testrelevanter
Informationen
• Größe und Art der Software und Systemumgebung
• Komplexität der Anwendungsdomäne und der Software
Testinfrastruktur
• Verfügbarkeit von Testwerkzeugen
• Verfügbarkeit von Testumgebung und Testinfrastruktur
• Verfügbarkeit und Bekanntheit von Testprozess, Standards und Verfahren
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
4
Mitarbeiterqualifikation
• Erfahrung und Know-How der Tester bzgl. „Testen“
• Erfahrung und Know-How der Tester bzgl. „Testwerkzeugen“ und „Testumgebung“
• Erfahrung und Know-How der Tester bzgl. „Testobjekt“
• Zusammenarbeit Tester-Entwickler-Management-Kunde
Qualitätsziele
• Angestrebte Testabdeckung
• Angestrebte Restfehlerrate bzw. Zuverlässigkeit nach dem Test
• Anforderungen an die Systemsicherheit
• Anforderungen an die Testdokumentation
Teststrategie
• Testziele (abgeleitet aus den Qualitätszielen) und Mittel zur Zielerreichung, u.a.
Anzahl und Umfang der Teststufen (Komponenten-, Integrations- und Systemtest,
usw.)
• Wahl der Testmethoden (Blackbox- oder Whitebox-Verfahren)
• Zeitliche Planung der Tests (Beginn und Durchführung der Testarbeiten im Projekt
bzw. im Softwarelebenszyklus)
2.1.2. Fehlerkosten
Bei den Fehlerkosten werden zum einen direkte Fehlerkosten definiert. Diese entstehen
durch die Fehlwirkung des Produktes. Wenn es sich um eine sicherheitsrelevante Software,
bspw. im Bereich der Avionik handelt, kommen ggf. große Summen an
Schadenersatzansprüchen zusammen. Vor allem aber sind direkte Fehlerkosten auch die
Summe der Kosten, die durch das Neueinspielen der überarbeiteten Software bei allen
Anwendern entstehen. Auch hier gibt es wieder unternehmensspezifische
Kritikalitätsbewertungen: Ein Systemhersteller, der sehr spezialisierte Software mit einem
sehr engen Kundenkreis anbietet, wird hier sehr wahrscheinlich mit wesentlich geringeren
Kosten konfrontiert, als etwa ein Anbieter, der z.B. im B2C-Bereich Software für PC-Nutzer
vertreibt und dann Millionen Geräte erreichen muss.
Zum anderen unterscheidet man bei den Fehlerkosten die indirekten Fehlerkosten: Hierzu
gehören die Kosten, die nur indirekt, bzw. als Folge aus dem eigentlichen Fehler entstehen.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
5
Dies kann etwa der Umsatzverlust des Herstellers durch unzufriedene Kunden sein, oder der
Verlust von Zulassungen bei z.B. sicherheitskritischer Software.
Als Fehlerkorrekturkosten bezeichnet die Literatur noch die Kosten, welche durch die
notwendige Fehleranalyse und Korrektur entstehen. Schließlich muss nach der Meldung
eines Fehlers zuerst ein umfassender Softwaretest zur Lokalisierung des Fehlers erfolgen.
Nach der Überarbeitung des Quellcodes wiederum schließt sich ein Regressionstest zur
Überprüfung des Systems mit geänderter Komponente an. Bei sehr großen und komplexen
Systemen können die Fehlerkorrekturkosten kritische Ausmaße annehmen. ([SPIL], S. 186 f)
2.1.3. Qualitative Faktoren mit Einfluss auf die Te stautomatisierung
In dieser Quelle wird eine Übersicht über die Qualitativen Faktoren getroffen, die eine
Auswirkung auf die Automatisierung von Testabläufen haben. Zu bemerken ist, dass die hier
ausgewertete Quelle auch ausschließlich qualitative Faktoren benennt. Konkrete
Zahlenwerte zur Beurteilung der Entscheidung der Frage nach der Testautomatisierung
lassen sich nicht finden.
• Regressionstests: Die Kostenersparnis durch automatisiertes Testen steigt mit der
Anzahl der Testfallwiederholungen.
• Lifecycle: Die Lebensdauer des Testobjektes und der Entwicklungszeitraum des
Systems üben Einfluss auf den möglichen Amortisationszeitraum aus.
• Entwicklungszyklus: Wie oft und wie schnell werden Iterationen durchlaufen? Bietet
der Entwicklungsprozess die Möglichkeit, zu Automatisieren oder sind die Schleifen
zeitlich zu kurz?
• Bedienbarkeit und Automatisierbarkeit: Manche Abläufe lassen sich nicht manuell,
andere nicht automatisiert testen.
• Kombinatorik: Die Möglichkeit, automatisiert gleiche Abläufe mit unterschiedlichen
Daten zu testen, kann einen Qualitätszugewinn bringen. Außerdem: Wenn nur eine
andere Datengrundlage eingearbeitet werden muss, kann bei entsprechendem
Testaufbau eine signifikante Kostenoptimierung im Vergleich zur manuellen
Abarbeitung des Tests erreicht werden.
• Fehleranfälligkeit: Automatisierte Abläufe liefern gleichbleibende Qualität, bei
manuellen Mehrfachtests bleibt der Tester als Risikofaktor durch z.B. schwindende
Aufmerksamkeit.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
6
• Fehlerfindung: Findet keine Beeinträchtigung der bestehenden Funktionalität durch
die Änderungen am Testobjekt statt? (Regressionstest)
([SPIL], S. 186 f)
2.1.4. Risikoanalyse
Nach der Betrachtung der Test- und Fehlerkosten gilt es noch, einen Blick auf die
Entwicklung des Risikos zu werden, welches ein Fehler für das Softwareprojekt mit sich
bringt. Die nachfolgen Auflistung gibt einen Überblick über Einflussfaktoren auf das
Fehlerkostenrisiko (Spillner und Linz 2010):
• Art und Größe des Softwareproduktes (Bsp.: Smartphone-App oder ERP-System)
• Art und Branche des Kunden (Bsp.: Militärluftfahrt oder Consumer-Anwendung)
• Anzahl der betroffenen Installationen bzw. Endanwender
• Individualsoftware oder Standardsoftware
• Werkzeug vorhanden? (Kosten für Beschaffung, Wartung der Werkzeuge, Hardware,
Schulung der Mitarbeiter; auch beim manuellen Test)
• Softwareprodukt geeignet? Bzw. könnte man überhaupt manuell Testen? (Embedded
Controller, GUI, Bedienereingaben etc.)
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
7
2.2. Sneed/Baumgartner „Der Systemtest“
2.2.1. Einführung in den Systemtest
Gerade in Großbetrieben geht der Trend hin zu unabhängigen Abteilungen für den
Systemtest. Die Existenz dieser großen Kapazitäten für den Test hat einen ganz
wesentlichen Grund darin, dass heutige Projekte derart komplex und zeitlich begrenzt sind,
dass sie ohne Outsourcing-Prozesse nicht bewältigt werden können. Dem
Generalunternehmer bzw. Unterauftraggeber obliegt aber weiterhin die Pflicht, „die
Anforderungen zu spezifizieren und das fertige System abzunehmen.“ ([SNE], S.3) Dieser
Prozess umfasst das Abprüfen des kompletten Systems gegen die Gesamtheit der
Projektanforderungen. ([SNE], S.3)
2.2.2. Notwendigkeit des Testens
Seit Jahrzehnten werden Technologien für die Softwareprojektumgebung erforscht und
entwickelt, die entweder „Fehlerfreiheit gewährleisten oder zumindest die Fehleranzahl
drastisch reduzieren.“ ([SNE], S.6) Als Beispiele sind in der Quelle etwa die strukturierte/
regelbasierte/ objektorientierte Programmierung, CASE-Tools oder die modellgetriebene
Entwicklung genannt.
Die Geschichte der Softwareentwicklung hat aber auch gezeigt, dass sich trotz dieser
Maßnahmen die Fehlerrate pro 1000 Anweisungen nicht verringert hat. ([SNE], S.6) Hinzu
kommt, dass Software immer mehr Funktionen übernimmt. Diese Funktionalität von IT-
Systemen wächst „multiplikativ von Jahr zu Jahr, so dass trotz codesparender Maßnahmen
die absolute Zahl der Softwarefehler ständig steigt.“ ([SNE], S.6)
Ein in dieser Quelle zitierter Bericht des Bundesministeriums für Bildung und Forschung
(BMBF) aus dem Jahre 2001 äußert folgende Zahlen: Der Wert aller Softwaresysteme in der
dt. Industrie beläuft sich auf 25 Mrd. Euro. Hinter diesem Wert verbergen sich ca. 1,25 Mrd.
Anweisungen im Code. Ein weiterer, greifbarer Zahlenwert ist die Anzahl der Fehler in der
Software. Diese Fehlerrate liegt bei ausgelieferter Software ca. bei 1 bis 3 Fehlern pro 1000
Anweisungen. Gerechnet auf das Jahr 2001 ergibt sich so eine Fehleranzahl von insgesamt
3,75 Mio. Softwarefehlern. Eine in dieser Quelle zitierte, weitere Studie gibt an, dass für die
Behebung eines Fehlers nach der Freigabe im Schnitt 13 Stunden benötigt werden.
Mit den damaligen Werten für den Stundenpreis (50,- €) kostet allein die Korrektur eines
Softwarefehlers nach der Auslieferung 650,- €. Skaliert auf die Gesamtanzahl der
Softwarefehler ergibt sich ein Wert von 2,4 Mrd. €. Diese Kosten in Höhe von knapp 10%
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
8
des Gesamtwertes der existierenden Software würden durch eine Behebung der nach
Auslieferung vorhandenen Fehler entstehen.
Greift man dann die Überlegung auf, dass im Integrations- und Systemtest vielleicht 50% der
Fehler entdeckt werden können – und dies zu wesentlich geringeren Aufwänden von ca. 4
Stunden – so ergeben sich bei gleichem Stundensatz Gesamteinsparungen von 1,6 Mrd. €.
Es gilt zu beachten, dass in der gesamten Kostenbetrachtung ausschließlich die direkten
Fehlerkosten berücksichtigt werden. Die indirekten Fehlerkosten, die beispielsweise in der
nachgelagerten Produktion, durch Rückrufaktionen, notwendige Updates oder auch den
Imageverlust entstehen, steigern die totalen Kosten eines Fehlers nochmals um ein
Vielfaches. (S. 6f) Auch die gravierenden Entwicklungen in der IT-Branche seit der
Publikation des BMBF – immerhin 13 Jahre – lassen auf aktuell noch größere Umfänge und
Potentiale bei der Optimierung im Softwaretest schließen.
Ein Blick unter der Rubrik „Notwendigkeit des Testens“ gilt auch der Klassifizierung der
Fehler. Hier muss unterschieden werden in z.B. tolerierbare Fehler (Klasse IV „störende
Fehler“) und Fehler, die nicht im freigegebenen Produkt enthalten sein dürfen (Klasse I
„fatale Fehler“). Eine Übersicht über die vier definierten Fehlerklassen liefert nachfolgende
Abbildung.
Abbildung 1: Fehlerklassen ([SNE], S. 264)
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
9
2.2.3. Testplanung
Die Grundlage für eine eigenständige Testplanung ist damit geschaffen, dass der
Softwaretest heute wie ein eigenständiges Projekt gehandhabt wird, das parallel zu einem
Entwicklungs-, Integrations- oder Installationsprojekt läuft. Ergo muss der Test als Projekt
„definiert, kalkuliert, organisiert und geplant“ werden ([SNE], S.65).
Die Voraussetzung für die Durchführung des Tests ist das Erstellen und Freigeben des
Testplans. Hier sind die Ziele, Termine, Umfänge etc. festgelegt. Einen kompakten Überblick
über die in der Testplanung zu klärenden Fragen geben die sogenannten „7 Ws“:
• Was: Welche Objekte und Funktionen sind zu testen?
• Warum: Welche Ziele verfolgt der Test?
• Wann: Welche Termine gelten für welche Lieferungen und Leistungen?
• Wo: Wo soll das System getestet werden?
• Wie: Unter welchen Bedingungen soll das System getestet werden?
• Womit: Mit welchen Mitteln bzw. Werkzeugen soll getestet werden?
• Von Wem: Welches Personal führt den Systemtest durch? (S. 66)
Eine erfolgreiche Testplanung setzt in verschiedenen Teststufen das Vorhandensein
verschiedener Informationen voraus. Ohne diese Basis ist eine valide und ergebnisnahe
Planung nicht möglich. Einige Beispiele:
• Komponententest: Source-Code analysieren um Testziele abzustecken.
• Integrationstest: Systemarchitektur (Schnittstellen, Komponenten, etc.) analysieren.
• Systemtest: Anforderungsspezifikation analysieren und Umfang des Systemtests
abstecken.
Es gilt also, vor der Planungsphase für die spätere Testdurchführung eine weitere Sacharbeit
voranzustellen. Ohne diese Analysetätigkeit kann es dazu kommen, dass nicht zielgerichtete
Planungen getätigt werden. Ein Lösungsvorschlag liegt in den agilen Vorgehensmethoden.
Hier werden Planung und Ausführung jeweils in sehr kurzen Iterationen durchlaufen. ([SNE],
S. 70f)
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
10
2.2.4. Schätzung der Testaufwände mit COCOMO-II
„Das Verhältnis zwischen Aufwand und Zeit ist nicht linear, d.h. wir können ein Projekt von
12 Mannmonaten nicht auf 6 Mannmonate reduzieren, indem wir die Anzahl der
Projektbeteiligten verdoppeln.“ ([SNE], S.73) Die steigende Anzahl an Beteiligten erhöht
signifikant die Aufwände für Kommunikation, Administration und Organisation. Die
Produktivität pro Mitarbeiter sinkt. Ein Schlüssel in der gegenseitigen Beeinflussung von Zeit
und Aufwand ist die Ermittlung der Produktivität.
Abbildung 2: Ermittlung der Testproduktivität ([SNE], S.73)
Zur Bildung einer Produktivitätskennzahl werden hier zuerst die sogenannten „TestPoints“
eingeführt. Sie erlauben es, jedes Testobjekt gemäß seiner Komplexität zu bewerten und
ermöglichen so eine Differenzierung nach Schwierigkeit einzelner Testtätigkeiten. Ein
Testpoint wird dabei mit 1,5 bis 3 Arbeitsstunden bewertet.
Man unterscheidet zum einen die dynamischen Testpoints, also die Anzahl der der
ausgeführten logischen Testfälle gemäß den Anforderungen. Führt man bspw. 1000 Testfälle
(1000 dyn. Testpoints) in 150 Tagen aus, so ergibt sich eine Testproduktivität von 6,6
Testpoints pro Tag. Diese dyn. Produktivität kann wie in Abbildung 2 aufgezeichnet und
langfristig gemittelt werden. Zum anderen existieren die statischen Testpoints. Diese
ergeben sich aus der Anzahl der Testobjekte. Im Systemtest sind dies bspw. zu testende
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
11
Schnittstellen, Benutzeroberflächen oder Datenbanken. Die Formel zur Berechnung der
Testpoints ergibt sich wie folgt:
���������� �� ��� � � ������ ∗ 4� � ������� ∗ 2� � ���� !� (2.1)
Da die Produktivität ganz wesentlich abhängig ist von der Erfahrung der Tester und vom
Grad der Testautomatisierung, muss die Statistik bisheriger Projekte (vgl. Abbildung 2)
bemüht werden. Hinzu müssen spezielle Einflussfaktoren und Testumstände berücksichtigt
werden, sodass sich die Testproduktivität wie folgt ergibt:
����"#�$%&��'��ä� �� ��� �� �� �����)� ∗ *��+,%��+-&��# (2.2)
Die Idee der noch wenig detaillierten Formel (2.2) wird in der sogenannten COCOMO-II
Gleichung zur Einschätzung des Testaufwandes mit Größen neben der Testproduktivität
weiter aufgegriffen ([SNE], S.74-77). Die drei weiteren berücksichtigten Faktoren sind hier:
• Projektbedingungen
• Produktqualität
• Systemtyp
Die Projektbedingungen lassen sich in folgende fünf Bedingungen unterteilen:
• Grad der Testwiederholbarkeit
• Stabilität der Testumgebung
• Kenntnis der Anwendung
• Zusammengehörigkeit des Testteams
• Reife des Testprozesses
Der finale Skalierungsexponent ist das arithmetische Mittel aus den Bewertungen der fünf
Projektbedingungen. Jede dieser Bedingungen wird anhand nachfolgender Skala bewertet:
• Sehr Niedrig (1,23)
• Niedrig (1,10)
• Mittel gut (1,00)
• Hoch (0,96)
• Sehr Hoch (0,91)
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
12
Die Produktqualität ist aus Sicht des Softwaretesters die Testbarkeit der „angelieferten“
Software aus der Entwicklungsabteilung. Die Testbarkeit wird dabei anhand des Aufwandes
gemessen, der notwendig ist, ein gegebenes Testziel zu erreichen. Je höher der Aufwand,
desto niedriger die Testbarkeit. Ein Beispiel für niedrige Testbarkeit liefert etwa ein System
mit vielen Parametern und graphisch überladenen Oberflächen. Um diese Testbarkeit als
Faktor zu bestimmen kann die Komplexität des Systems in vier Bereichen berechnet werden:
• Komplexität der Benutzeroberflächen
Je mehr Steuerungseingaben gemacht werden müssen, desto höher wird die
Komplexität. Die Eingabe in Textfeldern etwa erhöht zwar die Gesamteingaben, nicht
aber die Komplexität:
./�� ���0��0�) � �)�1��2� �3�� �)�1�� (2.3)
• Komplexität der Systemschnittstellen
Die Komplexität einer Schnittstelle ist das Verhältnis der Anzahl verschiedener
Datentypen zur Anzahl an Datenelementen pro Schnittstelle. Je mehr Datentypen es
pro Schnittstelle gibt, desto schwieriger ist diese zu testen.
.�� 4�����5���4�������3���� (2.4)
• Komplexität der Datenbanken
Die Komplexität einer Datenbank spiegelt sich wieder im Verhältnis von Schlüsseln
und Indizes zur Gesamtanzahl aller Attribute.
.4/ �!6�ü ������ 10��89�: ;� <��� 10�� (2.5)
• Komplexität der Anwendungsfälle
Diese ist abhängig von den Bedingungen, die für eine einzelne Aktion gelten. Je
mehr Bedingungen, desto größer der Aufwand, eine Aktion zu testen.
.<�= /�: �)0�)��<>� ���� (2.6)
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
13
• Systemkomplexität
Die Komplexität des gesamten Systems berechnet sich aus dem arithmetischen
Mittel der Einzelkomplexitäten.
.�5 ?@AB8?CC8?D@8?EBFG (2.7)
Kann die Systemkomplexität nicht über die Einzelkomplexitäten ermittelt werden,
so ist sie über eine Skala z.B. in Anlehnung an frühere Projekte zu schätzen. Die
Komplexität ergibt sich dann wie folgt:
• Sehr hoch (0,8)
• Hoch (0,6)
• Durchschnittlich (0,5)
• Niedrig (0,4)
• Sehr Niedrig (0,2)
• Testbarkeitsfaktor aus der Komplexität
Der Faktor der eingangs erwähnten Testbarkeit berechnet sich aus der ermittelten
Komplexität und der mittleren Komplexität. Die mittlere Komplexität nimmt nach
Sneed den Wert 0,5 an.
����H-#&����+-&��# )�3� ���?�3���J �ä�3 ������?�3���J �ä� (2.8)
Nach der Ermittlung der Faktoren für die Projektbedingungen und die Produktqualität gilt es
noch den Faktor für den Systemtyp zu bewerten. Hierzu werden die Systeme in drei
relevante Kategorien unterteilt:
• Verteilte Multi-User-Systeme (1,0)
• Integrierte, verteilte Systeme mit mehreren Benutzern (2,0)
• Embedded-Systeme (4,0)
Standalone- und Single-User-Systeme werden mit dem Faktor Null bewertet. Da sie nicht in
Systeme integriert sind, ist dieser Faktor nicht von Relevanz und wird nicht berücksichtigt.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
14
Nach der Bestimmung aller relevanten Faktoren ergibt sich die sogenannte COCOMO-II
Gleichung zur Bestimmung des Testaufwandes (in Personentagen) wie folgt:
����-%+K-�$ LM���N�M" ∗ O �� ��� �� �� ����:0>� � �ä�P
�>�� ��0�) �J������ ∗ ����H-#&����+-&��# (2.9)
2.2.5. Wartung und Weiterentwicklung
Wenn Software geändert wird, müssen dementsprechend auch Änderungen auf der
Testebene umgesetzt werden. Die geänderten Funktionalitäten oder Anforderungen etwa
bedingen eine Anpassung der Testfälle. Man spricht in diesem Fall von der Wartung bzw.
Weiterentwicklung der Testumgebung.
Wichtig für die Effizienz ist es dabei, Testfälle möglichst schnell und bequem abzurufen, zu
verändern und wieder abzuspeichern. Im Sinne der Effektivität ist es wichtig, Testfälle an
beliebigen Stellen einfügen und diese mit bestehenden Strukturen verknüpfen zu können.
Hierzu werden anstatt Textdateien Tabellen oder XML-Strukturen empfohlen.
Bestehen bleibt aber das Problem der Zuordnung der Testfälle zu den geänderten
Anforderungen. Wenn sich Quellcode ändert, müssen die zugehörigen Testfälle gewartet
werden. Das Problem liegt darin, dass beim Systemtest die Testfälle auf die Anforderungen
bezogen sind und nicht auf den Code. Die Anforderungen sind im Idealfall wieder direkt mit
dem Code verknüpft. Und zwar in der Form, dass Codeabschnitte auf die Anforderung
verweisen, die sie notwendig macht.
Es gilt also von vornherein für jeden Testfall einen Verweis auf die jeweilige Anforderung zu
schaffen. Invertiert man dann den Informationsfluss, so ist direkt ersichtlich, welche Testfälle
durch geänderten Code angepasst werden müssen.
Ohne diese Verknüpfung von Testfällen, Anforderungen und Code ist „intuitives Testen“
notwendig: d.h. blind testen, alles testen etc. Effektiver und effizienter ist der Weg, über die
Verknüpfung: so können gezielte, systematische Regressionstests gefahren werden. Die
Zusatzaufwände durch die Speicherung der Testfälle mit Querverweisen lassen sich so
mehrfach kompensieren. ([SNE], S. 124 f)
2.2.6. Testautomatisierung – Ausbaustufen und Alter nativen
Die Automatisierung im Testumfeld kann verschieden intensive Formen annehmen. Von der
vergleichsweise einfachen, automatischen Testauswertung bis hin zur komplexen,
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
15
automatischen Testfallermittlung sind fünf Stufen der Testautomatisierung denkbar. Unten
stehende Abbildung zeigt den Aufbau zunehmender Testautomatisierung.
Abbildung 3: Stufen der Testautomatisierung ([SNE], S. 237)
Neben der Automatisierung von Softwaretests gibt es mindestens zwei weitere Alternativen
im Umgang mit der Testproblematik:
• Erste Alternative: Weniger Tests
Hier wird mit Stichproben die Lauffähigkeit der Software nachgewiesen und dann
eine Produktfreigabe erteilt. Man erhofft sich, durch Einsparungen beim Test evtl.
steigende Supportaufwände zu kompensieren. Diese Alternative ist die teuerste, da
unentdeckte Fehler kaum kalkulierbare Kosten und Risiken nach sich ziehen. „Die
Testwirtschaftlichkeit beginnt mit der Eindämmung der Fehlerkosten.“ ([SNE], S. 239)
• Zweite Alternative: Massiver Personaleinsatz
Hierbei wird davon ausgegangen, dass eine ausreichend große Anzahl an Testern
die Testabdeckung übernimmt. Zum einen verursachen aber auch diese Mitarbeiter
in Summe nicht unerhebliche Kosten, zum anderen variiert die Testqualität aufgrund
von Faktoren wie Konzentrationsfähigkeit, Motivation und Erfahrung der Mitarbeiter
erheblich. Diese Schwankung der menschlichen Leistungsfähigkeit im Gegensatz zur
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
16
konstanten Kontrollleistung eines Automaten senkt die Testeffektivität in diesem Falle
erheblich. ([SNE], S.239)
2.2.7. Testmanagement
Das Projektmanagement während eines Entwicklungsprojektes hat sich in der Industrie als
unbestrittene Aufgabe etabliert. Nicht immer wird aber beim Softwaretest ein unabhängiges
Management eingesetzt. Werden etwa Aufgaben des Testmanagements und/oder des
Qualitätsmanagements dem Projektleiter zur Koordination überantwortet, so entsteht ein
Zielkonflikt auf dieser Position. Die Projektleitung verantwortet Kosten und Termine
gegenüber der Geschäftsleitung und dem Kunden, das Qualitäts- und Testmanagement die
Sicherstellung der definierten Qualitätsziele sowie der Lauffähigkeit und
Bedienerfreundlichkeit. Weiterhin endet das Testmanagement nicht mit der Fertigstellung
des Produktes (und damit einhergehend dem Ende des Entwicklungsprojektmanagements).
Die Bereitstellung von neuen Releases, Updates etc. macht Regressionstests über die
gesamte Produktlaufzeit notwendig. ([SNE], S. 253 ff)
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
17
2.3. Seidl/Baumgartner „Basiswissen Testautomatisie rung“
2.3.1. Der fundamentale Testprozess
Letztlich lässt sich aber unabhängig vom Diversifikationsgrad der Projekte ein „gemeinsamer
Nenner“ ausmachen: Jeder Testprozess folgt einem einfachen Regelkreis, der hier als
„Fundamentaler Testprozess“ bezeichnet wird [SEID]. Die Abbildung 4 zeigt diesen
einfachen Regelkreis mit den Bestandteilen Planung, Analyse, Realisierung, Auswertung und
Abschluss des Prozesses sowie dem Projektcontrolling als begleitendem, steuerndem
Element.
Das Problem in der Praxis ist das Folgende: Die Ausgestaltung dieser einzelnen
Prozessschritte erfolgt in hohem Maße erfahrungsbasiert und unternehmensspezifisch. Ein
wichtiger Punkt zur unternehmensübergreifenden Vergleichbarkeit von Softwareprojekten ist
also die Abbildung der Projektdaten in ein möglichst allgemeingültiges Datenraster.
Abbildung 4: Der Fundamentale Testprozess (Quelle: [SEID], 2012)
2.3.2. Automatisierte Testdurchführung
Im Hinblick auf die zeitliche Taktung automatisierter Tests gibt es vielfältige Ansätze. Im
Rahmen eines Projektes kann an verschiedenen Zeitpunkten unter verschiedenen
Randbedingungen automatisiert getestet werden. Voneinander abweichende Vorgehen
beim Testen sind durch die Varianz der Projekte sogar sinnvoll: So eignet sich in der
sequenziellen Entwicklung die Implementierung fallweiser Testdurchläufe, in agilen
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
18
Entwicklungsumgebungen mit inkrementellem Fortschritt liegt eher die kontinuierliche
Durchführung automatisierter Tests im Fokus. ([SEID], S. 38)
Generell sind auch die Softwaretools, mit denen wiederum andere IT-Systeme getestet
werden, nicht vollständig fehlerfrei. Bei der Anwendung von z.B. kommerziellen Tools gilt es
dann die herstellereigenen Foren und Plattformen für die Meldung von Bugs und Feature
Requests zu beachten. ([SEID], S. 41 f) Es empfiehlt sich für die Beobachtung von
Werkzeugfehlern eine ähnliche Systematik, wie sie auch beim Test des eigentlichen
Produktes angewendet wird. Der Vorteil eines vorgeschalteten internen Reviews liegt darin,
dass sichergestellt werden kann, dass keine Konfigurations- oder Frameworkfehler
vorliegen, bevor eine einheitlich koordinierte Meldung an den Werkzeugprovider versendet
wird.
Auch durch Fehler bei der Implementierung des automatischen Testfalls fehlgeschlagene
Durchläufe erzeugen zunächst ein reguläres Fehlerprotokoll (z.B. Nichtbestehen des
Testfalles), welches Aufwände zur Durchsicht und Behebung des vermeintlichen
Produktfehlers auslöst. Es empfiehlt sich also innerhalb der Testumgebung einen
zusätzlichen Status für das Testdurchführungsergebnis einzuführen. Hier kann vermerkt
werden, was den Abbruch oder zumindest den nicht erfolgreichen Abschluss des Testfalls
verursacht hat – das Werkzeug, sprich die Implementierung, oder der Prüfling. So kann
schnell und einfach gemessen werden, wo Verbesserungspotentiale vorliegen und
zielgerichtete Gegenmaßnahmen sind möglich (S. 45f). Ein in dieser Quelle genanntes
Praxisbeispiel zeigt, dass 60% der fehlgeschlagenen Testfälle aufgrund der Automatisierung
selbst fehlschlugen. Der neue Status und gezielte Gegenmaßnahmen konnten diesen Wert
auf unter 10% absenken und im Gegenzug den Prozentsatz tatsächlich aufgedeckter
Produktfehler erhöhen. ([SEID], S. 46)
2.3.3. Softwarequalitätskriterien
Vielfach wird die Frage gestellt, wie Qualität von Software gemessen werden kann.
Verschiedene Standards und Richtlinien versuchen diese Frage zu beantworten. Eine Norm,
die sich mit allgemeinen Qualitätskriterien befasst, ist die ISO 9126. Die hier erfassten
Kriterien sind meist auf allen Teststufen anwendbar. Einen Überblick über die Kriterien gibt
nachfolgende Abbildung.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
19
Abbildung 5: Darstellung der Qualitätskriterien nach ISO 9126 ([SEID], S.103)
Die Funktionalität von Software ist in vielen Fällen der Hauptaspekt, unter dem Tests
betrieben werden. Die zugehörigen Unterpunkte ergeben sich laut Standard.
Angemessenheit ist hierbei die „Eignung der Funktionen für spezifizierte Aufgaben“ ([SEID],
S. 104). Die Richtigkeit beschreibt beispielsweise die Wertegenauigkeit, während
Interoperabilität ein Maß dafür ist, wie gut mit vorgegebenen Systemen interagiert werden
kann. Die Sicherheit beinhaltet den Schutz vor unberechtigtem Zugriff, die
Ordnungsmäßigkeit zielt auf die Erfüllung von Normen, Bestimmungen, Vereinbarungen oder
Gesetzen ab. ([SEID], S. 104 ff)
Das zweite Hauptkriterium Zuverlässigkeit beschreibt die Fähigkeit des Systems zur
Leistungserbringung über einen bestimmten Zeitraum. Unter der Reife eines Systems
versteht die Norm dabei eine geringe Versagenshäufigkeit durch Fehler. Die Fehlertoleranz
sagt etwas darüber aus, welches Leistungsniveau oder Maß an Lauffähigkeit ein System
selbst beim Auftreten von Fehlern erhalten kann. Die Wiederherstellbarkeit befasst sich mit
dem Rekonstruieren von Daten und dem Erreichen der Betriebsleistung nach einem Ausfall
([SEID], S. 109ff). Die Konformität beschreibt den „Grad der Erfüllung von Anforderungen an
die Zuverlässigkeit“ ([SEID], S. 112).
Die Benutzbarkeit ist nach ISO 9126 der Aufwand, den die Softwarenutzung vom User
fordert und wie dieser ihn bewertet. Die Unterpunkte Verständlichkeit, Erlernbarkeit,
Bedienbarkeit und Attraktivität sind hierbei schwierig gemäß eines Rasters zu bewerten. Sie
hängen vielmehr von z.B. Erfahrung, visueller Wahrnehmung etc. ab. ([SEID], S. 112)
Die Effizienz ist gemäß Norm „definiert als das Verhältnis zwischen eingesetzten
Betriebsmitteln und Leistungsniveau der Software“ ([SEID], S. 114). In der Norm wird die
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
20
Effizienz auf zwei Kenngrößen ausgebreitet. Zum einen auf das Zeitverhalten der Software.
Dieses bezieht sich auf Antwort- und Verarbeitungszeiten des Systems. Solche Zeiten
hängen aber gerade in Umgebungen mit mehreren Usern von der Auslastung des Systems
und der Anzahl an Zugriffen ab. Aus diesem Grund werden Lasttests durchgeführt, also die
Systeme mit einem definierten Stresslevel beaufschlagt, um Vergleichbarkeit herzustellen.
([SEID], S. 114) Zum anderen erstreckt sich Effizienz auf das Verbrauchsverhalten des
Systems. Hier wird gemessen, welche Verbrauchsindikatoren (Speicherverbrauch,
Rechenzeitverbrauch, …) wie stark ausgeprägt sind.
Die Unterpunkte des Kriteriums Änderbarkeit erfassen die Aufwände, die für die Analyse
und die tatsächlichen Modifikationen am Testobjekt entstehen. Die Stabilität gibt hierbei an,
wie wahrscheinlich unerwartete Auswirkungen der durchgeführten Änderungen am
Testobjekt sind. Diese inneren Qualitätsmerkmale können mit einer hohen und hochwertigen
Abdeckung durch automatisierte Tests recht gut bewertet und verbessert werden ([SEID], S.
117). Die Testbarkeit beschreibt die zur Prüfung des Testobjektes notwendigen Aufwände.
Verringert sich dieser Aufwand, steigt die Testeffizienz. Da aber die Testbarkeit neben
„weichen“ Faktoren wie der Komplexität der Arbeitsabläufe auch von technischen
Voraussetzungen wie etwa der Ausgestaltung von Schnittstellen abhängt, empfiehlt es sich,
frühzeitig in der Entwicklung des Prüflings die spätere Testbarkeit zu berücksichtigen.
Gerade wenn automatisiert und nicht manuell getestet werden muss, können andere
Anforderungen gelten ([SEID], S. 117).
Schlussendlich noch ein Blick auf das Kriterium der Übertragbarkeit : Die Anpassbarkeit wird
auch als Portabilität bezeichnet und beschreibt den Betrieb in verschiedenen Umgebungen.
Die Installierbarkeit bezeichnet den Installationsaufwand. Die Koexistenz bezieht sich auf die
Fähigkeit des Systems, ohne Beeinträchtigung parallel mit weiteren Systemen zu laufen.
Unter Austauschbarkeit versteht man z.B. das Ersetzen des Prüfsystems durch sein
nachfolgendes Release und den Aufwand, der benötigt wird, dieses unter Beibehaltung der
bestehenden Schnittstellen betriebsbereit zu machen. ([SEID], S. 118f)
2.3.4. Integration von Testautomatisierung in die O rganisation
In diesem Abschnitt sollen neben einigen Anregungen und Ideen für den Einstieg in die
Testautomatisierung auch Herausforderungen, Probleme und Lösungsansätze vorgestellt
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
21
werden, die im Zusammenhang mit der Einführung automatisierter Tests einhergehen. Ein
Blick auf die Voraussetzungen rundet die Integration von Testautomatisierung ab.
Abbildung 6: Anregungen und Ideen zum Einstieg in die Testautomatisierung ([SEID], S. 151)
Die Abbildung 6 zeigt ein Bild, das beispielsweise in einem Workshop mit Testern,
Entwicklern und Managern im Vorfeld eines Testautomatisierungsvorhabens entstehen
könnte. Es zeigt deutlich, wie vielfältig die Herangehensweisen an die Testautomatisierung
sein können und auch, dass dieses Thema von leichteren Seiten her angegangen werden
kann. Im Folgenden sollen dazu einige Punkte aufgegriffen werden.
In neuen Projekten ergibt sich die Möglichkeit, Testautomatisierung von Beginn an
einzuführen und sie mit dem Produkt wachsen und reifen zu lassen. In frühen
Entwicklungsphasen wird bspw. auf die spätere Testbarkeit und Wartbarkeit geachtet, was
durchaus Vorteile mit sich bringt. Die Gefahr ist, gerade bei verhältnismäßig unerfahrenen
Unternehmen, dass das Thema Testautomatisierung auf zu breiter Front angegangen wird.
Es wird versucht, den gesamten Testprozess mit Automatisierung zu unterstützen, die aber
noch nicht ausgereift ist. In solchen Situationen ist eine valide Konzeption des Vorhabens
unumgänglich ([SEID], S. 152).
In bestehenden Projekten ist die Einführung von Testautomatisierung sogar noch
schwieriger. Neben der Frage, auf welcher Stufe (Komponententest, Systemtest, …) von
wem automatisiert getestet wird, muss mit einer zeitlichen Verzögerung durch den
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
22
Initialaufwand der Automatisierung gerechnet werden. Ebenso sind vorübergehende
Qualitätseinbußen durch den Eingriff in ein bestehendes und prinzipiell lauffähiges System
möglich. Auf der nichttechnischen Ebene bringt Testautomatisierung eine Art
Paradigmenwechsel mit sich. Das Team muss bestehende Abläufe und Arbeitsweisen
durchbrechen oder zumindest verändern, eine Aufgabe, die verstärkte Präsenz und
Aufmerksamkeit von der Teamführung fordert, um alle Beteiligten mitzunehmen (vgl. [SEID],
S. 152).
In der Praxis kommt es auch vor, dass kein ausgereifter Testprozess existiert. In diesem
Falle ist Testautomatisierung kein probates Mittel, da sie keinen Prozess verbessern kann, in
dem es an Know-How in Testtechniken, Ressourcen etc. fehlt. In diesem Falle würden durch
Werkzeugbeschaffungen und Implementierungen nur zusätzliche Aufwände generiert, die
zusätzlich noch zu erhöhtem Druck auf die Mitarbeiter hinter den Tests führen.
Auch wenn es gewachsene Systeme auf Produktseite und ausgereifte Testprozesse auf der
Methodenseite gibt, empfiehlt es sich nicht, Testautomatisierung in einem ganzheitlichen
Ansatz kurzfristig einzuführen (Big Bang). Es sollte vielmehr in Teilbereichen automatisiert
werden (z.B. Komponententest, „Top 10“-Testfälle, …) um Erfahrungen zu sammeln. Bei
entsprechender Reife der automatisierten Prozesse können sie dann sukzessive auf
übergeordnete Teststufen übertragen werden.
Hochkomplex ist die Einführung von Testautomatisierung in Unternehmen mit
Multiprojektumgebungen. Heterogene Systemlandschaften, die sich dann in Schnittstellen,
Technologien und Projektvorgehen unterscheiden, lassen sich nicht mit einem einheitlichen
Werkzeug bewältigen. Vielmehr empfiehlt sich dann ein Automatisierungsframework, das auf
die Gemeinsamkeiten fokussiert und doch flexibel genug ist, um auf die komplexe
Systemlandschaft einzugehen ([SEID], S. 153 f).
Die Argumente Zeit und Aufwand werden im Hinblick auf die Testautomatisierung auch
nicht selten falsch eingeschätzt. Die Einführung eines Testautomatisierungsprozesses
erfordert einiges an Aufwänden und Zeit über den üblichen Projektaufwand hinaus. Etwa für
die Recherche, Beschaffung, Einführung und Installation von Werkzeugen, aber auch für die
Implementierung, Durchführung und Auswertung sowie die Wartung der automatisierten
Tests ([SEID], S. 155)
Für die Wirtschaftlichkeit von Testautomatisierung spielen Kosten und Nutzen eine wichtige
Rolle. Gerade diese Aspekte sind aber äußerst schwer zu bewerten. Wichtig ist es zu
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
23
beachten, dass die Kosten nicht nur die Initialkosten beschaffter Werkzeuge umfassen. Es
ist zu erwarten, dass auch für Wartungs- oder Supportverträge, Schulungen und Personal
weitere Kosten entstehen. Diese Kosten erzeugen nicht sofort einen gleichwertigen Nutzen.
Die Vorteile der Testautomatisierung stellen sich meist erst im Verlauf der Entwicklung, z.B.
über mehrere Releases heraus. Je öfter Testläufe durchgeführt werden, desto höher ist die
Wahrscheinlichkeit, dass sie mehr Nutzen generieren, als sie Kosten verursacht haben
([SEID], S. 156).
Ein weiterer wichtiger Punkt, ist die Unterstützung einer Lernkurve. Wenn Erfahrungen und
Bestehendes von bisherigen (erfolgreichen oder gescheiterten) Automatisierungsprojekten
gesichert werden, muss nicht jedes Mal neu begonnen werden. Vielleicht sind durch
werkzeugseitige Weiterentwicklungen frühere Konzepte nicht mehr unrealistisch – in jedem
Fall tragen sie aber ihren Teil zu einer validen Entscheidungsgrundlage bei ([SEID], S. 156)
Wenn dann letztlich Testautomatisierung eingeführt wird, startet oft eine Reihe von
Experimenten mit dem Werkzeug oder Framework. Varianten und Spielarten werden nicht
immer systematisch ausprobiert. Es ist aber wichtig, auch diese Erfahrungen in Form einer
Dokumentation festzuhalten, um Einstellungen, Konfigurationen oder erste Best-Practices
festzuhalten. Auch sollten nach Festlegung wesentlicher Regularien noch während des
Projektes Dokumente wie etwa Verfahrensanweisungen erstellt werden, um z.B.
Zertifizierungen zu bestehen und reproduzierbare Ergebnisse sicherzustellen ([SEID], S.
157).
Wenn ein Testfall erst einmal automatisiert ist, verschwindet er oftmals im Testset der
durchzuführenden Fälle und wird nicht mehr überprüft. Das Konzept Test the Test sieht vor,
auch automatisierte Testfälle regelmäßig auf ihre Qualität und Relevanz zu prüfen. Diese
Tätigkeit wird beim manuellen Test vom Tester meist „nebenbei“ mit ausgeführt und daher
nicht explizit berücksichtigt. Eine Möglichkeit dazu ist das sog. „Fault Seeding“ oder
„Bebugging“. Dabei werden gezielt Fehler im Prüfling versteckt und es wird gemessen, ob
die Testfälle den Fehler finden. Werden automatisierte Testfälle nicht in dieser Form
begutachtet, ist es wahrscheinlich, dass Testfälle durchlaufen werden, deren Potential zur
Fehlererkennung sehr gering ist. Der automatisierte Test würde damit weniger wirtschaftlich
([SEID], S. 158 f)
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
24
2.4. Dustin/Rashka/Paul „Software automatisch teste n“
2.4.1. Test Maturity Model (TMM)
Das sogenannten Test Maturity Model (TMM) ist ein Reifegradmodell zur Bewertung der
Testprozesse in insgesamt 5 Stufen. Diese Stufen und das jeweils zugehörige,
automatisierte Testen, sollen im Folgenden kurz beschrieben werden.
TMM Level 1 – Initialphase
Beschreibung: Das Testen ist auf dieser Stufe kein sicherer, sondern vielmehr ein schlecht
definierter und nicht von der Fehlersuche abgegrenzter Prozess. Es wird unmittelbar nach
der Erstellung des Codes getestet. Das Ziel ist dabei die Sicherstellung der Lauffähigkeit der
entwickelten Software. Es wird dabei auch nicht auf explizite Testressourcen oder
Testwerkzeuge zurückgegriffen.
Automatisiertes Testen: Auf dieser Stufe wird von der „zufälligen Automatisierung“
gesprochen. Entweder findet kein oder nur augenblicksorientiertes automatisiertes Testen
statt. Die Testskripts innerhalb eines eventuell zum Versuch eingesetzten Werkzeuges
werden nicht hinsichtlich der Mehrfachverwendung gepflegt und auch nicht entsprechend
existierender Standards für automatisierte Testskripts entwickelt. Dadurch müssen sie für
jeden Build neu erstellt werden, was die Testkosten um 100% bis 150% erhöhen kann.
([DUST], S.19)
TMM Level 2 – Definitionsphase
Beschreibung: In dieser Phase wird das Testen der Software von der Fehlersuche getrennt.
Es wird eine eigene Testphase definiert, die auf das Programmieren folgt. Der Testprozess
wird erst nach Abschluss der Programmierung des Prüflings geplant, was u.a. damit zu tun
hat, dass davon ausgegangen wird, der Test wäre abhängig vom Quellcode der zu
testenden Software. Das Ziel innerhalb dieser Stufe ist das Testen des Systems gegen seine
Spezifikationen. Es gibt einfache Testtechniken und Methoden, durch die späte Planung ist
die Qualität aber noch nicht optimal.
Automatisiertes Testen: Testen wird in der Definitionsphase zur geplanten Aktivität. Die
Testaktivitäten werden systematisch definiert und vervollständigt und über das
Projektmanagement werden dem Test benötigte Ressourcen zugewiesen. Auf dem
Testniveau wird automatisiert getestet, es werden auch Testskripts hinsichtlich der
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
25
Automatisierung modifiziert, jedoch gibt es keine dokumentierten Standards oder eine
Wiederholbarkeit. Die Einführung von Werkzeugen, das Design und die Entwicklung von
Tests folgen ebenfalls keinen Standards. Entsprechend Level 1 bietet die Automatisierung
hier keinen positiven Ertrag, es besteht vielmehr das Risiko von erhöhten Testaufwänden.
([DUST], S.20)
TMM Level 3 – Integrationsphase
Beschreibung: Das Testen des Systems ist nun keine auf die Entwicklung folgende Phase
mehr, sondern ist in den gesamten Entwicklungsprozess integriert. Auf den
Testplanungsfähigkeiten von Level 2 wird insofern aufgebaut, als dass bereits in der
Anforderungsphase begonnen wird. Mit dem V-Modell werden Testziele anforderungs- und
kundenorientiert aufgestellt und für den Testfallentwurf herangezogen. Die Testprozesse
sind in dieser Phase werkzeugunterstützt, für die Qualitätsprüfung fehle allerdings noch ein
formelles Prüfprogramm und es gibt keine Überprüfungen über den gesamten Lebenszyklus
des Systems.
Automatisiertes Testen: In der Integrationsphase spricht man vom „absichtlichen
Automatisieren“. Die Testanforderungen und Testskripts gehen logisch aus den
Spezifikationen der Softwareanforderungen und den Designdokumenten hervor. Es gibt
automatisiert erstellte und hinsichtlich Pflege und Wiederverwendung optimierte Testskripts,
aber noch keine automatisierten Testverfahren. In dieser Phase kann in der Regel ab dem
zweiten Regressionstest kostendeckend gearbeitet werden. ([DUST], S. 21)
TMM Level 4 – Phase von Management und Measurement
Beschreibung: Der Testprozess ist auf diesem Level quantifiziert und bewertet, es erfolgen
Prüfungen in allen Phasen der Entwicklung als Qualitätskontrollmaßnahmen. Die
Schwerpunkte liegen dabei mittlerweile bei Qualitätskriterien wie der Zuverlässigkeit oder der
Benutzerfreundlichkeit. Die Testfälle werden datenbankbasiert für die Wiederverwendung
und für die Durchführung von Regressionstests verwaltet. Entdeckte Fehler werden
dokumentiert und hinsichtlich ihrer Kritikalität bewertet. Mängel im Testprozess resultieren im
Wesentlichen noch aus dem Fehlen einer konsequenten Fehlervermeidungsphilosophie.
Automatisiertes Testen: Auf Level 4 des TMM wird von „fortgeschrittener Automatisierung“
gesprochen. Dazu wird im Wesentlichen ein automatisierter Testlebenszyklus umgesetzt.
Hier werden Fehler erkannt, aufgezeichnet und automatisch direkt dem Prozess der
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
26
Behebung, Überprüfung und Auswirkungsuntersuchung im Regressionstest zugewiesen. Der
Softwaretest ist integraler Bestandteil der Produktentwicklung, Test und Entwicklung arbeiten
anforderungsorientiert und eng abgestimmt zusammen. Fehler lassen sich so früh aufdecken
und kostengünstig beheben. Die bisherige Werkzeuglandschaft mit den reinen
Testwerkzeugen wird bspw. um Tools zur Fehlerverfolgung ergänzt. ([DUST], S. 22)
TMM Level 5 – Phase der Optimierung, Fehlervermeidu ng und Qualitätskontrolle
Beschreibung: Aufbauend auf der Definition und Verwaltung des Testprozesses aus den
vorangegangenen Reifegraden können mit der vorhandenen Infrastruktur auf dieser Stufe
auch die Kosten und die Wirksamkeit der Tests überprüft werden. Es gibt Mechanismen zur
kontinuierlichen Verbesserung, Philosophien zur Fehlervermeidung und eine effektive
Qualitätskontrolle. Es gibt Verfahren für die Auswahl und Bewertung von Testwerkzeugen.
Diese wiederum sind automatisiert und liefern Unterstützung für die einmalige und
wiederholte Ausführung von Testfällen, für deren Entwurf, für die Wartung der
Testumgebung und für das Fehlermanagement.
Automatisiertes Testen: Mit der oben erwähnten Unterstützung aus automatisierten
Werkzeugen wird der automatisierte Testlebenszyklus systemisch umgesetzt. Neben den
Testbezogenen Werkzeugen kommen Tools für die Erzeugung von Testdaten und zur
Fehleranalyse und Fehlervermeidung hinzu. ([DUST], S. 23)
2.4.2. Testteam-Management
Je nach Organisationsstruktur im Unternehmen an sich bieten sich auch verschiedene
Möglichkeiten an, das Testteam zu strukturieren und in den Entwicklungsprozess zu
integrieren. Die Literatur unterscheidet hier fünf beispielhaft mit Mitarbeitern besetzte
Testteamprofile (vgl. Abbildung 7), die im Folgenden kurz vorgestellt werden sollen.
Werden Testingenieure nur für die Dauer des Projektes in die entsprechende Organisation
beordert, spricht man von einem Durchgangs-Testteam . Je nach Systemumfang kann
dieses Testteam unterschiedlich groß sein. In kleinen Durchgangsteams kann einer der
Testingenieure die Funktion des Testleiters mitübernehmen, ein Testleiter sollte dabei nicht
mehr als 4 Testingenieure betreuen. In größeren Testteams, ab einer Anzahl von ca. 8
Testern, empfiehlt sich zusätzlich zu einem weiteren Testleiter eine übergeordnete
Hierarchiestufe (Testmanager) zur Gesamtkoordination der Tests. Nach dem Ende des
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
27
Testprojektes verlassen die Testingenieure das die Organisation wieder und nehmen die
gesammelten Erfahrungen aus der Arbeit mit der Anwendung, den Werkzeugen und von
Schulungen mit. Der Vorteil dieser Teamstruktur liegt darin, dass die Kontrolle über die
Testarbeiten in der Projektorganisation verbleibt. Außerdem können recht kurzfristig
Kapazitäten durch Berater oder weitere Ingenieure unterstützt werden. Die Nachteile liegen
zum einen darin, dass nicht von Beginn des Entwicklungszyklus an getestet wird, zum
anderen verbleibt nach Ende des Projektes wenig Test-Know-How in der Organisation.
Darüber hinaus sind die Möglichkeiten zur systemischen Prozessverbesserung ebenso
begrenzt, wie die des internen Wissenstransfers zu Prozessen und Werkzeugen ([DUST], S.
172 ff).
Wird der professionelle Test von Software als strategische Investition (Aufbau von Know-
How, etc.) betrachtet, so kann ein Zentrales Testteam aufgebaut werden. Dieses
unterscheidet sich schon allein aufgrund der Teamgröße und Hierarchiestufen deutlich vom
Durchgangsteam. Der übergeordnete Testdirektor übernimmt die Funktion eines
Abteilugnsleiters und stellt die korrekte Ausführung aller im Team verorteten Testaktivitäten
unter Einhaltung der Planungen sicher. Im zentralen Testteam werden entsprechend seiner
strategischen Ausrichtung Testingenieure langfristig und einzelprojektunabhängig
beschäftigt. Den Mitarbeitern wird eine Weiterentwicklung durch den Einsatz in
verschiedenen Projekten oder eine Weiterbildung anhand der (automatisierten)
Werkzeuglandschaft ebenso ermöglicht, wie der Aufstieg innerhalb der Organisation. Das
Testteam fungiert in der Startphase als „interne Beratung“ der Entwickler hinsichtlich der
Ausrichtung der Prozesse auf Testbarkeit, Werkzeugeinsatz o.ä. Die Vorteile des zentralen
Testteams liegen einerseits in der langfristigen Sicherung und dem Austausch von Know-
How, da Erfahrungswerte aus verschiedenen Entwicklungsprojekten in einer Abteilung
gebündelt werden können. Durch den Pool von kompetenten Mitarbeitern können
Testexperten kurzfristig Projekten zugewiesen werden, z.B. bei Kapazitätsengpässen oder
Terminproblemen. Nachteile entstehen lediglich durch höhere Aufwände für dauerhaft
beschäftigtes Expertenpersonal sowie für die recht aufwändige Verwaltung für den
Austausch von Testingenieuren zwischen den verschiedenen Projekten ([DUST], S. 172, 174
f, 179).
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
28
Neben der Strategie der Integration des Testteams in den gesamten Entwicklungsprozess
gibt es auch die Möglichkeit, den Test der entwickelten Software als sogenannte
Unabhängige Verifizierung und Validierung (UVV) am Ende des
Entwicklungslebenszyklus durchzuführen. Das UVV-Testteam führt also einen
Akzeptanztest mit der Anwendung und eine Validierung der Produktqualität gegen die
Softwaredokumentation durch. Die eher von extern auf die Entwicklung blickende UVV-
Gruppe beurteilt oftmals den Reifegrad einer Entwicklung und entscheidet über die
Marktfähigkeit. Hierzu fokussiert das Team im Wesentlichen auf die Teststufen ab dem
Systemtest. Das UVV-Testteam kann also als First User bezeichnet werden, der einerseits
sehr anspruchsvoll, andererseits auch wirtschaftlich und technisch kompetent an das
Produkt herangeht. Gerade im Bereich von Softwaresystemen mit erhöhter Kritikalität
(Finanzsoftware, Avionik, Satellitentechnik, etc.) kann ein derartiges Testteam seine
Investitionen rechtfertigen.
Die Vorteile des UVV-Teams liegen in seinen speziellen Kenntnissen, außerdem ist es
ähnlich wie das zentrale Testteam projektübergreifend verfügbar und kann auch beratend
zur Seite stehen. Ein weiterer Vorteil liegt darin, dass ein extrem anspruchsvoller Test aus
der Sicht eines Kunden noch im Hause durchgeführt werden kann, was entstehende
Nachteile (Kosten, Image, etc.) durch Fehleraufdeckung nach dem Release des Systems
reduziert. Die Nachteile liegen dem Autor zufolge darin, dass Tester innerhalb der UVV-
Organisation schnell auf diese festgelegt werden könnten und evtl. nicht mehr über
umfassende und aktuelle Softwarekenntnisse in der Entwicklung verfügen ([DUST], S. 172,
176f, 180).
Als abschließender Teamtypus soll die SMT-Gruppe vorgestellt werden. Die Abkürzung
steht dabei für System Methodology and Test (SMT) und bedeutet, dass das Team im
Mittelpunkt der internen Qualitäts-, Test- und Prozessentwicklung angesiedelt ist und
verschiedenen Projekten in Form eines internen Beraters zur Seite steht. Innerhalb dieses
Teams wird der Wissenstransfer von Methoden und Normen innerhalb der Organisation
ebenso weiterentwickelt, wie die Testrichtlinien und Testtechniken sowie Schulungen im
Zusammenhang mit der Werkzeuglandschaft. Das SMT-Team muss daher Kompetenzen
bündeln, die den gesamten Testlebenszyklus abdecken (Testdesign, Testautomatisierung,
Testausführung, etc.). Es kümmert sich außerdem im Verlauf der Testentwicklung um die
Erforschung neuer Testmethoden und Testwerkzeuge, die Teilnahme an Konferenzen sowie
die Pflege der Testdatenbank mit Test-Know-How, Bewertungen von Werkzeugen und
Testautomatisierungscode. Die Vorteile für das Team liegen zum einen darin, dass es von
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
29
neuesten Methoden und Werkzeugen profitieren kann. Zum anderen werden umfangreiche
Erfahrungen zentral erfasst und verwaltet, was den Informationsaustausch sowie den
Wissenstransfer erleichtert. Durch das erweiterte Aufgabengebiet (Forschung) ist das SMT-
Team im Unterhalt etwas günstiger als ein zentrales Testteam, verursacht jedoch „für die
Organisation höhere Kosten als ein einfaches Stovepipe-Team“. ([DUST], S. 172, 177f, 180)
Abbildung 7: Beispielhafte Organisation verschiedener Testteamtypen ([DUST], S. 173)
Unabhängig von der Organisationsform gibt es Dustin/Rashka/Paul Aspekte, die für eine
erfolgreiche Testgruppe kennzeichnend sind. Diese 10 Stoßrichtungen sind im Folgenden
aufgelistet
• Wirtschaftliche Kenntnisse. Testingenieure benötigen wirtschaftliche Kenntnisse
und sollten eng mit Anwendern und Benutzern des Systems zusammen arbeiten.
• Technische Kenntnisse. Um zunehmend komplexere Anwendungen zu
beherrschen ist aktuelle technische Expertise im Bereich der Werkzeuge, der
Softwareentwicklung und bei der Bewertung der Usability notwendig.
• Aufgabenteilung. Trennung von technischen und wirtschaftlichen Aufgaben, von
funktionalen und nichtfunktionalen Tests, etc.
• Ressourcenmanagement. Kombination technischer und wirtschaftlicher Ressourcen
wenn möglich und sinnvoll.
• Verhältnis zum Entwicklungsteam. Testingenieure sollten mit den Entwicklern
Hand in Hand arbeiten.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
30
• Frühe Einbeziehung in den Lebenszyklus. Das Testteam sollte von Beginn an in
die Entwicklung miteinbezogen werden.
• Definierte Testmethoden. Methoden, Normen und Prozesse müssen bekannt und
verfügbar sein und sollten nach Bedarf angepasst oder neu implementiert werden.
• Flexibilität und Anpassungsfähigkeit. Neue Anwendungen erfordern meist
modifizierte Teststrategien. Altbewährtes sollte nicht ohne kritischen Review
übernommen werden.
• Metriken 1. Um den Testprozess zu verbessern, sollte das Team lernen, welche
Metriken dazu während der gesamten Entwicklung erfasst und angewendet werden
müssen.
• Prozessverbesserung. Das Testteam sollte nach stetiger Verbesserung seiner
definierten Methoden und Prozesse streben und dabei die gesamte Prozesskette im
Auge behalten.
([DUST], S. 180f)
2.4.3. Wartungsfreundliche Testverfahren
Testverfahren sollten nicht nur hinsichtlich ihrer Wiederverwendbarkeit entwickelt werden,
sondern auch Richtlinien zur Steigerung der Wartungsfreundlichkeit folgen. Wenn Tests
durch veränderte Software angepasst werden müssen, gibt es teils einfache Standards, die
deren Wartungsfreundlichkeit erhöhen. Im Folgenden findet sich eine diesbezügliche
Übersicht ([DUST], S. 367 ff)
• Befolgen von Formatierungsstandards
Diese Standards sollen für die leichte Lesbarkeit von Quellcode sorgen und legen
das äußere Erscheinungsbild fest. Es können etwa Vorgaben über den Einzug oder
die Hervorhebung von Anweisungen gemacht werden, etc. Eine weitere Hilfe ist das
Auskommentieren von Testprozeduren bzw. deren Quellcode. Hier können die
logischen Überlegungen des Testingenieurs, die Reichweite des Tests zum besseren
Verständnis der Struktur wiedergegeben werden.
1 Metrik: Eine Metrik ist eine auf den Eigenschaften der Software basierende Maßzahl. Dieser Wert
kann als Erfüllungsgrad einer Qualitätseigenschaft betrachtet werden und hilft bei der Vergleichbarkeit
von Entwicklungen.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
31
• Dokumentieren von Testskripts
Die Dokumentation von Testskripts in normaler Sprache erleichtert die
Nachvollziehbarkeit für Personen, die nicht über die Programmierkenntnisse
verfügen, um Skriptsprache lesen zu können. Zusätzlich wird der Wert der Skripte in
einer Bibliothek durch eine angemessene Dokumentation erhöht.
• Berücksichtigen der Synchronisierung
Wenn das Skript bspw. eine komplexe Anfrage an eine Datenbank generiert, muss es
mit geeigneten Wartezeiten versehen werden, um die ggf. verlängerte Reaktionszeit
der Anwendung zu berücksichtigen, um immer mit dem Prüfling synchron zu laufen.
• Verwenden eines Testverfahrensindex
Um in der großen Datenmenge, die aus archivierten Testskripten entsteht, die gerade
passenden zu finden und einsetzen zu können, sollte eine Art Index gepflegt werden,
der z.B. über Schlüsselnummern die Wirkungsbereiche oder die durch das Skript
getesteten Features wiedergibt.
• Einführen einer Fehlerbehandlung
Ein Testskript sollte mit Blick auf die Fehler entworfen werden, die es am
wahrscheinlichsten aufdecken könnte. An kritischen Stellen können Fehlerkontrollen
eingebaut werden, die so eine genauere Lokalisierung der Fehler und insgesamt
stabilere Testskripts ermöglichen. Stabiler deswegen, da durch die bewusste
Fehlererkennung ggf. noch nachgeordnete Tests ausgeführt werden können, wenn
ansonsten der Test scheitern würde.
• Befolgen von Namenskonventionen
Diese helfen beim Entschlüsseln der Struktur und der Logik von Skripts, bspw. durch
anwendungsübergreifende und selbstdokumentierende Variablen (Format, Variable
oder Konstante, etc.)
• Erstellen von Modularitätsskripts
Kürzere, oder in logische Module unterteilte Skripts sind leichter zu verstehen.
Komplexe Skriptstrukturen können so vereinfacht werden, zudem lässt sich eine
Aufgabenverteilung vornehmen. Im Falle einer Änderung muss nur der betroffene
Skriptteil überarbeitet werden.
• Verwendung von Schleifenkonstrukten
Schleifen unterstützen die Modularität und Übersichtlichkeit eines Skripts, außerdem
erhöhen sie die Anpassbarkeit des Skripts auf veränderte Durchlaufzahlen einer
Aktion. Auch erlauben z.B. statusabfragende Schleifen das unbeaufsichtigte
Ausführen eines Skripts.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
32
• Verwendung von Verzweigungskonstrukten
Basierend auf dem Wert einer Variablen (z.B. true, false) nimmt das Skript
unterschiedliche Pfade durch die Anwendung. So können wie oben bei bestimmten
Fehlerwerten ggf. durch das automatische Wechseln der Skripts andere Funktionen
noch getestet werden.
• Kontextunabhängigkeit
Richtlinien für den Kontext sollten definieren, wo ein Testverfahren beginnt und wo es
endet. Dadurch kann das Skript entweder selbstständig überprüfen ob seine
notwendigen Randbedingungen gelten, oder selbstständig durch die Anwendung
laufen, bis diese erfüllt sind, um dann den eigentlichen Test zu beginnen. So können
modulare Skripts voneinander unabhängig ausgeführt werden.
• Verwenden von globalen Dateien
Übergeordnete Testprozeduren sollten inklusive aller zugehörigen Variablen global
deklariert und allen Skripts zugänglich gemacht werden (mittels include-Anweisung).
So können Deklarationsfehler vermieden und der Änderungsaufwand übergeordneter
Elemente reduziert werden.
2.4.4. Aufgaben im Softwaretest
Im Folgenden wird eine Liste von Aktivitäten vorgestellt, die rund um ein Softwaretestprojekt
entstehen können ([DUST], S. 182 ff). Nicht in jedem Projekt werden alle Tätigkeiten
anfallen, aber das Sammeln der zugehörigen Aufwandsdaten erleichtert langfristig die
Kalkulation des Testaufwandes für neue Projekte. Organisationsspezifisch sind ggf. weitere
Unterteilungen dieser Tätigkeitsliste notwendig.
1. Beginn des Projektes
a. Prozessverbesserung. Review von Kenntnissen aus früheren Projekten.
Entscheidung, welche Verbesserungsaktivitäten implementiert werden sollen
b. Prozess. Verständnis für Automatisierte Testlebenszyklusmethode
entwickeln.
c. Zielsetzung. Ziele definieren.
d. Umfang. Abschätzen des Testumfanges.
e. Teamzusammenstellung. Analyse der Teamzusammensetzung und
Aufgabenbeschreibung für die Testingenieure.
f. Einstellung. Stellenbeschreibungen ausarbeiten und Einstellungsgespräche
leiten.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
33
2. Frühe Unterstützung des Projektes
a. Ziele. Weitere Definition und Überprüfung der Testziele mit der Projektleitung,
der Entwicklung und den Testingenieuren.
b. Prüfung der Einschränkungen. Entwicklungsphase und Ressourcen.
c. Review der Testfähigkeit. Ist das System testfähig?
d. Review der Anforderungen. Sind die Anforderungen testfähig formuliert?
e. Review der Normen. Anwendbare Normen identifizieren und kennen,
fehlende Normen definieren.
f. Analyse des Testprozesses. Wie arbeitet aktuell die Organisation?
g. Einbeziehung des Kunden. Auch den Einbezug des Kunden von Beginn des
Testlebenszyklus an sicherstellen.
3. Entscheidung für automatisiertes Testen
a. Testziele und Teststrategien. Ziele Definieren und Strategien entwickeln –
was soll mit der Automatisierung konkret erreicht werden und auf welchem
Weg?
b. Nutzen des Testwerkzeuges. Abschätzen der Vorteile eines Werkzeuges.
c. Vorschlag eines Testwerkzeuges. Vorschlag zum Erwerb ausarbeiten.
4. Auswahl und Bewertung des Testwerkzeuges
a. Systementwicklungsumgebung. Organisationsbezogenes Review.
b. Verfügbare Testwerkzeuge. Typreview.
c. In Frage kommende Werkzeuge. Erforschung, Bewertung und Einschätzung
der potentiellen Werkzeuge.
d. Definieren der Bewertungskriterien. Funktional, Nichtfunktional, etc.
e. Leiten der Bewertung. Ergebnisse möglichst quantifizieren.
f. Zusammenfassen der Bewertung. Dokumentation der Werkzeugauswahl,
Bewertungsergebnisse kompakt und visualisiert.
g. Erwerb des Testwerkzeuges. Operative Beschaffung im Einkauf.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
34
5. Einführung des Testwerkzeuges
a. Testprozess. Falls noch nicht vorhanden: Implementieren des Prozesses und
seiner Methoden hin zu automatisierten Werkzeugen. Testen parallel zur
Entwicklung. Einrichten eines Einführungsprozesses für Testwerkzeuge
(Change Management).
b. Fehlerbeseitigungsaktivitäten. Inspektionen, Walkthroughs und andere
Tätigkeiten.
c. Kenntnisse im Umgang mit Testwerkzeug. Schulungen, Review der
Handbücher, Übungen, Werkzeugexperten, etc.
d. Testwerkzeugvalidierung. Neue Versionen validieren, Werkzeugeinsatz
gemäß Spezifikation und Arbeitsumgebung verifizieren.
e. Testberatung. Support bei Fragen zu Werkzeug und Prozess durch den
Testingenieur. Probleme und Lösungen zur Wissenssicherung
dokumentieren.
f. Testwerkzeugorientierung. Präsentationen und Vorführungen zum
Testwerkzeug durch den Testingenieur um Eindrücke davon zu vermitteln.
g. Einrichtung der Netzwerkumgebung. Datenbank mit Link zum
Testwerkzeug, erweiterte Speicherkapazitäten, etc.
h. Fehlermanagementprozess. Aufbau eines Prozesses zur Fehlerübermittlung
und Lösung, verwendbare Normen aufzeigen.
i. Schulung zum Fehlermanagement. Prozessorientierte Schulungsangebote
aufbauen.
j. Testwerkzeugberichte. Welche Arten automatisierter Testberichte sind
möglich?
6. Testplanung
a. Testanforderungen. Dokumentieren der Anforderungen für die zu testende
Anwendung entsprechend der Systemanforderungen.
b. Prüfung der Einschränkungen. Entwicklungsphase und Ressourcen.
c. Testziele. Definition der Ziele wie Skalierbarkeit, Regression, Einbeziehung
der Endanwender in den Testprozess, etc.
d. Teststrategie. Strategien und Werkzeugtypen dokumentieren.
e. Testprogrammaktivitäten. Strategie entwickeln, bei der Testaktivitäten früh
in den Entwicklungszyklus einbezogen werden.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
35
f. Zwischenprodukte. Identifizieren von Zwischenprodukten oder Leistungen,
die einem Review unterzogen werden können.
g. Kritische Erfolgsfunktionen. Identifizierung und Dokumentation kritischer
Funktionen zusammen mit den Anwendern.
h. Testprogrammparameter. Voraussetzungen, Vorbereitungsaktivitäten,
Systemakzeptanzkriterien, Testprogrammrisiken inkl. Dokumentation.
i. Qualitätsniveau. Feststellung des bisherigen und Festlegen des geplanten
Qualitätsniveaus inkl. Dokumentation im Testplan.
j. Testprozess. Prozess im Testplan dokumentieren inklusive der
Testwerkzeugeinführung und des Fehlermanagements.
k. Testschulung. Schulungsanforderungen und Schulungspläne
dokumentieren.
l. Entscheidung für Automatisiertes Testen. Vorteile und Einschätzungen
bezüglich der Verwendung von Testautomatisierung dokumentieren (Details
siehe 3. Bis 5.)
m. Technische Umgebung. Dokumentieren der techn. Anwendungsumgebung.
Potentielle Probleme und mögliche technische Fragen dokumentieren.
n. Überprüfung der Testwerkzeugkompatibilität. Ergebnisse,
Problemlösungen und Alternativen dokumentieren.
o. Quality Gates. Diese mit einplanen, ggf. definieren.
p. Risikoabschätzung. Risiken mit Maximalkosten und
Eintrittswahrscheinlichkeit auf einen konkreten Geldwert quantifizieren.
q. Review der Testbereitschaft. Planung von Analyseaktivitäten zur
Unterstützung der Reviews.
r. Testplandokument. Aus der Testplandokumentation wird ein
zusammengefasster Testplan. Änderungen nur nach Absprache mit
Projektleitung und Endanwender.
s. Testdaten. Dokumentieren von Testdatenanforderungen und Testplänen im
Hinblick auf das Einrichten einer Datenbank.
t. Testumgebung. Testlaboranforderungen identifizieren, Personal für
Einrichtung und Dokumentation benennen.
u. Berichtsanforderungen. Diese definieren und im Testplan dokumentieren.
v. Rollen und Verantwortlichkeiten. Aufgaben-Kompetenzen-Verantwortung
(AKV) für alle Teammitglieder eindeutig und für alle einsehbar definieren.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
36
w. Systemadministration des Testwerkzeuges. Anforderungen für Einrichten
und Unterhalt der Werkzeuglandschaft inkl. Benennung des zugehörigen
Personals.
7. Testdesign
a. Prototyp der automatisierten Umgebung. Erste Testumgebung einrichten
zum Umsetzen des Testdesigns und der Testentwicklung.
b. Techniken und Werkzeuge. Identifizieren von Techniken und Werkzeugen
für die Verwendung in der Projektanwendung und deren Schnittstellen.
c. Designnormen. Normen für das Testverfahren vorbereiten (Wartung,
Wiederverwendbarkeit, etc.)
d. Design von Testverfahren und Testskripts. Liste und Hierarchie von
Verfahren und Skripts. Prozeduren und manuelle Skripts ggf. mit
automatisierter Unterstützung identifizieren, ggf. Entscheidung über und
Definition alternativer Verifikationsverfahren.
e. Zuweisung der Testverfahren und Testskripts. Personal zuweisen.
f. Eingaben/Ausgaben. Entwickeln der Eingaben und erwarteten Ausgaben der
Testverfahren und Testskripts.
g. Skriptbibliothek für die Testautomatisierung. Im Projekt verwendbare
Skripts aus den Bibliotheken herausfiltern.
8. Testentwicklung
a. Empfohlene Normen und Vorgehensweisen. Diese müssen für das Testen
der aktuellen Anwendung meistens adaptiert werden.
b. Normen für die Testverfahrensentwicklung. Ggf. neue entwickeln,
festhalten (Kommentare, Formate für Quellcode, etc.). Siehe hierzu auch
2.4.3.
c. Normen für die Skriptausführung. U.a. für Durchführung von Testverfahren.
d. Testeinrichtung. Implementierung der Skripts während Regressionstest,
Leistungstest, etc.
e. Pseudocode. Schrittweises Vorbereiten der Testverfahren, evtl. als Anhang
zum Testplan.
f. Problemlösungen. Für Inkompatibilitätsprobleme o.ä.
g. Entwickeln von Testverfahren/-skripts. Für verschiedene Testphasen oder
Teiltests.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
37
h. Unittest. Entwickeln von Testverfahren/-skripts.
i. Integrationstest. Entwickeln von Testverfahren/-skripts.
j. Systemtest. Entwickeln von Testverfahren/-skripts.
k. Entwickeln eines Ausführungsplans für die Testverfa hren.
l. Analyse der Wiederverwendbarkeit der automatisierte n Tests.
m. Analyse zur Bestimmung der zu automatisierenden Tes ts.
n. Entwickeln einer Matrix mit den Modularitätsbeziehu ngen.
o. Akzeptanztest. Entwickeln von Testverfahren/-skripts.
p. Datenbankgruppenkoordination. Mit Datenbankgruppe entwickeln der
Testdatenbankumgebung, der Baseline und Testdatenpflege.
q. Peer Reviews im Testverfahren. Vergleich der Tests mit Design- und
Entwicklungsnormen. Dokumentation und Verwaltung von Fehlern und
Feststellungen.
r. Wiederverwendungsbibliothek. Entwicklung und Pflege.
s. Testhilfen. Hilfsprogramme, die die Testeffizienz erhöhen.
9. Testdurchführung
a. Einrichten der Testumgebung. Ggf. Skripts entwickeln, die dies
übernehmen.
b. Testbed-Umgebung. Referenzskripts entwickeln, logistische Aktivitäten zur
Testbed-Entwicklung durchführen.
c. Testdurchführung. Entlang der verschiedenen Phasen, strategische
Ausführung der Testautomatisierung. Fehlerdokumentation.
d. Testzusammenfassung. Vorbereitung von Testberichten.
e. Problemlösung. Tägliche Fragen zu Problemen mit den Werkzeugen. Ggf.
Herstellersupport anfordern.
f. Pflege der Testdatenbank. Sichern/Wiederherstellen der
Testwerkzeugdatenbank, Durchführen von Aktivitäten zur Fehlersuche.
10. Testmanagement und Testunterstützung
a. Prozessreviews. Diese dienen der Sicherstellung der Einhaltung des
definierten Prozesses.
b. Spezielle Weiterbildung. Schulungen auf spezielle Testanforderungen.
Ausbau technischer Kenntnisse.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
38
c. Konfigurationsmanagement. Verwaltung des Testbeds via Datenbank
(Testdaten, Verfahren, Problemberichte, etc.) zur Sicherstellung der
Wiederverwendbarkeit.
d. Bericht zum Testprogrammstatus. Mechanismen zur Verfolgung des
Testprogrammfortschritts (periodische Berichte, etc.).
e. Fehlermanagement. Fehlerverfolgungsprozess, Ausführen der
Fehlerverfolgung und Fehlerberichte, Teilnahme an Konferenzen zur
Fehleranalyse.
f. Erfassung und Analyse von Metriken. Review der Metriken hinsichtlich
Notwendigkeit von Verfahrensänderungen, Feststellung der Marktreife.
11. Verbesserung des Testprozesses
a. Schulungsmaterial. Entwickeln und pflegen von Weiterbildungsmaterial für
Testprozesse und Werkzeuge.
b. Testprozessressourcen. Unterhalten einer Datenbank mit Normen,
Prozessen, Verfahren, Werkzeugvorschlägen, Werkzeugbewertungen,
Aufwandsdaten früherer Projekte, Testwissen, Skripts und Analysen.
c. Erworbenes Wissen. Sitzungen zum Wissensaustausch, sammeln von
Informationen über den gesamten Entwicklungslebenszyklus.
d. Analyse und Zusammenfassung von Metriken. Innerhalb der Organisation
verwendete Metriken analysieren, Ergebnisse zusammengefasst zugänglich
machen.
e. Testteam-Intranet. Testteam-Website zur Kommunikation mit der restlichen
Organisation, als Wiki o.ä.
f. Untersuchung der Projektunterstützung. Wie kann der Testprozess
verbessert werden und das Testteam unterstützte Projekte noch besser
voranbringen?
g. Stetige Prozessverbesserung. Weiterentwicklung der Ressourcen im
Testprozess anhand des erworbenen Wissens, mittels Umfrageergebnissen,
etc.
h. Testkonferenzen und Berufsverbände. Mitwirken in Usergroups von
Werkzeuganbietern, Konferenzen und Zusammenkünfte zum
Informationsaustausch und Networking über die Grenzen der eigenen
Branche hinaus.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
39
2.5. Dowie „Testaufwandsschätzung in der
Softwareentwicklung“
Als ein wesentlicher Faktor zur Bestimmung der Wirtschaftlichkeit von
Testautomatisierungsvorhaben wird in der ausgewerteten Literatur die Erfassung tatsächlich
entstehender Testaufwände beim manuellen Test genannt.
Diese Testaufwände werden in Softwareprojekten wegen unrealistischer und ungenauer
Abschätzung von Projektkennzahlen regelmäßig unterschätzt. Die daraus entstehenden
Folgen für die Projekte sind etwa die mangelnde Steuerbarkeit, nicht identifizierte Risiken
oder völliges Scheitern (Dowie 2009). In ihrer Dissertation formuliert Ulrike Dowie ein Modell
zur Aufwandsermittlung, das auch an verschiedenen Projekten validiert wurde. Die
Datengrundlage sind 58 Projekte aus insgesamt zwei softwareentwickelnden
Organisationen. (37 Projekte < 2500 MT; 9 Projekte > 5000 MT, 60%
Weiterentwicklungsprojekte).
So wurden die Testaufwände in Abhängigkeit verschiedener Einflussfaktoren definiert. Eine
vereinfachte Darstellung dieser Testaufwandsgleichung findet sich nachfolgend (vgl. [DOW]):
Für Neuentwicklungsprojekte sind etwa die Abhängigkeit von Zulieferungen, die Anzahl der
Sprachen im Entwicklerteam (gerade bei multinationalen Konzernen ein wichtiger Faktor)
sowie die Erfahrung der Entwickler und auch Systemkenngrößen, wie die Anzahl der
Releases relevant. Ein individuell wählbarer Störfaktor S ergänzt die Faktoren.
�Q +�QHR. '. T%,��+�#%�U��, Q�W. L"#-XR��, *#+. $. *��K. , L� �Q +�QHR. '. T%,��+�#%�U��, Q�W. L"#-XR��, *#+. $. *��K. , Q�W. Y�,�-���, L
Für Verbesserungsprojekte werden einige andere Faktoren genannt, etwa die Anzahl
externer Schnittstellen und die verfügbare Zeit. Dieser Zeitfaktor ist gerade bei
Optimierungsprojekten auf Basis eines bestehenden Produktes eine oftmals unterschätzte
Einflussgröße.
�Q +�Q�W. �Z�. LL, *#+. $. *��K. , '�#+. T���, L� �Q +�Q�W. �Z�. LL, '�#+. T���, L�
Die Schlussfolgerung dieser Quelle ist im Wesentlichen diese: Um valide die
Wirtschaftlichkeit des automatisierten Testprozesses zu bewerten, müssen Aufwände exakt
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
40
vermessen werden. Die Sammlung organisationsspezifischer Daten zu abgeschlossenen
Projekten ist zur Aufwandsschätzung absolut notwendig. Auch müssen analysierte und zu
schätzende Projekte hinsichtlich der Ausprägung mehrerer Merkmale vergleichbar sein. Die
Quantifizierung der Ausprägung dieser Merkmale ist dabei komplexer als die Auswahl der
Einflussfaktoren selbst.
Die Autorin weist ebenfalls auf die hervorgehobene Bedeutung messbarer Kennzahlen hin.
Sobald eine Kennzahl mit vorliegenden Messwerten valide quantifizierbar ist, sollte sie auf
jeden Fall bevorzugt behandelt werden.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
41
3. Literaturübersicht – Paper und Fachartikel
3.1. Hoffman – „Cost Benefits Analysis of Test Auto mation“
Es gilt weiterhin festzuhalten, dass die Softwaretestautomatisierung nicht nur Auswirkungen
innerhalb der Testabteilung hat. Vielmehr bringt sie einen Einfluss auf alle Projekt- und
Organisationsbereiche mit sich (Hoffman 1999). So wird etwa die Projektkomplexität
signifikant erhöht, etwa durch komplexere Planungs- und Testimplementierungsprozesse. Es
werden von den Mitarbeitern und Projektleitern andere Fähigkeiten verlangt – z.B. im
Hinblick auf die Fähigkeit zur Beurteilung des sinnvollen Automatisierungsgrades eines
Softwaretests. Es ergeben sich aber auch andere Arbeitsabläufe und neue Prozesse. So
müssen die Prozesse der Testautomatisierung und Wartung mit der Produktentwicklung
abgestimmt, Testberichte müssen validiert und effizient in die Entwicklung rückgeführt
werden etc. Zu guter Letzt wird auch die Infrastruktur beeinflusst: Es müssen die
Möglichkeiten für automatisiertes Testen geschaffen werden, was z.B. durch die
Anschaffung bestimmter Tools oder Hardwareumgebungen (HIL) geschaffen werden kann.
Die Bedeutung messbarer Kennzahlen findet sich in verschiedenen Quellen zur
Testautomatisierung. Auch Hoffman formuliert es so, dass belastbare Erkenntnisse zum ROI
der Testautomatisierung nur über messbare Zahlenwerte (Kosten) zu Stande kämen
(Hoffman 1999). Um das Verhältnis von Kosten und Nutzen einzuschätzen sollen
verschiedene Beispiele für Automatisierungskosten und Automatisierungsnutzen vorgestellt
werden:
Beispiele für Automatisierungskosten:
• Kosten für Hardware, Softwarelizenzen und Support
• Automatisierungsumgebung: Design und Implementierung
• Testfallgenerierung und Wartung
Nutzen durch die Automatisierung:
• Einsparungen beim Aufwand zur Testausführung
• Tests laufen bedienerunabhängig, auch nachts oder am Wochenende
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
42
• Ggf. Qualitätsoptimierung durch Reduzierung des Fehlerfaktors Mensch im
Testdurchlauf
Die Berechnung der Effizienz der Testautomatisierung erfolgt in zwei Gleichungen [HOF]:
*� Q�Q3 �[� � � ∗ \���[3 � � ∗ \3�
*�] Q�Q3 �[� � �^ ∗ \���[3 � �_ ∗ \3�
[�= Ausgaben für Testspezifikation und –implementierung
[3 = Ausgaben für Testspezifikation
\�= Ausgaben für Ergebnisinterpretation nach dem Test
\3= Ausgaben für manuelle Einzeltestausführung
Die Gleichung mit dem Ergebnis *� nimmt dabei eine identische Anzahl an Testdurchläufen
an. Das realitätsnähere (Anm. d. Verf.) Ergebnis *�] in der zweiten Gleichung berücksichtigt
eine unterschiedliche Anzahl an Testdurchläufen. In einer definierten Zeitspanne sollte der
automatisierte Test mehr Durchläufe absolvieren, als ein Tester im manuellen Prozess.
Die Berechnung des ROI der Testautomatisierung erfolgt ebenfalls in zwei Gleichungen
[HOF]:
Y`a�0���� �Q%��N-�����#%�U��%�W����Q%��N-�����#%�U�&������ �.�
Y`a�0���� ∆�%�W��Q%� c d-��∆�.�����Q%� c d-�� ∆�∆.�
Hier ist zum einen der ROI global als Verhältnis von Automatisierungsnutzen zu
Automatisierungskosten dargestellt. Da für die Amortisation eines
Automatisierungsvorhabens aber die Differenzen gegenüber dem Manuellen Test
interessant sind, erweitert Hoffman seine Gleichung.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
43
Er bestimmt den ROI der Testautomatisierung nun über das Verhältnis aus höherem Nutzen
durch Automatisierung gegenüber manuellem Test und höheren Kosten der Automatisierung
gegenüber der manuellen Durchführung.
Berechnung der inkrementellen Nutzenzunahme [HOF]:
∆���� ef∆.g J,���,� h��ij � e�.���,3 ∗ �_ ���� k e�.���,� ∗ �^ ����
�= geplante Amortisationszeit, z.B. ein Vielfaches der Zeit zwischen Produktreleases
(praxisnahe Zahl!)
�= geplante Nutzungsdauer
Um den Nutzen der Testautomatisierung gegenüber dem manuellen Testen zu ermitteln,
summiert Hoffman alle Einzelnutzen auf. Ein erster Nutzenaspekt sind die langfristig
optimierten Fixkosten. Bspw. könnten in der Testdurchführung Personalstellen eingespart
werden. Diese Ersparnis wird in Relation zu Amortisationszeit und Nutzungsdauer gesetzt.
Ein Beispiel: Die geplante Amortisationszeit beträgt 5 Releases mit einem Release pro Jahr,
also t=5 Jahre. Die geplante Nutzungsdauer der Automatisierung geht über 3
Softwareproduktlebenszyklen mit je 5 Releases, z.B. T=3*5=15 Jahre. Dann dürfte im aktuell
zu projektierenden Testvorhaben nur ein Drittel der Fixkostenoptimierung als Nutzen geltend
gemacht werden.
Als weiterer Nutzen geht die Summe der variablen Kosten aus dem manuellen Testdurchlauf
ein. Diese Summe wird automatisiert komplett eingespart. Subtrahiert wird hingegen die
Summe der variablen Kosten, die beim automatisierten Testdurchlauf entstehen. Sie sollte
kleiner den manuellen variablen Kosten sein, also entsteht hier positiver Nutzen aus den
variablen Kosten.
Berechnung der inkrementellen Kostenzunahme [HOF]:
∆.���� ef∆.g J,6ö6��,� h��ij � e.���,��0,� k e.���,��0,3 � ef.���,=���,� O�^Pj
�^= Anzahl der automatisierten Testdurchläufe
= Anzahl der möglichen Testdurchläufe bevor Wartung notwendig ist
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
44
Die Berechnung der inkrementellen Kostenzunahme setzt sich ähnlich zusammen wie die
Nutzenberechnung. Hier werden zuerst die höheren Fixkosten durch Automatisierung
(Hardware, Software, Mitarbeiterschulung o.ä.) anteilig für ein Testprojekt berücksichtigt. Das
Verhältnis von Amortisationsdauer zu Nutzungsdauer bestimmt wie oben den Anteil.
Weiterhin werden die neu entstehenden variablen Kosten des automatisierten Tests
berücksichtigt. Die für einen Test neu entstehenden manuellen variablen Kosten werden
eingespart, daher subtrahiert. Die letzte Summe befasst sich mit der Wartung des
automatisierten Tests. Hier entstehen variable Kosten (z.B. Arbeitsaufwand des
Mitarbeiters). Diese werden wie die Fixkosten anteilig berücksichtigt. Allerdings ergibt sich
der Anteil hier aus der Anzahl der automatisierten Testdurchläufe und der Anzahl der
möglichen Testdurchläufe, bevor Wartungsumfänge notwendig sind. Können z.B. 5
Testdurchläufe ohne Wartungsaufwand gefahren werden und es sind 10 Testdurchläufe
geplant, so müssen diese variablen Kosten doppelt berücksichtigt werden.
3.2. Schmid et. al – „Wann lohnt sich die Automatis ierung
von Tests?“
Anlässlich der Tagung „Objektorientiertes Programmieren (OOP) 2006“ thematisieren Gregor
Schmid und Frank Schmeißner von der imbus AG, einem „Lösungsanbieter für die
Qualitätssicherung und das Testen von Software“, das Thema wann sich Automatisierung
von Tests lohnt. Insgesamt werden in dieser Quelle anhand der fundamentalen Testphasen
Aussagen zu deren Auswirkungen auf den ROI der Testautomatisierung gemacht. Die
fundamentalen Phasen sind (siehe hierzu Abbildung 8) sind im Wesentlichen die Planung
und Spezifikation der Tests, die Entwicklung, Dokumentation und das Verwalten von
Testfällen, sowie letztlich die Testdurchführung mit Ergebnismanagement und Testfallpflege.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
45
Abbildung 8: Phasen im Testprozess ([SCH], S. 9)
Es gibt nun gerade in der Planung und Spezifikation der Tests und Testfälle
Aufgabenpakete, die sich nicht hinsichtlich der manuellen oder automatischen
Testausrichtung unterscheiden. Sobald die zu erledigenden Tasks aber komplexer oder
aufwändiger werden kann sich eine Automatisierung lohnen. Die nachfolgende Abbildung 9
zeigt vorwiegend noch Phasen mit geringer Auswirkung auf den ROI. Beispielhaft sei die
Verwaltung der Testfälle noch näher erläutert: Zwar würde die automatisierte Verwaltung der
Dokumente allein vielleicht Umfänge senken, in Summe fallen hier bei der automatisierten
Bearbeitung aber mehr Tasks insgesamt an, daher gleicht sich der Effekt wieder
weitestgehend aus.
Sobald jedoch länger andauernde Tätigkeiten, wie etwa das Eintragen der Ergebnisse
ersetzt werden können, beginnt der Bereich ROI-beeinflussender Phasen. In der
nachfolgenden Abbildung ist dies an ersten Punkten im Umgang mit den Testergebnissen zu
sehen. Das manuelle Eintragen der Ergebnisse fällt nach jedem Test in vergleichbarem
Umfang an. Ein automatisiertes Erstellen der jeweiligen Reports per Knopfdruck oder
Mausklick spart hier nach jedem Test Aufwände ein. Die für die Testautomatisierung
relevanten Faktoren sind auch hier u.a. die Wiederholbarkeit der Aktivität ohne Anpassung,
sowie die Einsparung pro Ausführung.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
46
Abbildung 9: Phasen mit geringem Einfluss auf ROI ([SCH], S. 9)
Weitere Testprozessphasen mit starken Auswirkungen auf die Testautomatisierung zeigt die
nachfolgend dargestellte Abbildung 10. Bei den manuell lang andauernden Aufgaben der
Implementierung von Testfällen, der Testdurchführung an sich sowie der Testfallpflege (z.B.
in Datenbank) lässt sich durch den Einsatz automatisierter Routinen Aufwand einsparen.
Wichtig ist es bei diesen Prozessphasen, die wesentlichen Einflussfaktoren zu kennen und
entsprechend aufmerksam zu beobachten.
Abbildung 10: Phasen mit starkem Einfluss auf ROI ([SCH], S. 10)
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
47
4. Zusammenfassung
Welche Aussagen können nun also getroffen werden, wenn man die wesentlichen
Fragestellungen aus Kapitel 1 wieder aufgreift? Welche Faktoren überhaupt eine Rolle im
Softwaretestprojekt spielen, kann sehr gut beurteilt werden. Die Aussagen sind, da rein auf
die Kriterien überhaupt bezogen, rein qualitativ. Wie oft ein Test wiederholt werden muss, bis
er automatisiert wird, ist schwierig zu beantworten. Überwiegende Faktoren sind die Anzahl
der Ausführungen und die Wartungsfreundlichkeit. Werden diese signifikant gesenkt, ist eine
kleinere Anzahl an Ausführungen bis zum Break-Even wahrscheinlich.
Bezogen auf die Fragestellung der einfach zu automatisierenden Testfälle wird die
Modularität als wichtig bewertet. Modular aufgebaute und einzeln lauffähige Testfälle sind
leichter automatisierbar, da sie sich ihre notwendigen Randbedingungen ggf. selbst
generieren können.
Enorme Risikofaktoren für das Projekt bestehen einerseits dann, wenn nicht ausreichend
granular und realitätsnah geplant wird. Zum anderen steigt das Risiko, wenn der Test als
ganzes nicht in den Entwicklungsprozess integriert, sondern nachgeschaltet wird. Ein
weiteres Risiko entsteht, wenn der Test nach seinem Aufbau nicht zur Freigabe an den
Anforderungen gemessen wird. Dann besteht die Gefahr, dass keine ausreichende
Testabdeckung oder Testtiefe gegeben ist.
Tatsächliche Testaufwände lassen sich anhand verschiedener Formeln mit organisations-
und projektspezifischen Faktoren berechnen. Wichtig ist hierbei die Qualität der
Datengrundlage. Auch die selbstkritische Einstufung nach verschiedenen Faktoren und
Reifegraden sollte stattfinden, da sonst schnell die Ergebnisse verfälscht werden.
Der hier dargestellte Stand der Technik im Hinblick auf die Ansätze und Methoden rund um
das Thema Softwaretest und Testautomatisierung zeigt vorwiegend qualitative
Überlegungen. Das Fehlen von umfassenden, exakt quantifizierten Richtlinien bei der
Beurteilung der Wirtschaftlichkeit und des sinnvollen Automatisierungsgrades von
Softwaretestprojekten sorgt für die Manifestierung der Forschungsfrage von V²bIT im Bereich
Guidelines für die Verifikation. Die Annäherung bspw. über die Messung realer Aufwände in
verschiedenen Projekten stellt dabei eine anerkannte und erprobte Herangehensweise dar.
_____________________________________________________________________________________________________ IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen
www.iwt-wirtschaft-und-technik.de
48
5. Literaturverzeichnis
[DOW] Dowie, Ulrike (2009): Testaufwandsschätzung in der Softwareentwicklung.
Modell der Einflussfaktoren und Methode zur organisationsspezifischen
Aufwandsschätzung. 1. Aufl. Lohmar, Köln: Eul (Reihe: Wirtschaftsinformatik,
Bd. 63).
[DUST] Dustin, Elfriede; Rashka, Jeff; Paul, John (2001): Software automatisch testen.
Verfahren, Handhabung und Leistung. Berlin, Heidelberg, New York: Springer
(Xpert.press).
[HOF] Hoffman, Douglas (1999): Cost Benefits Analysis of Test Automation. Online
verfügbar unter
http://www.softwarequalitymethods.com/papers/star99%20model%20paper.pd
f, zuletzt geprüft am 07.11.2013.
[SCH] Schmid, Gregor; Schmeißner, Frank; „Wann Lohnt sich die Automatisierung
von Tests?“; anlässlich der Tagung „Objektorientiertes Programmieren 2006“;
Quality First Software GmbH, Imbus AG, 18.01.2006
[SEID] Seidl, Richard; Baumgartner, Manfred; Bucsics, Thomas (2012): Basiswissen
Testautomatisierung. 1. Aufl. Heidelberg: dpunkt-Verl.
[SNE] Sneed, Harry M.; Baumgartner, Manfred; Seidl, Richard (2012): Der
Systemtest. Von den Anforderungen zum Qualitätsnachweis. 3., aktualis. und
erw. Aufl. München: Hanser.
[SPIL] Spillner, Andreas; Linz, Tilo (2010): Basiswissen Softwaretest. Aus- und
Weiterbildung zum Certified Tester ; Foundation level nach ISTQB-Standard.
4., überarb. und aktualisierte Aufl. Heidelberg: dpunkt-Verl.