Methoden und Vorgehensweisen im Softwaretestprozess ...€¦ · zum Thema Softwaretest,...

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.



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



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



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?



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.



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



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.



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.



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



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%



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)



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)



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



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)



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)



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.



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,



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



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)



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



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.



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



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



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



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



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)



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



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



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



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



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



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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



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.



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



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.



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



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.



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.



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)



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.



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.

Methoden und Vorgehensweisen im Softwaretestprozess ...€¦ · zum Thema Softwaretest,...

Documents

Transcript of Methoden und Vorgehensweisen im Softwaretestprozess ...€¦ · zum Thema Softwaretest,...