Verifikation bedienergeführter IT-Systeme unter ... · Verifikation bedienergeführter IT-Systeme...

Verifikation bedienergeführter IT-Systeme unter Wirtschaftlichkeitsaspekten

Abschlussbericht

Prof. Dr.-Ing Wilhelm Ruckdeschel

IWT Wirtschaft und Technik GmbH

Friedrichshafen, den 31.12.2015

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

1

Kurzfassung

Die Entwicklung innovativer Softwaresysteme ist eine anspruchsvolle Aufgabe: Es sollen in

kurzer Zeit Produkte mit hoher Qualität entwickelt und freigegeben werden, ohne dabei

Budgetgrenzen zu überschreiten. Ein erheblicher Teil der Projektbudgets wird dabei für

Tests eingesetzt, und dennoch bleiben immer wieder wichtige Fehler unentdeckt. Dies gilt im

Speziellen für bedienergeführte IT-Systeme, weil das Verhalten des Bedieners „Mensch“

besonders schwer vorhersagbar und modellierbar ist – im Gegensatz zu technischen

Systemen, für die es zumindest eine Spezifikation gibt.

Die Testteams stehen daher unter Druck, die Effizienz ihrer Aktivitäten zu optimieren.

Wichtige „Stellschrauben“ sind z.B. die Testorganisation, die Testprozesse, der

Werkzeugeinsatz sowie Art und Umfang die Testautomatisierung. Häufig werden aber die

entstehenden Aufwände und somit der Break-Even dieser Maßnahmen falsch eingeschätzt.

Das Ziel dieses Projektes ist daher, einen Beitrag zu leisten, die Wirtschaftlichkeit im

Softwaretest zu verbessern. Dies erfolgt einerseits durch die Begleitung und Analyse

konkreter Projekte von Projektpartnern in der Region, andererseits durch die Organisation

von Workshops und Fachtagungen, um den Erfahrungsaustausch und die Vernetzung

zwischen Unternehmen, Forschungseinrichtungen und Hochschulen zu fördern, damit die

Unternehmen daraus Erkenntnisse für die Optimierung ihrer eigenen Projekte gewinnen

können.

Eine Bedarfsanalyse ergab, dass die meisten Unternehmen in erheblicher Unsicherheit

agieren bzgl. der Aufwandsschätzung und Budgetierung von Softwaretestprojekten. Es

besteht großes Interesse daran, wie es eigentlich „die anderen machen“ und welche „best

practice“ Projekte als Benchmark dienen können.

Nach Auswertung der Literatur wird ein empirischer Projektansatz gewählt, d.h. Daten aus

realen Projekten werden erfasst und analysiert.

Im Rahmen dieses Projektes wurden Daten von vier Partnerunternehmen ausgewertet.

____________________________________________________________________________________________________


2

Inhaltsverzeichnis

1. Einleitung ................................................................................................................. 9

2. Bedarfsanalyse .......................................................................................................10

2.1. Interviews ...............................................................................................................10

2.2. Workshops und Fachtagungen ...............................................................................12

3. Stand der Technik ...................................................................................................14

3.1. Software-Test .........................................................................................................14

3.1.1. Sneed/Baumgartner „Der Systemtest“ .........................................................14

3.1.1.1. Einführung in den Systemtest ......................................................................14

3.1.1.2. Notwendigkeit des Testens ..........................................................................14

3.1.1.3. Testplanung .................................................................................................16

3.1.1.4. Schätzung der Testaufwände mit COCOMO-II ............................................17

3.1.1.5. Wartung und Weiterentwicklung ..................................................................23

3.1.1.6. Testautomatisierung – Ausbaustufen und Alternativen ................................23

3.1.1.7. Testmanagement .........................................................................................25

3.1.2. Seidl/Baumgartner „Basiswissen Testautomatisierung“ ...............................26

3.1.2.1. Der fundamentale Testprozess ....................................................................26

3.1.2.2. Automatisierte Testdurchführung .................................................................27

3.1.2.3. Softwarequalitätskriterien.............................................................................28

3.1.2.4. Integration von Testautomatisierung in die Organisation .............................30

3.1.3. Dustin/Rashka/Paul „Software automatisch testen“ .....................................34

3.1.3.1. Test Maturity Model (TMM) ..........................................................................34

3.1.3.2. Testteam-Management ................................................................................37

____________________________________________________________________________________________________


3

3.1.3.3. Wartungsfreundliche Testverfahren .............................................................42

3.1.3.4. Aufgaben im Softwaretest ............................................................................44

3.1.4. Dowie „Testaufwandsschätzung in der Softwareentwicklung“ ......................51

3.2. Wirtschaftlichkeit des Software-Tests .....................................................................53

3.2.1.1. Testkostenbeeinflussende Faktoren ............................................................53

3.2.1.2. Fehlerkosten ................................................................................................54

3.2.1.3. Qualitative Faktoren mit Einfluss auf die Testautomatisierung .....................55

3.2.1.4. Risikoanalyse ..............................................................................................56

3.2.2. Das Fehlermodell nach Kropfitsch & Vigenschow ........................................57

3.2.3. Das Qualitätskostenmodell von Wiemann ....................................................58

3.3. Wirtschaftlichkeit der Softwaretest-Automatisierung ...............................................58

3.3.1. Einführung ...................................................................................................59

3.3.2. Hoffman – „Cost Benefits Analysis of Test Automation“ ...............................63

3.3.3. Schmid et. al – „Wann lohnt sich die Automatisierung von Tests?“ ..............67

3.3.4. Einflussfaktoren ...........................................................................................70

3.3.5. Risikoanalyse ..............................................................................................71

3.4. Zusammenfassung .................................................................................................72

4. Methode ...................................................................................................................74

4.1. Ansatz ....................................................................................................................74

4.2. Datenerfassung ......................................................................................................74

4.3. Auswertungskonzept ..............................................................................................75

4.3.1. Anforderungen .............................................................................................75

4.3.2. Datengrundlage ...........................................................................................76

____________________________________________________________________________________________________


4

4.3.3. Grundsätzliches Vorgehen ...........................................................................78

4.3.4. Datenbankentwurf .......................................................................................78

5. Projekt A ..................................................................................................................82

5.1. Eckdaten ................................................................................................................82

5.2. Systematik ..............................................................................................................82

5.2.1. Datenerfassung ...........................................................................................82

5.2.2. Datenbasis ..................................................................................................82

5.2.3. Fehlfarbendarstellung ..................................................................................83

5.2.4. Umfang der Datenbank ................................................................................83

5.3. Übersichtsdaten ......................................................................................................83

5.3.1. Gesamtstunden pro Mitarbeiter ...................................................................83

5.3.2. Verteilung der Gesamtstunden ....................................................................84

5.3.3. Verteilung auf Kategorien ............................................................................85

5.3.4. Verteilung Overhead ....................................................................................87

5.3.5. Anteil Mitarbeiter am Overhead ...................................................................87

5.3.6. Aufteilung im Produkttest .............................................................................88

5.3.7. Aufteilung im Regressionstest .....................................................................89

5.3.8. Anzahl der Mitarbeiter pro Aktivität ..............................................................90

5.4. Zeitlicher Verlauf .....................................................................................................92

5.4.1. Gesamtaufwand ..........................................................................................92

5.4.2. Arbeitszeit der Mitarbeiter über die Zeit .......................................................93

5.4.3. Anzahl der Mitarbeiter über die Zeit .............................................................94

5.4.4. Aufwand der Kategorien ..............................................................................95

5.4.5. Verlauf von Einzelaktivitäten ........................................................................98

____________________________________________________________________________________________________


5

5.4.6. Anzahl der Mitarbeiter pro Aktivität über die Zeit ........................................ 104

5.5. Interpretation ........................................................................................................ 107

5.5.1. Generelle Aussagen .................................................................................. 107

5.5.2. Auffälligkeiten ............................................................................................ 107

6. Projekt B ................................................................................................................ 108

6.1. Eckdaten .............................................................................................................. 108

6.2. Systematik ............................................................................................................ 108

6.2.1. Datenerfassung ......................................................................................... 108

6.2.2. Datenbasis ................................................................................................ 108

6.2.3. Zusammenfassung Systemtest und Abnahmetest ..................................... 109

6.3. Übersichtsdaten .................................................................................................... 109

6.3.1. Umfang der Datenbasis ............................................................................. 109

6.3.2. Verteilung der Gesamtstunden .................................................................. 109

6.3.3. Verteilung auf Kategorien .......................................................................... 111

6.3.4. Verteilung Overhead .................................................................................. 112

6.4. Zeitlicher Verlauf ................................................................................................... 112

6.4.1. Einleitung ................................................................................................... 112

6.4.2. Gesamtaufwand ........................................................................................ 113

6.4.3. Kategorien ................................................................................................. 113

6.4.3.1. Systemtest ................................................................................................. 116

6.4.3.2. Overhead ................................................................................................... 117

6.4.4. Anteil Besprechungen und Spezifikation .................................................... 118

6.4.4.1. Aufteilung Systemtest ................................................................................ 119

____________________________________________________________________________________________________


6

6.4.4.2. Anteile aller Aktivitäten .............................................................................. 120

6.4.4.3. Anteil Besprechungen ................................................................................ 121

6.5. Statistische Auswertungen .................................................................................... 122

6.6. Zusammenhang mit Zusatzdaten .......................................................................... 124

6.6.1. Bug-Report ................................................................................................ 124

6.6.2. Zeiterfassung der Entwickler ...................................................................... 126

6.6.3. Zeiterfassung weitere Mitarbeiter ............................................................... 127

6.6.4. Interpretation der Zusatzdaten ................................................................... 128

6.6.4.1. Bugeinträge von Mitarbeiter 1 .................................................................... 128

6.6.4.2. Bugeinträge von Mitarbeiter 2 .................................................................... 130

6.6.4.3. Zusammenhang Projektstunden zu Bugeinträge ....................................... 130

6.7. Interpretation ........................................................................................................ 132

6.7.1. Auffälligkeiten ............................................................................................ 132

6.7.2. Ausblick ..................................................................................................... 133

7. Projekt C ................................................................................................................ 133

7.1. Eckdaten .............................................................................................................. 133

7.2. Systematik ............................................................................................................ 134

7.2.1. Datenerfassung ......................................................................................... 134

7.2.2. Datenbasis ................................................................................................ 134

7.3. Übersichtsdaten .................................................................................................... 134

7.3.1. Gesamtstunden ......................................................................................... 134

7.3.2. Gegenüberstellung von Release 1.2.0 und Release 1.3.0 ......................... 134

7.3.3. Verteilung der Stunden auf die Testphasen ............................................... 136

____________________________________________________________________________________________________


7

7.3.3.1. Beschreibung............................................................................................. 136

7.3.3.2. Ergebnis .................................................................................................... 136

7.3.4. Verteilung der Stunden auf Testaktivitäten ................................................ 137

7.3.4.1. Beschreibung............................................................................................. 137

7.3.5. Ergebnis .................................................................................................... 138

7.3.6. Verteilung der Stunden auf Systemkomponenten ...................................... 139

7.3.6.1. Beschreibung............................................................................................. 139

7.3.6.2. Ergebnis .................................................................................................... 139

7.4. Zeitlicher Verlauf ................................................................................................... 140

7.4.1. Gesamtaufwand ........................................................................................ 140

7.4.2. Gesamtaufwand von Rel12 und Rel13....................................................... 141

7.4.3. Testphasen ................................................................................................ 142

7.4.3.1. Gesamtaufwand Stunden .......................................................................... 142

7.4.3.2. Release 1.2.0 ............................................................................................ 143

7.4.3.3. Release 1.3.0 ............................................................................................ 143

7.4.4. Aktivitäten .................................................................................................. 144

7.4.4.1. Gesamtaufwand hours ............................................................................... 144

7.4.4.2. Release 1.2.0 ............................................................................................ 145

7.4.4.3. Release 1.3.0 ............................................................................................ 145

7.5. Statistische Auswertung........................................................................................ 146

7.5.1. Gesamteinträge ......................................................................................... 146

7.5.2. Sortierung nach Aktivität ............................................................................ 146

7.5.3. Sortierung nach Projektphase .................................................................... 147

8. Projekt D ................................................................................................................ 148

____________________________________________________________________________________________________


8

8.1. Eckdaten .............................................................................................................. 148

8.2. Datenbasis ........................................................................................................... 149

8.3. Methodik ............................................................................................................... 150

8.4. Ergebnisse ........................................................................................................... 150

8.4.1. Übersichtsdaten ......................................................................................... 150

8.4.2. Auswertung Kategorien ............................................................................. 151

8.4.3. Statistische Daten ...................................................................................... 152

8.4.4. Ist / Planvergleich ...................................................................................... 152

9. Zusammenfassung ............................................................................................... 154

10. Anhang .................................................................................................................. 155

10.1. Abbildungsverzeichnis .......................................................................................... 155

10.2. Tabellenverzeichnis .............................................................................................. 159

10.3. Literaturverzeichnis ............................................................................................... 161

____________________________________________________________________________________________________


9

1. Einleitung

Die Entwicklung innovativer Softwaresysteme ist eine anspruchsvolle Aufgabe: Es sollen in

kurzer Zeit Produkte mit hoher Qualität entwickelt und freigegeben werden, ohne dabei

Budgetgrenzen zu überschreiten. Ein erheblicher Teil der Projektbudgets wird dabei für

Tests eingesetzt, und dennoch bleiben immer wieder wichtige Fehler unentdeckt. Dies gilt im

Speziellen für bedienergeführte IT-Systeme, weil das Verhalten des Bedieners „Mensch“

besonders schwer vorhersagbar und modellierbar ist – im Gegensatz zu technischen

Systemen, für die es zumindest eine Spezifikation gibt.

Die Testteams stehen daher unter Druck, die Effizienz ihrer Aktivitäten zu optimieren.

Wichtige „Stellschrauben“ sind z.B. die Testorganisation, die Testprozesse, der

Werkzeugeinsatz sowie Art und Umfang die Testautomatisierung. Häufig werden aber die

entstehenden Aufwände und somit der Break-Even dieser Maßnahmen falsch eingeschätzt.

Das Ziel dieses Projektes ist daher, einen Beitrag zu leisten, die Wirtschaftlichkeit im

Softwaretest zu verbessern. Dies erfolgt auf zwei Arten:

1. Durch die Begleitung und Analyse konkreter Projekte von Projektpartnern in der

Region werden die Unternehmen dabei unterstützt, die Wirtschaftlichkeit ihrer

Testprojekte zu verbessern. Der Schwerpunkt liegt dabei auf Unternehmen im

Großraum Friedrichshafen.

2. Durch die Organisation von Workshops und Fachtagungen wird den Unternehmen in

der Region die Möglichkeit gegeben, an einem Erfahrungsaustausch zwischen

Unternehmen, Forschungseinrichtungen und Hochschulen teilzunehmen und daraus

Erkenntnisse für die Optimierung ihrer eigenen Projekte zu gewinnen.

Zunächst wurde eine Bedarfsanalyse bei 13 Unternehmen durchgeführt, die Software- oder

softwarelastige Produkte herstellen und testen. Dabei zeigt sich, dass z.T. erhebliche

Unsicherheit darüber besteht, welcher Testaufwand insgesamt vorgesehen und wie der

Gesamtaufwand auf die einzelnen Aktivitäten im Test aufgeteilt werden sollte. Zur

Kalkulation werden i.d.R. firmeninterne oder persönliche Erfahrungswerte herangezogen. Es

____________________________________________________________________________________________________


10

besteht großes Interesse daran, wie es eigentlich „die anderen machen“ und welche „best

practice“ Projekte als Benchmark dienen können.

Es wird ein empirischer Projektansatz gewählt, d.h. Daten aus realen Projekten sollen

erfasst, analysiert und daraus Abhängigkeiten abgeleitet werden.

Der aktuelle Stand der Technik bezüglich der Themen Softwaretest, Wirtschaftlichkeit des

Softwaretests und der Testautomatisierung wurde ausgewertet und wird in diesem Bericht

dargestellt.

2. Bedarfsanalyse

Um die Projektinhalte möglichst gut am konkreten Bedarf der Unternehmen in der Region

auszurichten, wurde zunächst eine Bedarfsanalyse durchgeführt.

Dabei wurden in Form von Interviews der Status quo (Testprozesse, Testwerkzeuge, ggf.

Automatisierungsgrad) erfasst und die konkreten Handlungsfelder bezüglich der

Wirtschaftlichkeit des Software-Tests abgefragt.

2.1. Interviews

Im Rahmen des Projektes fanden Vor-Ort-Gespräche bei folgenden Firmen statt:

Unternehmen

Standort

EADS Immenstaad

ZF Friedrichshafen

Bosch Sicherheitstechnik Grasbrunn

IFM Kressbronn

Wenglor Tettnang

Steca Memmingen

Continental Lindau

____________________________________________________________________________________________________


11

Gunda Elektronik Friedrichshafen

Daimler Stuttgart

Astrium Immenstaad

Siemens Konstanz

Sybit Radolfzell

PSI Berlin

Im Folgenden sind die wesentlichen Fragestellungen zusammengefasst, die im Rahmen der Interviews durch die Partnerunternehmen benannt wurden:

• Test einer Mischung von zugekauften und selbst entwickelten Teilsystemen • Massive Aufspaltung des Produktes in parallele Produktlinien (Branches),

Auswirkungen auf den Test • Wie kann die Wirtschaftlichkeit verbessert werden, indem Rüstzeiten zwischen den

Tests reduziert und die Testvorbereitung automatisiert wird? • In welchem Teil der Testkosten steckt das höchste Einsparpotenzial? • Welcher Aufwand ist zu kalkulieren, um das Qualitätsziel durch manuellen Test zu

erreichen? Welcher Aufwand für automatisierten Test? • Was ist „Best-Practice“ im Softwaretest? • Was sind typische Break-Even-Punkte und wie werden sie erreicht? • Bedarf an detaillierter Erfassung der Testaufwände • Welche Aufwände fließen in den eigenen Projekten in die einzelnen Testphasen? • Was ist die Erfahrung anderer Unternehmen im Softwaretest? • Entscheidungshilfe, wie neuen Features getestet werden sollten (manuell/

automatisiert) • Break-Even, wann lohnt sich Automatisierung? Nach wieviel Releases? • Vermessung der realen Aufwände im Test als Argumentationsgrundlage für die

Projektkalkulation • Managen der Komplexität bei mehreren Branches • Wie erstellt man eine belastbare Kalkulation der Budgets bezogen auf ein

Testautomatisierungsprojekt? • Welche Faktoren spielen dabei eine Rolle?

____________________________________________________________________________________________________


12

• 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?

• 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?

• Wie verteilt sich der Ist-Aufwand zwischen Testplanung, Testvorbereitung,

Testdurchführung, Testauswertung, Projektkommunikation und Pflege der Test-

infrastruktur?

• Welchen Anteil haben die Teammitglieder an den einzelnen Testaktivitäten? Warum?

Gewollt oder eher zufällig? Was kann verbessert werden?

• Wie verteilt sich der Testaufwand über die Systemkomponenten? Welcher

Zusammenhang besteht zwischen Testaufwand, Größe/Komplexität der System-

komponenten und Fehlerrate (vor/im/nach dem Systemtest)?

• Bei welchen Testaktivitäten werden die Plan-Stunden besonders deutlich

überschritten? Warum?

2.2. Workshops und Fachtagungen

Die Bedarfsanalyse wurde erweitert durch die Organisation und Durchführung von mehreren

Workshops und einer Fachtagung, die in Friedrichshafen in den Räumen der Dualen

Hochschule durchgeführt wurden.

Die Themen der Veranstaltungen waren:

• Modellbasiertes Testen und Testautomatisierung

• Erfahrungen und Strategien im Systemtest

____________________________________________________________________________________________________


13

Die Themen und Referenten der Vorträge:

• Test@Cloud – Verbindung von .mzT und virtuellem Testen (Martin Beißer, sepp.med GmbH)

• Praxis des modellbasierten Testens (Dr. Hans-Jürgen Herpel, Airbus Defence&Space)

• Model Based System Integration (Dr. Karl Ambrus, Airbus Defence&Space) • Risk Oriented Test Optimization using the Model Based Testing Approach

(Felix Jakob, Dornier Consulting, Dr. Wolfgang Kremer, Creative Data AG) • Systemtest durch Systemsimulation - Wie können Systemkomponenten eines

komplexen Systems ohne Zugriff auf das Gesamtsystem getestet werden? (Postsortierzentrum) (Ralf Müller (Siemens AG, Logistics and Airport Solutions)

• Testen im agilen Umfeld - Welche Auswirkungen hat Scrum auf den Testprozess? Wie bekommt man den Aufwand für die häufigen Systemtests in den Griff? (Dr. Karl-Friedrich Koschnick, Sybit)

• Optimierungsstrategien beim Systemtest - Wie können Systemtests mit weniger Aufwand bessere Ergebnisse bringen? Wie verbindet man Sicherheit mit agiler Entwicklung? (Paul Huber, Ingenieurbüro Paul Huber)

• Satellite Functional Testing – Simulation Based and Modularized Simulation infrastruktur und Testansatz. (Prof. Dr.-Ing. Jens Eickhoff, Airbus Defence and Space)

Diese Veranstaltungen trugen sowohl zur Bedarfsanalyse bei, als auch unterstützten sie die

Vernetzung der Unternehmen in der Region bezüglich des Softwaretests.

____________________________________________________________________________________________________


14

3. Stand der Technik

In diesem Kapitel wird der aktuelle Stand der Technik bezüglich der Themen Softwaretest,

Aufwandsschätzung und Wirtschaftlichkeit des Softwaretests sowie der Testautomatisierung

dargestellt. Dabei werden sowohl wesentliche Grundlagen beleuchtet, wie sie in den

einschlägigen Fach- und Lehrbüchern zu finden sind, als auch spezielle Aspekte, die in

Konferenzbeiträgen oder Dissertationen behandelt wurden.

3.1. Software-Test

In diesem Abschnitt werden die Grundlagen bzgl. Software-Test und –automatisierung

dargestellt.

3.1.1. Sneed/Baumgartner „Der Systemtest“

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

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

____________________________________________________________________________________________________


15

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%

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

____________________________________________________________________________________________________


16

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)

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

____________________________________________________________________________________________________


17

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

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

____________________________________________________________________________________________________


18

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

____________________________________________________________________________________________________


19

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

____________________________________________________________________________________________________


20

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

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:

𝐾𝐵𝑇𝑃 = 𝑆𝑇𝑇𝑆𝑇𝑅𝑆𝑃𝑇𝑇𝑇𝑆𝑃𝑇𝑇𝑆𝑇𝑃𝐺𝑇𝑇𝑇𝐺𝑇𝑇𝑆𝑃𝑇𝑇𝑆𝑇𝑃

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

____________________________________________________________________________________________________


21

𝐾𝑆𝑆 = 𝐷𝑇𝑇𝑇𝑃𝑇𝐷𝑅𝑇𝑃𝐷𝑇𝑇𝑇𝑃𝑇𝑃𝑇𝐺𝑇𝑃𝑇𝑇

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

𝐾𝐷𝐵 = 𝑆𝑆ℎ𝑃ü𝑇𝑇𝑇𝑃𝑇𝑇𝑇𝑅𝑆𝑆𝑆𝑇𝑇+𝐼𝑃𝐼𝑆𝐼𝑇𝑇𝐴𝑇𝑇𝑅𝑆𝑆𝑆𝑇𝑇

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

𝐾𝐴𝑃𝐴 = 𝐵𝑇𝐼𝑆𝑃𝑇𝑆𝑃𝑇𝑇𝑃𝐴𝐴𝑇𝑆𝑅𝑃𝑇𝑃

(2.6)

• Systemkomplexität Die Komplexität des gesamten Systems berechnet sich aus dem arithmetischen

Mittel der Einzelkomplexitäten.

𝐾𝑆𝐷𝑇 = 𝐾𝐵𝐵𝐵+𝐾𝑆𝑆+𝐾𝐷𝐵+𝐾𝐴𝐵𝐴4

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

____________________________________________________________________________________________________


22

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

𝑇𝑇𝑇𝑇𝑇𝐸𝑇𝑇𝑇𝑇𝑇𝑇𝐸𝐸𝑇𝑇𝑇𝑇 = 𝑇𝑇𝐺𝑇𝑇𝑇𝑇𝑃𝑇 𝐾𝑅𝐺𝑅𝑃𝑇𝐾𝑆𝑇ä𝑇𝐺𝑆𝑇𝑇𝑃𝑇𝑅𝑇 𝐾𝑅𝐺𝑅𝑃𝑇𝐾𝑆𝑇ä𝑇

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

Nach der Bestimmung aller relevanten Faktoren ergibt sich die sogenannte COCOMO-II

Gleichung zur Bestimmung des Testaufwandes (in Personentagen) wie folgt:

𝑇𝑇𝑇𝑇𝐸𝑇𝐸𝑇𝐸𝑇𝑇 = 𝑆𝑆𝑇𝑇𝑇𝑆𝑇𝑆𝑇 ∗ � 𝑇𝑇𝑇𝑇𝑃𝑅𝑆𝑃𝑇𝑇𝑇𝑇𝑇𝑇𝑅𝑅𝑅𝐼𝑆𝐴𝑇𝑆𝑆𝑆𝑇ä𝑇

�𝑆𝐴𝑇𝑃𝑆𝑇𝑅𝑆𝑃𝑇𝑇𝑇𝐾𝑅𝑅𝑃𝑇𝑃𝑇

∗ 𝑇𝑇𝑇𝑇𝑇𝐸𝑇𝑇𝑇𝑇𝑇𝑇𝐸𝐸𝑇𝑇𝑇𝑇 (2.9)

____________________________________________________________________________________________________


23

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

3.1.1.6. Testautomatisierung – Ausbaustufen und Alternativen

Die Automatisierung im Testumfeld kann verschieden intensive Formen annehmen. Von der

vergleichsweise einfachen, automatischen Testauswertung bis hin zur komplexen,

automatischen Testfallermittlung sind fünf Stufen der Testautomatisierung denkbar. Unten

stehende Abbildung zeigt den Aufbau zunehmender Testautomatisierung.

____________________________________________________________________________________________________


24

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

____________________________________________________________________________________________________


25

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

konstanten Kontrollleistung eines Automaten senkt die Testeffektivität in diesem Falle

erheblich. ([SNE], S.239)

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

____________________________________________________________________________________________________


26

3.1.2. Seidl/Baumgartner „Basiswissen Testautomatisierung“

3.1.2.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 [SEI]. 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: [SEI], 2012)

____________________________________________________________________________________________________


27

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

Entwicklungsumgebungen mit inkrementellem Fortschritt liegt eher die kontinuierliche

Durchführung automatisierter Tests im Fokus. ([SEI], 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. ([SEI], 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. ([SEI], S. 46)

____________________________________________________________________________________________________


28

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

Abbildung 5: Darstellung der Qualitätskriterien nach ISO 9126 ([SEI], 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“ ([SEI], 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. ([SEI], S. 104 ff)

____________________________________________________________________________________________________


29

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

([SEI], S. 109ff). Die Konformität beschreibt den „Grad der Erfüllung von Anforderungen an

die Zuverlässigkeit“ ([SEI], 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. ([SEI], S. 112)

Die Effizienz ist gemäß Norm „definiert als das Verhältnis zwischen eingesetzten

Betriebsmitteln und Leistungsniveau der Software“ ([SEI], S. 114). In der Norm wird die

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.

([SEI], 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

____________________________________________________________________________________________________


30

Abdeckung durch automatisierte Tests recht gut bewertet und verbessert werden ([SEI], 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 ([SEI], 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. ([SEI], S. 118f)

3.1.2.4. Integration von Testautomatisierung in die Organisation

In diesem Abschnitt sollen neben einigen Anregungen und Ideen für den Einstieg in die

Testautomatisierung auch Herausforderungen, Probleme und Lösungsansätze vorgestellt

werden, die im Zusammenhang mit der Einführung automatisierter Tests einhergehen. Ein

Blick auf die Voraussetzungen rundet die Integration von Testautomatisierung ab.

____________________________________________________________________________________________________


31

Abbildung 6: Anregungen und Ideen zum Einstieg in die Testautomatisierung ([SEI], 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 ([SEI], S. 152).

____________________________________________________________________________________________________


32

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

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. [SEI],

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 ([SEI], S. 153 f).

____________________________________________________________________________________________________


33

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 ([SEI], 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

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

([SEI], 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 ([SEI], 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

____________________________________________________________________________________________________


34

Projektes Dokumente wie etwa Verfahrensanweisungen erstellt werden, um z.B.

Zertifizierungen zu bestehen und reproduzierbare Ergebnisse sicherzustellen ([SEI], 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

([SEI], S. 158 f).

3.1.3. Dustin/Rashka/Paul „Software automatisch testen“

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

____________________________________________________________________________________________________


35

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.

([DUS], 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

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.

([DUS], S.20)

TMM Level 3 – Integrationsphase

____________________________________________________________________________________________________


36

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. ([DUS], 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

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

____________________________________________________________________________________________________


37

und kostengünstig beheben. Die bisherige Werkzeuglandschaft mit den reinen

Testwerkzeugen wird bspw. um Tools zur Fehlerverfolgung ergänzt. ([DUS], S. 22)

TMM Level 5 – Phase der Optimierung, Fehlervermeidung 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. ([DUS], S. 23)

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

____________________________________________________________________________________________________


38

Testern, empfiehlt sich zusätzlich zu einem weiteren Testleiter eine übergeordnete

Hierarchiestufe (Testmanager) zur Gesamtkoordination der Tests. Nach dem Ende des

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 ([DUS], 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 ([DUS], S. 172, 174

f, 179).

____________________________________________________________________________________________________


39

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 ([DUS], 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

____________________________________________________________________________________________________


40

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

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“. ([DUS], S. 172, 177f, 180)

Abbildung 7: Beispielhafte Organisation verschiedener Testteamtypen ([DUS], 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.

____________________________________________________________________________________________________


41

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

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

• Metriken1. 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.

([DUS], S. 180f)

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.

____________________________________________________________________________________________________


42

3.1.3.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 ([DUS], 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.

• 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

____________________________________________________________________________________________________


43

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.

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

____________________________________________________________________________________________________


44

So können Deklarationsfehler vermieden und der Änderungsaufwand übergeordneter

Elemente reduziert werden.

3.1.3.4. Aufgaben im Softwaretest

Im Folgenden wird eine Liste von Aktivitäten vorgestellt, die rund um ein Softwaretestprojekt

entstehen können ([DUS], 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.

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?

____________________________________________________________________________________________________


45

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.

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.

____________________________________________________________________________________________________


46

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.

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.

____________________________________________________________________________________________________


47

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.

w. Systemadministration des Testwerkzeuges. Anforderungen für Einrichten

und Unterhalt der Werkzeuglandschaft inkl. Benennung des zugehörigen

Personals.

7. Testdesign

____________________________________________________________________________________________________


48

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

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

h. Unittest. Entwickeln von Testverfahren/-skripts.

i. Integrationstest. Entwickeln von Testverfahren/-skripts.

____________________________________________________________________________________________________


49

j. Systemtest. Entwickeln von Testverfahren/-skripts.

k. Entwickeln eines Ausführungsplans für die Testverfahren. l. Analyse der Wiederverwendbarkeit der automatisierten Tests. m. Analyse zur Bestimmung der zu automatisierenden Tests. n. Entwickeln einer Matrix mit den Modularitätsbeziehungen. 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.

____________________________________________________________________________________________________


50

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

____________________________________________________________________________________________________


51

Informationsaustausch und Networking über die Grenzen der eigenen

Branche hinaus.

i.

3.1.4. 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 [DOW]. In ihrer Dissertation formuliert 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.

𝑇𝑇 = 𝐸(𝑇𝑇ℎ. 𝑇.𝑍𝑇𝐸𝑇𝑇𝐸𝑇𝑇𝑇𝑇𝑍𝑇𝑇,𝑇𝑇𝐴. 𝑆𝑇𝑇𝐸𝑆ℎ𝑇𝑇,𝐸𝑇𝐸.𝑇.𝐸𝑇𝑇𝑇. , 𝑆)

𝑇𝑇 = 𝐸(𝑇𝑇ℎ. 𝑇.𝑍𝑇𝐸𝑇𝑇𝐸𝑇𝑇𝑇𝑇𝑍𝑇𝑇,𝑇𝑇𝐴. 𝑆𝑇𝑇𝐸𝑆ℎ𝑇𝑇,𝐸𝑇𝐸.𝑇.𝐸𝑇𝑇𝑇. ,𝑇𝑇𝐴.𝑅𝑇𝐸𝑇𝐸𝑇𝑇𝑇, 𝑆

____________________________________________________________________________________________________


52

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.

𝑇𝑇 = 𝐸(𝑇𝑇𝐴. 𝑇𝑒𝑇. 𝑆𝑆,𝐸𝑇𝐸.𝑇.𝐸𝑇𝑇𝑇. , 𝑇𝑇𝑇𝐸.𝑍𝑇𝑇𝑇, 𝑆)

𝑇𝑇 = 𝐸(𝑇𝑇𝐴. 𝑇𝑒𝑇. 𝑆𝑆, 𝑇𝑇𝑇𝐸.𝑍𝑇𝑇𝑇, 𝑆)

Die Schlussfolgerung dieser Quelle ist im Wesentlichen diese: Um valide die

Wirtschaftlichkeit des automatisierten Testprozesses zu bewerten, müssen Aufwände exakt

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.

____________________________________________________________________________________________________


53

3.2. Wirtschaftlichkeit des Software-Tests

In diesem Abschnitt werden Aspekte des Software-Tests beleuchtet, die die

Wirtschaftlichkeit betreffen, sowie verschiedene Ansätze zur Aufwandsschätzung.

3.2.1.1. Testkostenbeeinflussende Faktoren

Nach Spillner und Linz 2010 mit dem Titel „Basiswissen Softwaretest“ [SPI], 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

Mitarbeiterqualifikation

____________________________________________________________________________________________________


54

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

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

____________________________________________________________________________________________________


55

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.

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)

3.2.1.3. Qualitative Faktoren mit Einfluss auf die Testautomatisierung

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

____________________________________________________________________________________________________


56

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.

• Fehlerfindung: Findet keine Beeinträchtigung der bestehenden Funktionalität durch

die Änderungen am Testobjekt statt? (Regressionstest)

([SPI], S. 186 f)

3.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 [SPI]:

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

____________________________________________________________________________________________________


57

3.2.2. Das Fehlermodell nach Kropfitsch & Vigenschow

Die Autoren [KRO] stellen einen empirischen Ansatz vor, um Vorhersagen über die erwartete

Fehleranzahl eines gegebenen Systems zu machen. Dies dient als Grundlage zur

Aufwandsschätzung für die Testfallerstellung, für die Testdurchführung und für die

Fehlerbehebung.

Die Autoren geben eine Übersicht über typische Erfahrungswerte aus der Literatur, z.B. bzgl.

der erwarteten Fehleranzahl je 1.000 Lines of Code, abhängig vom Typ der Anwendung.

Wesentliche Parameter des vorgestellten Fehlermodells sind:

• Programmgrösse

• Fehleranzahl je 1.000 Lines of Code

• Anteil in der Testphase zu findender Fehler

• Abgestrebte Testabdeckung

• Anzahl notwendiger Testfälle, um einen Fehler zu finden

• Aufwandszahlen zur Erstellung und Durchführung von Tests

• Aufwandszahlen für die Fehlerbehebung

Die Autoren befassen sich ferner mit dem Prozess, Erfahrungswerte für diese Parameter aus

realen Projekten zu gewinnen und an das konkrete Projektumfeld eines Unternehmens

anzupassen.

____________________________________________________________________________________________________


58

Abbildung 8: Beispiel einer Fehlerkurve auf Basis eines Fehlermodells, [KRO, S. 34]

3.2.3. Das Qualitätskostenmodell von Wiemann

Der Autor [WIE] stellt in seiner Dissertation ein Qualitätskostenmodell vor, das sich auf

testinduzierte Qualitätskosten eingebetteter Systeme in der Automobilindustrie fokussiert.

Der Stand der Literatur, u.a. hinsichtlich Qualitätskostenmodellen, der Quantifizierung von

Fehlerströmen, der Quantifizierung von Fehlerbeseitigungskosten wird ausführlich

dargestellt. Für das Modell wurden acht reale Projekte eines Automobilzulieferers analysiert.

3.3. Wirtschaftlichkeit der Softwaretest-Automatisierung

In diesem Abschnitt liegt der Schwerpunkt auf Ansätzen, die die Wirtschaftlichkeit von

Automatisierungsmaßnahmen im Softwaretest behandeln.

____________________________________________________________________________________________________


59

3.3.1. Einführung

Zunächst sollen die in einem Testprojekt entstehenden Aufwände aus manuellen und

automatisierten Tests verglichen werden. In nachfolgend dargestellter Abbildung 9 sind

zunächst vereinfacht die Aufwandsentwicklungen aus manuellen und automatisierten Tests

gegenübergestellt. Es werden in der Grafik drei Aufwandstreiber berücksichtigt. Zum einen

die Testplanung bzw. die Testspezifikation. Hier wird angenommen, dass dieser Aufwand

beim manuellen und automatisierten Test vergleichbar groß ist. Diese Annahme beruht

darauf, dass es zunächst unerheblich ist, wie letztlich getestet wird, da in beiden Fällen

identische Programme getestet werden. Die Testspezifikationen mit Details zu den

Anforderungen an die Tests des Produktes sind also zumindest auf der aktuellen

Betrachtungsebene vergleichbar.

Ein weiterer Aufwandstreiber ist die Testautomatisierung. Sie ist nur beim automatisierten

Test notwendig und bringt einen erheblichen Mehraufwand mit sich. Dieser Aufwand ist

ähnlich groß wie die vorangegangene Testplanung/-spezifikation, nicht selten sogar höher.

Warum sich letztlich die Automatisierung eines Tests als günstigere Methode abzeichnen

kann, zeigt ein Blick auf die Testdurchführung. Beim manuellen Test ist der Aufwand zur

Durchführung jedes Mal gleich groß. Ein Tester führt jeden Test gleich durch. Wurde der

Test aber erfolgreich automatisiert, so reduziert sich der Aufwand für die reine Durchführung

an sich ganz erheblich gegenüber einem manuellen Test.

____________________________________________________________________________________________________


60

Abbildung 9: Aufwände beim Softwaretest ohne Berücksichtigung der Wartung für automatisierte Testfälle (Quelle: IWT)

Nun soll dieses vereinfachte Modell hingegen um die Aufwände erweitert werden, die

entstehen, wenn die nachfolgenden Testdurchläufe nicht eins zu eins mit den bisherigen

Spezifikationen, Testfällen o.ä. durchgeführt werden können. Werden im Verlauf einer

Testreihe derartige Anpassungen notwendig, spricht man von Wartung.

Um die Abbildung 9 um den Aspekt der Wartungsaufwände zu ergänzen, soll an dieser

Stelle zuerst darauf eingegangen, was „Wartung“ im Zusammenhang mit Softwaretests

bedeutet. Grundsätzlich fasst man darunter das jeweilige Anpassen der Tests an das

weiterentwickelte Produkt zusammen. Dazu gehören beispielsweise die Anpassung der

Testfälle oder auch das Erweitern des Testfallkataloges zum Beispiel zur Überprüfung neuer

Features.

Dieser Wartungsaufwand kann vom Testteam durch sorgfältiges Entwerfen modularer

Verfahren jedoch reduziert werden. Einige Aspekte, welche die Wartungsfreundlichkeit

erhöhen, sind z.B.:

Aufwände ohne Wartung

Testdurchführung

Testautomatisierung

Testplanung/-spezifikation

____________________________________________________________________________________________________


61

• Befolgen von Formatierungsstandards

• Parametrisierung

• Dokumentieren von Testskripts

• Verwendung von Namenskonventionen

• Verwendung standardisierter Schleifenkonstrukte [DUS]

Die nachfolgende Abbildung zeigt das modifizierte Aufwandsmodell. Die jeweiligen

Aufwände beim ersten Test sind dabei unverändert. Jeder weitere Durchlauf bis zum n. Test

wird jetzt aber um einen neuerlichen Testplanungs- und Testspezifikationsaufwand ergänzt,

da Wartungsarbeiten diesem Arbeitsbereich zugeordnet werden können. Auch hier wird

analog zu oben angenommen, dass die jeweils neuen Planungsaufwände eine

Vergleichbarkeit hinsichtlich der späteren Testdurchführung (manuell oder automatisiert)

aufweisen.

Beim automatisierten Test impliziert nun die geänderte Planung und Spezifikation einen

neuerlichen Automatisierungsaufwand zur Umsetzung dieser Änderungen. Die dabei

entstehenden Aufwände sind z.T. nicht unerheblich und werden in Projekten ebenfalls gerne

unterschätzt.

Am Durchführungsaufwand ändert sich aber nichts, so dass beim Testdurchlauf der

automatisierte Test nach wie vor geringere Aufwände zur Folge hat. Die Differenz am

Gesamtaufwand ist aber nicht mehr so signifikant wie in Abbildung 9. Es entscheidet sich

also über die Gesamtanzahl der durchgeführten Tests, ob eine Automatisierung sich als

wirtschaftlich sinnvoll erweist.

____________________________________________________________________________________________________


62

Abbildung 10: Aufwände beim Softwaretest unter Berücksichtigung der Wartung für automatisierte Testfälle (Quelle: IWT)

Im vorangegangenen Abschnitt wurde festgehalten, dass in einem frühen Projektstadium

über eine Automatisierung entschieden werden muss. Ob diese wirtschaftlich sinnvoll ist,

zeigt sich aber durch Beobachtung nur ex post. Um vor Beginn der Testdurchläufe ex ante

eine Voraussage zur Wirtschaftlichkeit des Vorhabens zu treffen, wäre eine äußerst valide

Datengrundlage hilfreich.

Eine solche Grundlage für die Entscheidung zur Automatisierung kann aus Daten

abgeschlossener, vergleichbarer Projekte bestehen, aus unternehmensinternen

Sammelwerken oder Verfahrensanweisungen. Letztlich entscheidet aber immer die

Erfahrung des Projektleiters in großem Maße mit, in welchen Teststufen und in welchem

Ausmaß Testautomatisierung eingesetzt werden soll. Durch den Verlust von Know-How-

Trägern oder aufgrund von einzelnen, verhältnismäßig unerfahrenen Testmitarbeitern ist im

Worst-Case der Projekterfolg akut gefährdet.

Aufwände mit Wartung

Testdurchführung

Testautomatisierung

Testplanung/-spezifikation

____________________________________________________________________________________________________


63

3.3.2. Hoffman – „Cost Benefits Analysis of Test Automation“

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:

____________________________________________________________________________________________________


64

• Einsparungen beim Aufwand zur Testausführung

• Tests laufen bedienerunabhängig, auch nachts oder am Wochenende

• Ggf. Qualitätsoptimierung durch Reduzierung des Fehlerfaktors Mensch im

Testdurchlauf

Die Berechnung der Effizienz der Testautomatisierung erfolgt in zwei Gleichungen [HOF]:

𝐸𝑃 =𝑇𝑇𝑇𝐺

=(𝑉𝑇 + 𝑇 ∗ 𝐷𝑇)

(𝑉𝐺 + 𝑇 ∗ 𝐷𝐺)

𝐸𝑃′ =𝑇𝑇𝑇𝐺

=(𝑉𝑇 + 𝑇1 ∗ 𝐷𝑇)

(𝑉𝐺 + 𝑇2 ∗ 𝐷𝐺)

𝑉𝑇= Ausgaben für Testspezifikation und –implementierung

𝑉𝐺 = Ausgaben für Testspezifikation

𝐷𝑇= Ausgaben für Ergebnisinterpretation nach dem Test

𝐷𝐺= 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.

____________________________________________________________________________________________________


65

Die Berechnung des ROI der Testautomatisierung erfolgt ebenfalls in zwei Gleichungen

[HOF]:

𝑅𝑅𝑅𝑇𝑆𝑇(𝑇) =(𝑇𝑇𝑇𝑇𝑆𝐸𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑍𝑇𝑇𝑇𝑇𝐴𝑇𝑇) (𝑇𝑇𝑇𝑇𝑆𝐸𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑍𝑇𝑇𝑇𝑇𝑇𝑇𝑇)

=𝑁𝑇𝐾𝑇

𝑅𝑅𝑅𝑇𝑆𝑇(𝑇) =∆(𝑁𝑇𝑇𝐴𝑇𝑇 𝑇𝑇𝑇 > 𝑀𝐸𝑇) ∆(𝐾𝑇𝑇𝑇𝑇𝑇 𝑇𝑇𝑇 > 𝑀𝐸𝑇)

=∆𝑁𝑇∆𝐾𝑇

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.

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]:

∆𝑁𝑇(𝑇) = ��∆𝐾𝑓𝑆𝐾,𝑅𝑅𝑇, 𝑇 �𝑇𝑇�� +�(𝐾𝑆𝑇𝑅,𝐺 ∗ 𝑇2 (𝑇)) −�(𝐾𝑆𝑇𝑅,𝑇 ∗ 𝑇1 (𝑇))

𝑇= geplante Amortisationszeit, z.B. ein Vielfaches der Zeit zwischen Produktreleases

(praxisnahe Zahl!)

𝑇= geplante Nutzungsdauer

____________________________________________________________________________________________________


66

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]:

∆𝐾𝑇(𝑇) = ��∆𝐾𝑓𝑆𝐾,ℎöℎ𝑇𝑅, 𝑇 �𝑇𝑇�� + �𝐾𝑆𝑇𝑅,𝑃𝑇𝑆,𝑇 −�𝐾𝑆𝑇𝑅,𝑃𝑇𝑆,𝐺 + ��𝐾𝑆𝑇𝑅,𝐴𝑇𝑅𝑇,𝑇 �

𝑇1𝑁��

𝑇1= Anzahl der automatisierten Testdurchläufe

𝑁 = Anzahl der möglichen Testdurchläufe bevor Wartung notwendig ist

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

____________________________________________________________________________________________________


67

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.3.3. Schmid et. al – „Wann lohnt sich die Automatisierung 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 11) 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.

____________________________________________________________________________________________________


68

Abbildung 11: 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 12

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

____________________________________________________________________________________________________


69

relevanten Faktoren sind auch hier u.a. die Wiederholbarkeit der Aktivität ohne Anpassung,

sowie die Einsparung pro Ausführung.

Abbildung 12: Phasen mit geringem Einfluss auf ROI ([SCH], S. 9)

Weitere Testprozessphasen mit starken Auswirkungen auf die Testautomatisierung zeigt die

nachfolgend dargestellte Abbildung 13. 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.

____________________________________________________________________________________________________


70

Abbildung 13: Phasen mit starkem Einfluss auf ROI ([SCH], S. 10)

3.3.4. Einflussfaktoren

Wenn nun die Testautomatisierung als Mittel zur Qualitäts- oder Kostenoptimierung in

Erwägung gezogen wird, so gilt es auch hier einige Faktoren zu beachten. Zu bemerken ist,

dass die ausgewertete Literatur vorrangig qualitative Faktoren benennt. Konkrete

Zahlenwerte zur Beurteilung der Entscheidung der Frage nach der Testautomatisierung

stehen aus.

Qualitative Faktoren

• 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?

____________________________________________________________________________________________________


71

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

• Fehlerfindung: Findet keine Beeinträchtigung der bestehenden Funktionalität durch

die Änderungen am Testobjekt statt? (Regressionstest)

[SPI]

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.

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

____________________________________________________________________________________________________


72

bringt. Die nachfolgen Auflistung gibt einen Überblick über Einflussfaktoren auf das

Fehlerkostenrisiko [SPI]:

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

Als Richtwert kann festgehalten werden, dass sich die Fehlerkorrekturkosten, die ein Defekt

verursacht, mit jeder Prozessphase gegenüber der vorangegangenen verdoppeln! Es ist also

kostenoptimal, wenn zum frühestmöglichen Zeitpunkt im Projekt bereits über die

Testplanung und das Testdesign nachgedacht, also ein insgesamt vorbeugender Ansatz

gewählt wird.

3.4. Zusammenfassung

Die qualitativen Faktoren, die im Zusammenhang mit Testplanung, Testdurchführung und

Testautomatisierung stehen, sind in der Literatur gut erforscht und dokumentiert. Es

existieren verschiedene Methoden und Modelle um Testvorhaben zu projektieren und den

Einsatz von Softwaretestautomatisierung abzuschätzen. Zu diesen Modellen gehören unter

anderem die hier skizzierten Wege zur Testaufwandsschätzung, oder Modelle zur

Abschätzung des finanziellen Nutzens.

Diese Modelle sind jedoch nur teilweise validiert und in der Praxis angewendet worden. An

detaillierten und validen, quantitativen Projektierungsrichtlinien fehlt es weiterhin.

____________________________________________________________________________________________________


73

Der empirische Ansatz, also die Annäherung an quantitative Aussagen über die Messung

realer Aufwände in verschiedenen Projekten stellt dabei eine erprobte und anerkannte

Herangehensweise dar.

____________________________________________________________________________________________________


74

4. Methode

4.1. Ansatz

Wir bereits beschrieben, wurde ein empirischer Ansatz gewählt. D.h. es wird der Aufwand in

realen Softwaretestprojekten vermessen und ausgewertet. Sofern ausreichend genaue

Daten vorliegen, können auch Daten aus bereits abgeschlossenen Projekten herangezogen

werden.

Dabei bestand die Randbedingung, dass den Partnerunternehmen bei der

Aufwandserfassung ein nur möglichst geringer Zusatzaufwand entstehen sollte, vor allem,

um die Akzeptanz bei den Mitarbeitern zu gewährleisten.

4.2. Datenerfassung

Wenn keine ausreichend detaillierten Daten vorliegen, erfolgte eine gemeinsame

Aufwandsvermessung eines Projektes. Dabei wurde ein durch das IWT vorgelegter

Aktivitätenkatalog („Welche Aktivitäten könnten in einem Softwaretestprojekt grundsätzlich

anfallen?“) an das konkrete Projekt des Partnerunternehmens angepasst. Auf dieser

Grundlage stellte das IWT Hilfsmittel zur Aufwandserfassung (Excel-Mappen) bereit, die das

Partnerunternehmen nun zur detaillierten Aufwandserfassung eines konkreten Projektes

oder einer Projektphase nutzte, begleitet durch das IWT. Die Auswertung der Messdaten

erfolgte durch das IWT, das Partnerunternehmen erhielt einen Ergebnisbericht.

____________________________________________________________________________________________________


75

4.3. Auswertungskonzept

4.3.1. Anforderungen

Folgende Fragestellungen sollten im Rahmen der Auswertung zunächst untersucht werden:

a) Wie ist die Verteilung (absolut, relativ) der Aktivitäten über den Zeitverlauf ?

b) Wie „kompakt“ (oder „wiederholt“/„verteilt“) werden Aktivitäten im Zeitverlauf ausgeführt ?

____________________________________________________________________________________________________


76

c) Wie ist die Verteilung der Aktivitäten über das Team ?

d) Wie hoch ist die Auslastung (als Funktion der Zeit) ?

e) Wieviele Aktivitäten werden je Mitarbeiter und Tag bebucht ?

f) Fragestellungen a) bis d), aber mit Bezug auf Systemkomponenten

4.3.2. Datengrundlage

In einem Vermessungsprojekt werden folgende Daten erhoben:

a) Ebene „Projekt“

- Projektname

- Liste der Aktivitäten (Schlüssel, Bezeichnung)

b) Ebene „Mitarbeiter“

- Name

- je Kalenderwoche: Aufwand (Std.) je Wochentag und Aktivität

- je Kalenderwoche: Aufwand (Std.) je Wochentag und Systemkomponente

Aus diesen Daten werden in den Excel-Erfassungstabellen bereits folgende Summen

gebildet:

a) Stunden je Mitarbeiter, Woche und Aktivität

b) Stunden je Mitarbeiter, Woche und Systemkomponente

c) Stundensumme je Mitarbeiter und Aktivität (auf Summenblatt I)

____________________________________________________________________________________________________


77

d) Stundensumme je Mitarbeiter und Systemkomponente (auf Summenblatt II)

____________________________________________________________________________________________________


78

4.3.3. Grundsätzliches Vorgehen

Die mitarbeiterbezogene Datenerfassung erlaubt, bereits in Excel Summen je Mitarbeiter zu

bilden. Für mitarbeiterübergreifende Auswertungen müssen daher Daten aus mehreren

Excel-Worksheets zusammengefasst werden. Dafür kommen u.a. folgende Verfahren in

Frage:

a) manuelles Zusammenfügen der MA-Tabellen zu einer Arbeitsmappe des gesamten

Projektes

b) Übertragung der Daten aus den MA-Tabellen in eine Projekt-Arbeitsmappe mit Hilfe eines

Excel-Makros

c) Übertragung der Daten aus den MA-Tabellen in eine Datenbank

Da eine Datenbank die umfassendsten Auswertungsmöglichkeiten erlaubt, wurde Variante c)

weiter verfolgt.

Hierbei wurde in zwei Stufen vorgegangen:

- Im ersten Schritt werden nur die Wochensummen in die Datenbank übernommen.

Dies hat den Vorteil, dass nur auf die Summenblätter zugegriffen werden muss, das

aufwendigere Auslesen der Wochenblätter entfällt.

- Im zweiten Schritt werden die Wochenblätter ausgelesen, so dass tagesgenaue

Informationen vorliegen.

4.3.4. Datenbankentwurf

____________________________________________________________________________________________________


79

Abbildung 14: Datenmodell zur Erfassung der Projektdaten

Mitarbeiter Aktivität

Aufwand

KW

1 1

n Stunden

n

____________________________________________________________________________________________________


80

Im ersten Schritt wird nur die Tabelle „Aufwand“ per Makro aus den Excel-Tabellen befüllt.

Die Tabellen „Mitarbeiter“, „Aktivität“ und „Komponente“ werden manuell befüllt.

Abbildung 15: Datenbankschema zur Aufwandserfassung

____________________________________________________________________________________________________


81

Abbildung 16: Excel-Tabelle zur Selbsterfassung der Arbeitszeit je Aktivität

____________________________________________________________________________________________________


82

5. Projekt A

5.1. Eckdaten

Branche: Elektronik / IT

Unternehmensgrösse: 1.000 – 10.000 MA

Produktgrösse: 100 – 1000 Personenjahre Entwicklungsaufwand

Beginn Entwicklung: ??

5.2. Systematik

5.2.1. Datenerfassung

Im Zeitraum 14.04.2014 bis 25.07.2014 wurden alle Aufwände im Rahmen des Testprojekts

durch Selbstaufschreibung in Excel Tabellen durch die Mitarbeiter im Test erfasst. Die Excel

Tabellen wurden in enger Absprache mit dem Partnerunternehmen durch das IWT erstellt

und durch einen Mitarbeiter des IWT an die ausfüllenden Mitarbeiter des

Partnerunternehmens übergeben.

5.2.2. Datenbasis

Alle Daten aus den im Rahmen der Aufwandserfassung erstellten Excel Tabellen wurden in

eine Access Datenbank in drei Tabellen abgelegt . Zur Auswertung wurden die Daten in eine

MySQL Datenbank exportiert, alle Abfragen wurden mit MySQL Workbench entwickelt und

ausgeführt. Darstellung und Pivotierung erfolgte dann in Excel.

____________________________________________________________________________________________________


83

5.2.3. Fehlfarbendarstellung

Manche Tabellen sind zur besseren Lesbarkeit farbig hinterlegt, dabei wird folgende

Farbgebung verwendet:

0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70% 75% 80% 85% 90% 95% 100%

5.2.4. Umfang der Datenbank

Aktivitäten: 27 Einträge

Aufwand: 2835 Einträge, davon 723 mit Stunden > 0

Mitarbeiter: 7 Einträge

Erfasste Gesamtstunden: 3314,0

5.3. Übersichtsdaten

5.3.1. Gesamtstunden pro Mitarbeiter

Mitarbeiter Gesamtstunden je

Mitarbeiter Anteil %

1 514,7 15,53

2 458,6 13,84

3 503,8 15,2

4 361,7 10,91

5 489 14,76

6 478,8 14,45

7 507,4 15,31

Abbildung 17: Verteilung der Gesamtstunden auf die Mitarbeiter

1 16%

2 14%

3 15% 4

11%

5 15%

6 14%

7 15%

____________________________________________________________________________________________________


84

5.3.2. Verteilung der Gesamtstunden

Abbildung 18: Verteilung des Gesamtaufwands auf die Aktivitäten

Testdurchführung 13%

Testen (Produkt) 19%

Testauswertung (Bugs) 10%

Testdurchführung (Regr.test)

17%

Testauswertung (Regr.test)

8%

Besprechungen 5%

TestplanungTestvorbereitung allg.Testvorber. HardwareTestvorber. SoftwareTestspezifikationTestdurchführungTesten (Produkt)Fehler in der TestumgebungTestauswertung (Bugs)TestabschlussTestplanung (Regr.test)Testvorbereitung (Regr.test)Testspezifikation (Regr.test)Testdurchführung (Regr.test)Testauswertung (Regr.test)Testabschluss (Regr.test)Einarbeitung

____________________________________________________________________________________________________


85

Bezeichnung der Aktivität Stunden Anteil %

Testen (Produkt) 617,0 18,62 %

Testdurchführung (Regr.test) 572,1 17,26 %

Testdurchführung 415,0 12,52 %

Testauswertung (Bugs) 320,1 9,66 %

Testauswertung (Regr.test) 276,8 8,35 %

Testvorber. Software 187,9 5,67 %

Testvorbereitung (Regr.test) 157,8 4,76 %

Besprechungen 149,9 4,52 %

Third Party Integration 111,8 3,37 %

Testmanagement 104,8 3,16 %

Testvorbereitung allg. 84,9 2,56 %

Administration, Maintenance, HW 72,9 2,20 %


Analyse 35,0 1,06 %

Fehler in der Testumgebung 33,0 1,00 %

Testvorber. Hardware 27,5 0,83 %

Hot Fix 15,0 0,45 %

Testabschluss (Regr.test) 13,0 0,39 %

Testabschluss 11,0 0,33 %

Testspezifikation (Regr.test) 10,8 0,32 %

Testspezifikation 10,3 0,31 %

Recherche (Werkzeuge,…) 8,8 0,26 %

Supportmanagement 8,0 0,24 %

Statusreport Test 7,8 0,23 %

Testplanung 6,0 0,18 %

Einarbeitung 4,5 0,14 %

Testplanung (Regr.test) 1,2 0,04 %

Tabelle 1: Aufwand je Aktivität

5.3.3. Verteilung auf Kategorien

Überbegriff Stunden Anteil %

Overhead 438,9 13,24 %

____________________________________________________________________________________________________


86

Querschnitt (Administration, Maintenance, HW) 72,9 2,20 %

Regressionstest 1031,6 31,13 %

Support 58 1,75 %

Systemtest 1712,6 51,68 %

Tabelle 2: Aufwand je Aktivitäts-Kategorie

Abbildung 19: Verteilung des Gesamtaufwands auf Aktivitäts-Kategorien

Overhead 13% 2%

Regressionstest 31%

Support 2%

Systemtest 52%

Overhead

Querschnitt (Administration,Maintenance, HW)Regressionstest

Support

____________________________________________________________________________________________________


87

5.3.4. Verteilung Overhead

Bezeichnung Stunden Anteil %


Besprechungen 149,9 34,2 %

Einarbeitung 4,5 1,0 %

Recherche (Werkzeuge,…) 8,8 2,0 %

Statusreport Test 7,8 1,8 %

Testmanagement 104,8 23,9 %

Third Party Integration 111,8 25,5 %

Tabelle 3: Aufwand der Overhead-Aktivitäten

Abbildung 20: Verteilung der Overhead-Aufwände

5.3.5. Anteil Mitarbeiter am Overhead

Mitarbeiter Stunden Anteil %

1 26,9 6,1 %

2 69,5 15,8 %

Besprechungen; 34,16 %

Testmanagement; 23,87 %

Third Party Integration;

25,46 %

Administration, Maintenance,HW

Besprechungen

Einarbeitung

Recherche (Werkzeuge,…)

Statusreport Test

Testmanagement

Third Party Integration

____________________________________________________________________________________________________


88

3 26,8 6,1 %

4 175,8 40,0 %

5 27,2 6,2 %

6 110,2 25,1 %

7 2,5 0,6 %

Tabelle 4: Overhead-Aufwand je Mitarbeiter

Abbildung 21: Aufwandsanteile der Mitarbeiter am Overhead

5.3.6. Aufteilung im Produkttest

Aktivität Bezeichnung Stunden Anteil %

3100 Testplanung 6,0 0,4 %

3200+3210+3220 Testvorbereitung 300,3 17,9 %

3300 Testspezifikation 10,3 0,6 %

1 6%

2 16%

3 6%

4 40%

5 6%

6 25%

7 1%

____________________________________________________________________________________________________


89

3400+3410 Testdurchführung 1032,0 61,4 %

3500 Testauswertung 320,1 19,1 %

3600 Testabschluss 11,0 0,7 %

Tabelle 5: Aufwand je Aktivität im Produkttest

5.3.7. Aufteilung im Regressionstest

Aktivität Bezeichnung Stunden Anteil %

5100 Testplanung (Regr.test) 1,2 0,1 %

5200 Testvorbereitung (Regr.test) 157,8 15,3 %

5300 Testspezifikation (Regr.test) 10,8 1,0 %

5400 Testdurchführung (Regr.test) 572,1 55,5 %

5500 Testauswertung (Regr.test) 276,8 26,8 %

5600 Testabschluss (Regr.test) 13,0 1,3 %

Tabelle 6: Aufwand je Aktivität im Regressionstest

Abbildung 22: Vergleich der Verteilung der Aktivitäten im Regressionstest (innerer Kreis) und Produkttest

(äußerer Kreis)

____________________________________________________________________________________________________


90

5.3.8. Anzahl der Mitarbeiter pro Aktivität

Aktivität Bezeichnung Anzahl MA

3100 Testplanung 5

3200 Testvorbereitung allg. 5

3210 Testvorber. Hardware 7

3220 Testvorber. Software 7

3300 Testspezifikation 4

3400 Testdurchführung 4

3410 Testen (Produkt) 7

3420 Fehler in der Testumgebung 4

3500 Testauswertung (Bugs) 7

3600 Testabschluss 2

5100 Testplanung (Regr.test) 2

5200 Testvorbereitung (Regr.test) 7

5300 Testspezifikation (Regr.test) 2

5400 Testdurchführung (Regr.test) 7

5500 Testauswertung (Regr.test) 7

5600 Testabschluss (Regr.test) 3

7100 Einarbeitung 3

7200 Besprechungen 7

7300 Recherche (Werkzeuge,…) 4

7400 Statusreport Test 2

7500 Administration, Maintenance, HW 5

7600 Third Party Integration 4

7700 Testmanagement 2

8100 Administration, Maintenance, HW 5

9100 Analyse 2

9200 Hot Fix 3

9300 Supportmanagement 3

Tabelle 7: Anzahl der Mitarbeiter je Aktivität , sortiert nach Aktivität

____________________________________________________________________________________________________


91

Aktivität Bezeichnung Anzahl MA 3210 Testvorber. Hardware

7

3220 Testvorber. Software 3410 Testen (Produkt) 3500 Testauswertung (Bugs) 5200 Testvorbereitung (Regr.test) 5400 Testdurchführung (Regr.test) 5500 Testauswertung (Regr.test) 7200 Besprechungen 3100 Testplanung

5 3200 Testvorbereitung allg. 7500 Administration, Maintenance,

8100 Administration, Maintenance, 3300 Testspezifikation

4 3400 Testdurchführung 3420 Fehler in der Testumgebung 7300 Recherche (Werkzeuge,…) 7600 Third Party Integration 5600 Testabschluss (Regr.test)

3 7100 Einarbeitung 9200 Hot Fix 9300 Supportmanagement 3600 Testabschluss

2

5100 Testplanung (Regr.test) 5300 Testspezifikation (Regr.test) 7400 Statusreport Test 7700 Testmanagement 9100 Analyse

Tabelle 8: Anzahl der Mitarbeiter je Aktivität , sortiert nach Anzahl der Mitarbeiter

____________________________________________________________________________________________________


92

5.4. Zeitlicher Verlauf

5.4.1. Gesamtaufwand

Woche Stunden Kumuliert

16 210,5 210,5

17 166,8 377,3

18 201,8 579,1

19 265,2 844,3

20 253,5 1097,8

21 243,1 1340,9

22 169,0 1509,9

23 228,8 1738,7

24 156,6 1895,2

25 128,5 2023,7

26 259,8 2283,5

27 258,6 2542,1

28 278,9 2821,0

29 268,0 3089,0

30 225,0 3314,0

Tabelle 9: Gesamtaufwand in Stunden pro Woche

____________________________________________________________________________________________________


93

Abbildung 23: Aufwand in Stunden pro Woche und kumuliert (y-Achse rechts)

5.4.2. Arbeitszeit der Mitarbeiter über die Zeit

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

1 33,2 33,1 31,1 40,7 37,5 40,8

23,5 33,0 34,0 43,5 42,3 43,5 38,3 40,5 515

2 23,8 32,8 22,8 33,5 35,5 38,8 24,0 40,0 24,5

40,5 24,3 40,5 39,5 38,3 459

3 24,0 14,3 31,3 38,0 40,0 40,5 30,0 39,0 31,0 29,0 35,0 37,8 40,0 38,0 36,0 504

4 30,6

21,0 32,6 24,0 4,0 22,5 34,3 27,1 4,5 32,3 28,3 34,9 32,5 33,3 362

5 34,5 23,8 33,8 41,5 40,5 42,0 33,5 38,5

32,5 44,0 41,0 43,5 40,0 489

6 32,0 32,0 35,8 39,0 36,0 31,5 31,0 37,0

23,5 35,0 37,0 35,0 37,0 37,0 479

7 32,5 31,0 26,2 40,0 40,0 45,5 28,0 16,5 41,0 37,5 41,0 45,0 44,0 39,3

507

211 167 202 265 254 243 169 229 157 129 260 259 279 268 225 3314

Tabelle 10: Arbeitszeit der Mitarbeiter je Projektwoche

0

500

1000

1500

2000

2500

3000

3500

0

50

100

150

200

250

300

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

____________________________________________________________________________________________________


94

Abbildung 24: Häufigkeitsverteilung der Wochenstunden

5.4.3. Anzahl der Mitarbeiter über die Zeit

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 14

2 1 1 1 1 1 1 1 1 1

1 1 1 1 1 14

3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 15

4 1

1 1 1 1 1 1 1 1 1 1 1 1 1 14

5 1 1 1 1 1 1 1 1

1 1 1 1 1 13

6 1 1 1 1 1 1 1 1

1 1 1 1 1 1 14

7 1 1 1 1 1 1 1 1 1 1 1 1 1 1

14

Gesamtergebnis 7 6 7 7 7 7 6 7 5 5 7 7 7 7 6 98

0

5

10

15

20

25

30

10 14 18 22 26 30 34 38 42 undgrößer

____________________________________________________________________________________________________


95

Tabelle 11: Anzahl der buchenden Mitarbeiter je Projektwoche

5.4.4. Aufwand der Kategorien

Tabelle 12: Aufwand der Aktivitäts-Kategorien je Projektwoche

0

50

100

150

200

250

300

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Overhead Querschnitt RegressionstestSupport Systemtest Gesamtergebnis

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Overhead 36,4 16,2 44 35,8 34,8 21 26,2 26 22,2 13,5 26,2 29,8 38 29,8 39

Querschnitt 7,2 5,5 2,8 1,8 0,5 8 0 5 2,8 1,5 10 1 8,8 5,5 12,5

Regressionstest 18,2 47,4 34,3 94,6 101,5 115,1 55,8 62,8 25 21,8 60 90,8 102,8 129,5 72

Support 1 0 0,8 0,5 0 0 7,5 6,5 3,5 1 16 4,2 5,5 5 6,5

Systemtest 147,6 97,7 119,8 132,7 116,8 99 79,5 128,5 103 90,8 147,5 132,8 123,8 98,2 95

Gesamtergebnis 210,4 166,8 201,7 265,4 253,6 243,1 169 228,8 156,5 128,6 259,7 258,6 278,9 268 225

____________________________________________________________________________________________________


96

Abbildung 25: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden)

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Overhead 8% 4% 10% 8% 8% 5% 6% 6% 5% 3% 6% 7% 9% 7% 9%

Querschnitt 10% 8% 4% 2% 1% 11% 0% 7% 4% 2% 14% 1% 12% 8% 17%

Regressionstest 2% 5% 3% 9% 10% 11% 5% 6% 2% 2% 6% 9% 10% 13% 7%

Support 2% 0% 1% 1% 0% 0% 13% 11% 6% 2% 28% 7% 9% 9% 11%

Systemtest 9% 6% 7% 8% 7% 6% 5% 8% 6% 5% 9% 8% 7% 6% 6%

Gesamtergebnis 6% 5% 6% 8% 8% 7% 5% 7% 5% 4% 8% 8% 8% 8% 7%

Tabelle 13: Aufwand der Aktivitäts-Kategorien je Projektwoche, je Kategorie normiert

Abbildung 26: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden), je Kategorie normiert

0%

5%

10%

15%

20%

25%

30%

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Overhead QuerschnittRegressionstest SupportSystemtest Gesamtergebnis

____________________________________________________________________________________________________


97

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Overhead 8% 12% 22% 30% 38% 43% 49% 55% 60% 63% 69% 76% 84% 91% 100%

Querschnitt 10% 17% 21% 24% 24% 35% 35% 42% 46% 48% 62% 63% 75% 83% 100%

Regressionstest 2% 6% 10% 19% 29% 40% 45% 51% 54% 56% 62% 71% 80% 93% 100%

Support 2% 2% 3% 4% 4% 4% 17% 28% 34% 36% 63% 71% 80% 89% 100%

Systemtest 9% 14% 21% 29% 36% 42% 46% 54% 60% 65% 74% 81% 89% 94% 100%

Gesamtergebnis 6% 11% 17% 25% 33% 40% 46% 52% 57% 61% 69% 77% 85% 93% 100%

Tabelle 14: Aufwand der Aktivitäts-Kategorien je Projektwoche, je Kategorie normiert, kumuliert

Abbildung 27: Zeitlicher Verlauf der Stunden je Aufwandskategorie, kumuliert

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Overhead Querschnitt Regressionstest

Support Systemtest Gesamtergebnis

____________________________________________________________________________________________________


98

5.4.5. Verlauf von Einzelaktivitäten

Absolute Werte 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

3100 Testplanung 1,8

0,3

1,0

3,0

3200 Testvorbereitung allg. 3,3 2,4 3,0 1,0 3,8 3,5 2,0 3,5 3,8 3,5 14,5 0,8 4,0 8,0 28,0

3210 Testvorber. Hardware 4,5 3,5

6,0 1,0

2,5

0,5

6,0 2,0 1,5

3220 Testvorber. Software 24,8 5,5 14,3 19,5 19,5 14,0 7,5 10,5 11,5 6,0 7,0 12,0 12,3 10,5 13,0

3300 Testspezifikation 3,3 1,0 1,0

3,0 1,0

1,0

3400 Testdurchführung 8,0 29,0 26,3 17,0 17,0 17,0 32,5 37,3 52,3 55,3 20,0 48,0 41,0 12,5 2,0

3410 Testen (Produkt) 70,3 40,7 51,8 59,2 42,0 34,0 27,0 51,8 13,8 17,0 80,5 32,5 25,5 42,5 28,5

3420

Fehler in der

Testumgebung 1,5 5,5 1,0 1,5 3,0 1,0 3,5 1,0 2,0

2,0 1,0 9,0 1,0

3500

Testauswertung

(Bugs) 30,3 10,1 22,3 28,5 27,5 27,5 7,0 21,5 17,3 9,0 23,0 38,5 26,0 17,8 14,0

3600 Testabschluss

3,0 8,0

5100

Testplanung

(Regr.test)

0,2

1,0

5200

Testvorbereitung

(Regr.test) 0,8 7,5 3,5 24,0 12,0 30,5 14,0 11,0 5,5 2,0 5,0 2,0 15,5 20,5 4,0

5300

Testspezifikation

(Regr.test)

2,0 2,3 2,0

1,0

1,0 2,5

5400

Testdurchführung

(Regr.test) 13,0 28,2 17,4 36,3 33,0 64,1 24,0 37,8 12,5 11,8 38,0 58,3 66,8 74,5 56,5

5500

Testauswertung

(Regr.test) 4,5 11,8 12,0 33,3 53,5 18,3 15,8 14,0 6,0 8,0 16,0 27,0 20,6 24,8 11,5

____________________________________________________________________________________________________


99

5600

Testabschluss

(Regr.test)

1,3 1,0 1,0

9,8

7100 Einarbeitung

3,0 0,5

0,5

0,5

7200 Besprechungen 18,2 3,8 18,8 9,0 12,3 12,5 10,0 7,5 5,8 2,5 12,8 6,3 10,5 6,3 14,0

7300

Recherche

(Werkzeuge,…)

1,0 1,5 2,0

2,3

1,0

1,0

7400 Statusreport Test 1,5

1,8 0,5

0,5 0,5 0,5

0,5 0,5 0,5 0,5 0,5

7500

Administration,

Maintenance, HW 2,5 6,8 2,0 8,8 5,5 2,5

4,0 7,0

1,5

2,5 8,5

7600 Third Party Integration 7,3

11,0 5,5 5,0 4,0 5,0 7,5 1,5 8,0 8,0 13,0 15,5 12,0 8,5

7700 Testmanagement 7,0 5,8 6,5 10,0 10,0 2,0 10,3 6,5 5,3 3,0 4,5 8,5 10,5 8,5 6,5

8100

Administration,

Maintenance, HW 7,3 5,5 2,8 1,8 0,5 8,0

5,0 2,8 1,5 10,0 1,0 8,8 5,5 12,5

9100 Analyse 1,0

0,8 0,5

3,0 5,0 3,0 1,0 16,0 1,3

1,0 2,5

9200 Hot Fix

4,5 1,5 0,5

3,0 5,5

9300 Supportmanagement

4,0 4,0

Gesamtergebnis

210,

5

166,

8

201,

8

265,

2

253,

5

243,

1

169,

0

228,

8

156,

6

128,

5

259,

8

258,

6

278,

9

268,

0

225,

0

Tabelle 15: Aufwand aller Aktivitäten je Projektwoche, in Stunden

Relative Werte 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

3100 Testplanung

29

%

4%

17

%

50

%

3200 Testvorbereitung allg. 4% 3% 4% 1% 4% 4% 2% 4% 4% 4% 17 1% 5% 9% 33

____________________________________________________________________________________________________


100

% %

3210 Testvorber. Hardware

16

%

13

%

22

% 4%

9%

2%

22

% 7% 5%

3220 Testvorber. Software

13

% 3% 8%

10

%

10

% 7% 4% 6% 6% 3% 4% 6% 7% 6% 7%

3300 Testspezifikation

32

%

10

%

10

%

29

%

10

%

10

%

3400 Testdurchführung 2% 7% 6% 4% 4% 4% 8% 9%

13

%

13

% 5%

12

%

10

% 3% 0%

3410 Testen (Produkt)

11

% 7% 8%

10

% 7% 6% 4% 8% 2% 3%

13

% 5% 4% 7% 5%

3420

Fehler in der

Testumgebung 5%

17

% 3% 5% 9% 3%

11

% 3% 6% 0% 6% 3%

27

% 3%

3500

Testauswertung

(Bugs) 9% 3% 7% 9% 9% 9% 2% 7% 5% 3% 7%

12

% 8% 6% 4%

3600 Testabschluss

27

%

73

%

5100

Testplanung

(Regr.test)

14

%

86

%

5200

Testvorbereitung

(Regr.test) 0% 5% 2%

15

% 8%

19

% 9% 7% 3% 1% 3% 1%

10

%

13

% 3%

5300

Testspezifikation

(Regr.test)

19

%

21

%

19

%

9%

9%

23

%

5400

Testdurchführung

(Regr.test) 2% 5% 3% 6% 6%

11

% 4% 7% 2% 2% 7%

10

%

12

%

13

%

10

%

5500

Testauswertung

(Regr.test) 2% 4% 4%

12

%

19

% 7% 6% 5% 2% 3% 6%

10

% 7% 9% 4%

5600 Testabschluss

10 8% 8%

75

____________________________________________________________________________________________________


101

(Regr.test) % %

7100 Einarbeitung

67

%

11

%

11

%

11

%

7200 Besprechungen

12

% 3%

13

% 6% 8% 8% 7% 5% 4% 2% 9% 4% 7% 4% 9%

7300

Recherche

(Werkzeuge,…)

11

%

17

%

23

%

26

%

11

%

11

%

7400 Statusreport Test

19

%

23

% 6%

6% 6% 6%

6% 6% 6% 6% 6%

7500

Administration,

Maintenance, HW 5%

13

% 4%

17

%

11

% 5% 0% 8%

14

%

3%

5%

17

%

7600 Third Party Integration 6%

10

% 5% 4% 4% 4% 7% 1% 7% 7%

12

%

14

%

11

% 8%

7700 Testmanagement 7% 5% 6%

10

%

10

% 2%

10

% 6% 5% 3% 4% 8%

10

% 8% 6%

8100

Administration,

Maintenance, HW

10

% 8% 4% 2% 1%

11

%

7% 4% 2%

14

% 1%

12

% 8%

17

%

9100 Analyse 3%

2% 1%

9%

14

% 9% 3%

46

% 4%

3% 7%

9200 Hot Fix

30

%

10

% 3%

20

%

37

%


50

%

50

%

Insgesamt 6% 5% 6% 8% 8% 7% 5% 7% 5% 4% 8% 8% 8% 8% 7%

Tabelle 16: Aufwand aller Aktivitäten je Projektwoche, in Stunden, je Aktivität normiert

____________________________________________________________________________________________________


102

Abbildung 28: Zeitlicher Verlauf der Stunden je Aktivität

Abbildung 29: Zeitlicher Verlauf der Stunden je Aktivität, je Aktivität normiert (?)

0,0

50,0

100,0

150,0

200,0

250,0

300,0

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

____________________________________________________________________________________________________


103

Abbildung 30: Zeitlicher Verlauf der Aktivitäten der Testdurchführung, normiert

Abbildung 31: Zeitlicher Verlauf der Aktivitäten des Regressiontest, in Stunden

0

0,02

0,04

0,06

0,08

0,1

0,12

0,14

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Testdurchführung

0

10

20

30

40

50

60

70

80

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Testplanung (Regr.test)Testvorbereitung (Regr.test)Testspezifikation (Regr.test)

____________________________________________________________________________________________________


104

5.4.6. Anzahl der Mitarbeiter pro Aktivität über die Zeit

Aktivität Bezeichnung 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

3100 Testplanung 3

1

1

2

3200 Testvorbereitung allg. 1 2 2 1 2 2 2 2 2 1 2 1 1 2 2

3210 Testvorber. Hardware 4 1

5 1

2

1

1 1 1

3220 Testvorber. Software 7 3 5 5 4 4 2 4 4 2 4 5 5 3 3

3300 Testspezifikation 2 1 1

2 1

1

3400 Testdurchführung 1 2 3 1 2 2 2 3 3 2 2 3 2 2 1

3410 Testen (Produkt) 7 4 5 6 6 4 3 5 2 2 5 4 4 4 3

3420 Fehler in der Testumgebung 2 2 1 2 1 1 2 1 1

1 1 2 1

3500 Testauswertung (Bugs) 7 5 4 3 5 4 2 6 5 2 6 4 5 4 4

3600 Testabschluss

2 1

5100 Testplanung (Regr.test) 1

1

5200 Testvorbereitung (Regr.test) 2 4 3 4 4 5 3 3 3 1 3 2 4 4 1

5300 Testspezifikation (Regr.test)

1 1 1

1

1 1

5400 Testdurchführung (Regr.test) 5 6 7 7 6 5 4 6 4 3 5 7 7 7 6

5500 Testauswertung (Regr.test) 4 4 6 6 5 4 5 3 3 1 4 4 5 5 3

5600 Testabschluss (Regr.test) 1 1 1

2

7100 Einarbeitung

2 1

1

1

7200 Besprechungen 6 4 7 6 5 5 5 3 3 2 6 4 6 4 6

____________________________________________________________________________________________________


105

7300 Recherche (Werkzeuge,…) 1 1 1

1

1

1

7400 Statusreport Test 1

2 1

1 1 1

1 1 1 1 1

7500 Administration, Maintenance, HW 1 2 1 3 4 2

3 3

1

2 2

7600 Third Party Integration 3

3 2 2 1 2 2 1 1 2 2 2 2 2

7700 Testmanagement 1 1 1 1 2 1 1 1 1 2 1 1 1 1 1

8100 Administration, Maintenance, HW 3 2 3 1 1 2

2 2 1 3 2 3 3 2

9100 Analyse 1

1 1

2 2 1 1 2 1

1 1

9200 Hot Fix

2 1 1

1 1


2 3

Tabelle 17: Anzahl der Mitarbeiter pro Aktivität je Projektwoche

Geleistete Stunden geteilt durch Anzahl der Mitarbeiter

Aktivität Bezeichnung 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

3100 Testplanung 0,6

0,3

1

1,5

3200 Testvorbereitung allg. 3,3 1,2 1,5 1 1,9 1,8 1 1,8 1,9 3,5 7,3 0,8 4 4 14

3210 Testvorber. Hardware 1,1 3,5

1,2 1

1,3

0,5

6 2 1,5

3220 Testvorber. Software 3,5 1,8 2,9 3,9 4,9 3,5 3,8 2,6 2,9 3 1,8 2,4 2,5 3,5 4,3

3300 Testspezifikation 1,6 1 1

1,5 1

1

3400 Testdurchführung 8 15 8,8 17 8,5 8,5 16 12 17 28 10 16 21 6,3 2

3410 Testen (Produkt) 10 10 10 9,9 7 8,5 9 10 6,9 8,5 16 8,1 6,4 11 9,5

3420 Fehler in der Testumgebung 0,8 2,8 1 0,8 3 1 1,8 1 2

2 1 4,5 1

____________________________________________________________________________________________________


106

3500 Testauswertung (Bugs) 4,3 2 5,6 9,5 5,5 6,9 3,5 3,6 3,5 4,5 3,8 9,6 5,2 4,4 3,5

3600 Testabschluss

1,5 8

5100 Testplanung (Regr.test)

0,2

1

5200 Testvorbereitung (Regr.test) 0,4 1,9 1,2 6 3 6,1 4,7 3,7 1,8 2 1,7 1 3,9 5,1 4

5300 Testspezifikation (Regr.test)

2 2,3 2

1

1 2,5

5400 Testdurchführung (Regr.test) 2,6 4,7 2,5 5,2 5,5 13 6 6,3 3,1 3,9 7,6 8,3 9,5 11 9,4

5500 Testauswertung (Regr.test) 1,1 2,9 2 5,5 11 4,6 3,2 4,7 2 8 4 6,8 4,1 5 3,8

5600 Testabschluss (Regr.test)

1,3 1 1

4,9

7100 Einarbeitung

1,5 0,5

0,5

0,5

7200 Besprechungen 3 0,9 2,7 1,5 2,5 2,5 2 2,5 1,9 1,3 2,1 1,6 1,8 1,6 2,3

7300 Recherche (Werkzeuge,…)

1 1,5 2

2,3

1

1

7400 Statusreport Test 1,5

0,9 0,5

0,5 0,5 0,5

0,5 0,5 0,5 0,5 0,5

7500 Administration, Maintenance, HW 2,5 3,4 2 2,9 1,4 1,3

1,3 2,3

1,5

1,3 4,3

7600 Third Party Integration 2,4

3,7 2,8 2,5 4 2,5 3,8 1,5 8 4 6,5 7,8 6 4,3

7700 Testmanagement 7 5,8 6,5 10 5 2 10 6,5 5,3 1,5 4,5 8,5 11 8,5 6,5

8100 Administration, Maintenance, HW 2,4 2,8 0,9 1,8 0,5 4

2,5 1,4 1,5 3,3 0,5 2,9 1,8 6,3

9100 Analyse 1

0,8 0,5

1,5 2,5 3 1 8 1,3

1 2,5

9200 Hot Fix

2,3 1,5 0,5

3 5,5


2 1,3

Tabelle 18: Geleistete Stunden bezogen auf die Anzahl der Mitarbeiter pro Aktivität je Projektwoche

____________________________________________________________________________________________________


107

5.5. Interpretation

5.5.1. Generelle Aussagen

- Sehr gute Überdeckung der Aufwände im Produkttest (3xxx) und Regressionstest

(5xxx) (0 / 0)

- Offensichtlich gute Arbeitsteilung und gute Verwaltung, daher Konzentration einzelner

Mitarbeiter auf das produktive Testen, Abarbeitung übergeordneter Aktivitäten durch

wenige Mitarbeiter (5.3.8)

- Die Summe aller Stunden hat zwei Maxima (KW 19 und KW 28) und ein Minimum

(KW 25). In der KW 25 waren zwei der sieben Mitarbeiter nicht im Projekt beschäftigt,

einer notierte nur 4,5h (5.3.10)

- Im Vergleich der Aufwände pro Woche der "Durchführungsaktivitäten"

(Testdurchführung 3400, Testen (Produkt) 3410 und Testdurchführung (Regr. Test)

5400) erscheint es, als ob "Testdurchführung" höher priorisiert ist als die anderen

beiden Aktivitäten, in den Wochen KW 24 und 25 ist eine auffällige Zunahme des

Aufwands bei gleichzeitiger Abnahme der anderen Aktivitäten. (0)

5.5.2. Auffälligkeiten

- 17% Overhead erscheint relativ groß (6.3.3)

- 81% des Overheads wird von 3 der 7 Mitarbeiter abgeleistet (MA 2,4 und 6) (0)

- Die wöchentliche erfasste Arbeitszeit schwankt zwischen 4h und 45,5h. in 20 Wochen

wurden mehr als 40h aufgeschrieben, in 7 Wochen wurden von jeweils einem

Mitarbeiter keine Stunden notiert (Urlaub, anderes Projekt?)

- In der KW 24 waren nur 4 Arbeitstage (Pfingstmontag), von Mitarbeiter 7 wurden

allerdings 41h notiert.

____________________________________________________________________________________________________


108

- Unerwarteter zeitlicher Verlauf im Regressionstest: Aktivität "Testabschluss erscheint

in den KWs 18-20 mit jeweils 1h, dann wieder in KW 29 mit 9,75h, die

Testdurchführung hat eine Häufung um die KW 29. Die Testspezifikation beginnt erst in

der KW 18 (nachdem bereits 41h in der Testdurchführung erfasst wurden) (0)

6. Projekt B

6.1. Eckdaten

Branche: Elektronik

Unternehmensgrösse: 100 – 1.000 MA



6.2. Systematik


Im Zeitraum 31.03.2014 bis 06.03.2015 wurden die Aktivitäten des Testmitarbeiters durch

Selbstaufschreibung in Excel Tabellen erfasst. Die Tabellen wurden in enger Absprache mit

dem Partnerunternehmen durch das IWT erstellt und durch einen Mitarbeiter des IWT an den

ausfüllenden Mitarbeiter des Partnerunternehmens übergeben.

6.2.2. Datenbasis

Alle Daten aus den im Rahmen der Aufwandserfassung erstellten Tabellen wurden in einer

SQL Datenbank abgelegt. Alle Abfragen wurden mit MySQL Workbench entwickelt und


____________________________________________________________________________________________________


109

Zusätzlich wurden in dieser Auswertung noch Daten, die direkt vom Partnerunternehmen

beigestellt wurden, eingearbeitet: eine Liste an Bug Einträgen, versehen mit Autor und

Eintragsdatum sowie eine Zeiterfassung der Entwickler.

6.2.3. Zusammenfassung Systemtest und Abnahmetest

In dieser Auswertung werden alle Stunden, die auf Aktivitäten der Kategorie "Approval Test"

(4xxx) gebucht wurden zu den Aktivitäten der Kategorie "Systemtest" (3xxx) addiert. Eine

Unterscheidung erscheint nicht sinnvoll, es konnte im Nachhinein nicht mehr eruiert werden,

welche der Stunden auf Systemtest und welche auf Approval Test gebucht wurden.


6.3.1. Umfang der Datenbasis

Gesamtstunden: 632,0

6.3.2. Verteilung der Gesamtstunden

In der Anlage der Zeiterfassungsbögen wurden zwei Tätigkeitsfelder identifiziert: GUI und

Embedded, ausgefüllt wurden nur Tätigkeiten im Bereich "GUI"

____________________________________________________________________________________________________


110

Insgesamt wurden 7 Aktivitäten bebucht:

Kat

egor

ie

Bez

eich

nung

Akt

ivita

et

Stun

den

Ant

eil

Kat

egor

ie

Ant

eil

Ges

amt

Stun

den

Ant

eil

Systemtest Test Preparation 3200 72 14% 11,4%

497 79%

Test Specification 3300 246 49% 38,9%

Test Execution 3400 119 24% 18,8%

Test Analyzation 3500 55 11% 8,7%

Test Conclusion 3600 5 1% 0,8%

Overhead Meetings 9200 83 61% 13,1% 135 21% Tool Research/ Test

infrastructure 9300 52 39% 8,2%

Tabelle 19: Übersicht über Kategorien, Aktivitäten und Gesamtaufwand

____________________________________________________________________________________________________


111

Abbildung 32: Verteilung des Gesamtaufwands auf die Aktivitäten

6.3.3. Verteilung auf Kategorien

Kategorie Stunden Anteil %

Systemtest 497 79%

Overhead 135 21%

Tabelle 20: Gesamtaufwand je Kategorie

____________________________________________________________________________________________________


112

Abbildung 33: Verteilung des Gesamtaufwands auf Aktivitäts-Kategorien

6.3.4. Verteilung Overhead

Aktivität Stunden Anteil Overhead

Anteil Gesamt

Meetings 83 61% 13,1%

Tool Research/ Test infrastructure 52 39% 8,2%

Tabelle 21: Aufteilung des Aufwands der Overhead-Aktivitäten


6.4.1. Einleitung

Der zeitliche Verlauf von Einzelaktivitäten und Kategorien wird auf mehrfache Art und Weise

dargestellt: Zum einen wird das Auftreten von Einträgen mit deren Länge dargestellt, zum

anderen die Kumulation der Einträge sowohl absolut (Einheit Stunden) als auch relativ zum

Gesamtaufwand diesen Eintrags (Einheit Prozent)

____________________________________________________________________________________________________


113


Abbildung 34: Gesamtaufwand in Stunden pro Woche und kumuliert (y-Achse rechts)

6.4.3. Kategorien

0

100

200

300

400

500

600

700

0

5

10

15

20

25

30

35

2014

14

2014

16

2014

18

2014

20

2014

22

2014

24

2014

26

2014

28

2014

30

2014

32

2014

34

2014

36

2014

38

2014

39

2014

41

2014

43

2014

45

2014

47

2014

49

2014

51

2015

01

2015

03

2015

05

2015

07

2015

09

Stunden / KW

Kumuliert

____________________________________________________________________________________________________


114

Abbildung 35: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden)

Abbildung 36: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden), kumuliert

____________________________________________________________________________________________________


115

Abbildung 37: Zeitlicher Verlauf der Stunden je Aufwandskategorie, kumuliert

____________________________________________________________________________________________________


116

6.4.3.1. Systemtest

Abbildung 38: Aufwand der Aktivitäten, in Stunden pro Tag

Abbildung 39: Aufwand der Aktivitäten, Stunden kumuliert

____________________________________________________________________________________________________


117

Abbildung 40: Aufwand der Aktivitäten, Stunden kumuliert, je Aktivität normiert

6.4.3.2. Overhead

Abbildung 41: Aufwand der Overhead-Aktivitäten, in Stunden pro Tag

0

1

2

3

4

5

6

7

8

9

02.0

3.20

14

21.0

4.20

14

10.0

6.20

14

30.0

7.20

14

18.0

9.20

14

07.1

1.20

14

27.1

2.20

14

15.0

2.20

15

06.0

4.20

15

Meetings

Tool Research

____________________________________________________________________________________________________


118

Abbildung 42: Aufwand der Overhead-Aktivitäten, Stunden kumuliert

Abbildung 43: Aufwand der Overhead-Aktivitäten, Stunden kumuliert, je Aktivität normiert

6.4.4. Anteil Besprechungen und Spezifikation

Im Laufe des Projekts wurden immer weitere externe Kräfte zur Testausführung hinzugeholt.

Um die Auswirkungen zu bewerten wird der Anteil verschiedener Aktivitäten über die Zeit

0102030405060708090

02.0

3.20

14

22.0

3.20

14

11.0

4.20

14

01.0

5.20

14

21.0

5.20

14

10.0

6.20

14

30.0

6.20

14

20.0

7.20

14

09.0

8.20

14

29.0

8.20

14

18.0

9.20

14

08.1

0.20

14

28.1

0.20

14

17.1

1.20

14

07.1

2.20

14

27.1

2.20

14

16.0

1.20

15

05.0

2.20

15

25.0

2.20

15

17.0

3.20

15

06.0

4.20

15

MeetingsTool…

0%10%20%30%40%50%60%70%80%90%

100%

02.0

3.20

14

22.0

3.20

14

11.0

4.20

14

01.0

5.20

14

21.0

5.20

14

10.0

6.20

14

30.0

6.20

14

20.0

7.20

14

09.0

8.20

14

29.0

8.20

14

18.0

9.20

14

08.1

0.20

14

28.1

0.20

14

17.1

1.20

14

07.1

2.20

14

27.1

2.20

14

16.0

1.20

15

05.0

2.20

15

25.0

2.20

15

17.0

3.20

15

06.0

4.20

15

MeetingsTool…

____________________________________________________________________________________________________


119

betrachtet. Dabei wird das Gesamtprojekt in unterschiedlich grosse zeitliche Fragmente

zerlegt.

6.4.4.1. Aufteilung Systemtest

Abbildung 44: Anteil der Aktivitäten im Systemtest über 16 Zeitabschnitte

Jeder Zeitabschnitt (ein Balken) entspricht ca. 6% des Gesamtaufwands.

Lesebeispiel: In der Zeit von KW 30 bis KW 34 2014 (7. Balken) verteilt sich die Aktivität im

Systemtest auf 22% Test Preparation, 49% Test Exexution und 29% Test Analyzation.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Test Conclusion

Test Analyzation

Test Execution

Test Specification

Test Preparation

____________________________________________________________________________________________________


120

Abbildung 45: Anteil der Aktivitäten im Systemtest über 5 Zeitabschnitte

Jeder Balken entspricht ca. 20% des Gesamtaufwands.

6.4.4.2. Anteile aller Aktivitäten

Abbildung 46: Anteil aller Aktivitäten über 10 Zeitabschnitte

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

25 2014 34 2014 46 2014 5 2015 10 2015

Test Conclusion

Test Analyzation

Test Execution

Test Specification

Test Preparation

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

2014

21

2014

25

2014

29

2014

34

2014

37

2014

45

2014

49

2015

3

2015

5

2015

9

Tool research / TestinfrastructureMeetings

Test Conclusion

Test Analyzation

Test Execution

Test Specification

Test Preparation

____________________________________________________________________________________________________


121

Jeder Balken entspricht etwa 10% des Gesamtaufwands

Abbildung 47: Anteil aller Aktivitäten über 10 Zeitabschnitte

Jeder Ballen entspricht ca. 20% des Gesamtaufwands.

6.4.4.3. Anteil Besprechungen

Abbildung 48: Anteil der Aktivität „Besprechungen“ am Gesamtaufwand über 10 Zeitabschnitte

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

2014 25 2014 34 2014 45 2015 3 2015 9

Tool research / Testinfrastructure

Meetings

Test Conclusion

Test Analyzation

Test Execution

Test Specification

Test Preparation

0%

5%

10%

15%

20%

25%

30%

35%

40%

2014

21

2014

25

2014

29

2014

34

2014

37

2014

45

2014

49

2015

3

2015

5

2015

9

____________________________________________________________________________________________________


122

Jeder Balken entspricht etwa 10% des Gesamtaufwands.

Abbildung 49: Anteil der Aktivität „Besprechungen“ am Gesamtaufwand über 10 Zeitabschnitte

Jeder Balken entspricht ca. 20% des Gesamtaufwands.

6.5. Statistische Auswertungen

Hier wird eine Statistik der Einzeleinträge erstellt. Wie oft wurde eine Aktivität bebucht? Wie

lange ist die mittlere Dauer etc.

0%

5%

10%

15%

20%

25%

30%

35%

40%

2014 25 2014 34 2014 45 2015 3 2015 9

____________________________________________________________________________________________________


123

Akt

ivitä

t

Anz

ahl

Auf

wan

d

Mitt

lere

Dau

er

Med

ian

Min

Max

His

togr

amm

Test Preparation 15 72 4,8 5 2 7

Test Specification 53 246 4,6 5 2 6

Test Execution 27 119 4,4 4 2 6

Test Analyzation 18 55 3,1 3,5 1 5

Test Conclusion 4 5 1,3 1 1 2

Meetings 61 83 1,4 1 1 3

____________________________________________________________________________________________________


124

Tool Research 12 52 4,3 3,5 2 8

Gesamt 190 632 3,3 4 1 8

Tabelle 22: Übersicht statistische Daten je Aktivität

6.6. Zusammenhang mit Zusatzdaten

Im Juli 2015 wurden vom Partnerunternehmen weitere Daten zur Verfügung gestellt.

6.6.1. Bug-Report

In der Tabelle sind 343 Bugs notiert, jeweils mit Autor, Datum, Status, Auflösung, Typ und

ID. Zur Auswertung kamen davon Autor und Datum.

Um eine Vergleichbarkeit mit den bisherigen Daten zu erreichen wurden die Einträge nach

Kalenderwoche gruppiert:

____________________________________________________________________________________________________


125

Abbildung 50: Anzahl der Bugeinträge aller Reporter über die Zeit, pro Woche und kumuliert

In einer weiteren Filterung wurden aus diesen Daten nur die Einträge des Testers, der in der

Zeiterfassung gemessen wurde, verwertet (insgesamt 52):

____________________________________________________________________________________________________


126

Abbildung 51: Anzahl der Bugeinträge von Tester 1 über die Zeit, pro Woche und kumuliert

6.6.2. Zeiterfassung der Entwickler

Die Datei enthält insgesamt 2278 Einzeleinträge der internen Zeiterfassung im Zeitraum

10.06.2013 (KW 24 2013) bis 02.07.2015 (KW 27 2015) von 10 Mitarbeitern.

Abbildung 52: Verlauf der Projektstundenerfassung aller Mitarbeiter, Stunden pro Woche und kumuliert

Diese Daten erstrecken sich über eine größeren Zeitraum als die Daten, die mit Hilfe der

Zeiterfassung aufgenommen wurden.

Vergleicht man die Stunden der Zeiterfassung und der Projektstundenerfassung des

beobachteten Mitarbeiters fallen einige Besonderheiten auf:

____________________________________________________________________________________________________


127

Abbildung 53: Vergleich von Zeiterfassung und Projektstunden des Testers 1

- Die Zeiten, in den keine Stunden erfasst wurden stimmen gut überein

- Einträge, bei denen mehr Stunden in den Projektstunden stehen als in der Zeiterfassung

lassen sich durch andere Aktivitäten erklären

- Einträge, bei denen die Zeiterfassung mehr Stunden aufweist als die Projektstundenerfassung könnten Messungenauigkeiten sein.

6.6.3. Zeiterfassung weitere Mitarbeiter

Die Datei enthält Monatsarbeitszeiten zweier weiterer Mitarbeiter im Zeitraum April 2014 -

Juni 2015. Dabei werden die Zahlen mit Hilfe der Arbeitstage des Monats multipliziert mit

einem monatlichen Faktor berechnet.

Die beiden Mitarbeiter tauchen in der Projektstundenerfassung nicht auf.

____________________________________________________________________________________________________


128

6.6.4. Interpretation der Zusatzdaten

6.6.4.1. Bugeinträge von Mitarbeiter 1

In der durch die Zeiterfassung beobachteten Zeit (2014 14 - 2015 10) wurden nur 5 Einträge

in der Bugliste erfasst. Das zeitliche Auftreten dieser Einträge passt gut zum Auftreten der

Stunden:

Abbildung 54: Auftreten der Bug Einträge im Vergleich zur Zeiterfassung

Insgesamt sind 52 Bugeinträge von MA 1 in der Liste. Legt man die Zeiterfassung aus

projektstunden_combigui_auswertung.xlsx zugrunde ergibt sich folgendes Bild:

____________________________________________________________________________________________________


129

Abbildung 55: Auftreten der Bug Einträge im Vergleich zu den Projektstunden

Zu einer Zeit, in der 50% der erfassten Stunden bearbeitet sind (KW 2015 14) sind erst

knapp 10% der Bugeinträge erfolgt. 58% der Bugeinträge (30) werden während nur 4

Wochen erstellt (KW 2015 12 - 2015 15).

Abbildung 56: Fehlerfindungsrate und Verhältnis Bug zu Arbeitszeit

____________________________________________________________________________________________________


130

Die maximale Fehlerfindungsrate ist in der KW 2015 15 mit 0,36 Bugs / Stunde.

Das Verhältnis des Fortschritts der Bugeinträge zum Fortschritt ist bis zur KW 2015 12 unter

25%. Wäre der Fortschritt der Bugeinträge gleichzeitig zum Fortschritt der abgeleisteten

Stunden wäre diese Zahl bei 100%.

Insgesamt werden 0,046 / h eingetragen bzw. alle 21,7h ein Bug.

6.6.4.2. Bugeinträge von Mitarbeiter 2

Abbildung 57: Bug Einträge und Projektstunden von Mitarbeiter 2

Hier entstehen die Bugeinträge zeitgleicher mit den auflaufenden Stunden als in den

bisherigen Beobachtungen. Zum Zeitpunkt, zu dem 50% der Stunden geleistet sind (KW

2014 45) sind 40% der Bug Einträge erfolgt (36 von 90)

Insgesamt werden 0,035 / h eingetragen bzw. alle 27,9h ein Bug.

6.6.4.3. Zusammenhang Projektstunden zu Bugeinträge

In dieser Betrachtung wurden die Mitarbeiter berücksichtigt, die sowohl in der

Projektstundenerfassung als auch in der Bug Liste auftauchen.

Diese Daten umfassen 2278h und 166 Bugs.

____________________________________________________________________________________________________


131

Abbildung 58: Zusammenhang Bug Einträge und Projektstundenerfassung

Abbildung 59: Zusammenhang zwischen Anzahl Bugs (y-Achse) und Stundensumme pro Mitarbeiter (x-Achse)

____________________________________________________________________________________________________


132

Mitarbeiter Dauer Bugs Stunde / Bug

MA 01 816 25 32,6

MA 02 348 13 26,8

MA 03 208 52 4,0

MA 04 207 12 17,3

MA 05 198 22 9,0

MA 06 184 2 92,0

MA 07 176 10 17,6

MA 08 109 5 21,8

MA 09 21 5 4,2

MA 10 11 20 0,6

Gesamtergebnis 2278 166 13,7

Tabelle 23: Übersicht Gesamtaufwand und Bugs pro Mitarbeiter

6.7. Interpretation

6.7.1. Auffälligkeiten

Im Vergleich zu anderen erfassten Projekten erscheint der Anteil der Kategorie

"Testspezifikation" als sehr hoch (je 51% / 36% des System / Approvaltests und 39% des

gesamten Aufwands. (Bei anderen Projekten im kleinen Prozentbereich bis ca. 20%)

Interessant wäre hier die genaue Analyse, welche Tätigkeiten unter "Testspezifikation"

gebucht wurden und ob bestimmte Gegebenheiten dafür sorgen, dass der

Spezifikationsaufwand hoch ist.

Ungewöhnlich ist auch das zeitliche Auftreten der Einzelaktivitäten, insbesondere im

Systemtest. (vgl. 6.4.3.1)

Zu einem Zeitpunkt, an dem erst 20% der Gesamtaktivität abgeschlossen ist sind bereits alle

Stunden der "Test conclusion" erbracht (13.06.2014)

63% der "Test preparation" werden in einem Zeitraum erbracht, in dem nur noch 15% der

Gesamtaktivität ausstehen.

____________________________________________________________________________________________________


133

Unüblich erscheint auch der steigende Anteil an Besprechungen zu Projektende und der

sehr geringe Anteil zu Projektstart.

Überraschend erscheint die steigende Fehlerfindungsrate zu Projekt (Beobachtungs)- ende.

6.7.2. Ausblick

Mit Hilfe der Darstellung der Daten in diesem Dokument können in Zusammenarbeit mit dem

Partner Einzelaspekte beleuchtet und analysiert werden sowie die zu Grunde liegenden

Besonderheiten diesen Projektumfelds erfasst werden.

Auch weitere, speziell für den Partner interessante Daten und Zusammenhänge können aus

den bestehenden Daten gewonnen werden.

Im Vergleich zu weiteren Projekten dieses Partners oder zwischen mehreren Partnern kann

dieses Projekt eingeordnet und ggf. optimiert werden.

7. Projekt C

7.1. Eckdaten

Branche: Elektronik




____________________________________________________________________________________________________


134

7.2. Systematik


Im Zeitraum 14.07.2014 bis 20.11.2015 wurden alle Aktivitäten der Tester manuell in Excel /

OpenOffice Tabellen erfasst. Die Struktur der Erfassungstabellen wurde in enger

Abstimmung mit dem Projektpartner erstellt und den Testern erläutert. Jede Arbeitsmappe

enthält die Daten eines Quartals. Insgesamt bestehen 6 dieser Dokumente. Der aktuelle

Stand wurde wöchentlich an das IWT gesendet.

7.2.2. Datenbasis

Alle Daten aus den im Rahmen der Aufwandserfassung erstellten Tabellen wurden in einer

SQL Datenbank abgelegt. Alle Abfragen wurden mit MySQL Workbench entwickelt und


Es wurden zwei Releases der betrachteten Software vermessen und analysiert:

• Release 1.2.0 (kurz: Rel12)

• Release 1.3.0 (kurz: Rel13)


7.3.1. Gesamtstunden

Gesamtstunden: 2.489,7

7.3.2. Gegenüberstellung von Release 1.2.0 und Release 1.3.0

Rel12 Rel13 Gesamt

____________________________________________________________________________________________________


135

Summe Stunden 1109,1 1380,6 2489,7

Start Datum 14.07.2014 02.03.2015 14.07.2014

Ende Datum 27.02.2015 20.11.2015 20.11.2015

Anzahl Tage 228 263 494

Stunden / Woche 34,1 36,7 35,3

Tabelle 24: Übersichtsdaten Release 1.2.0 und Release 1.3.0

Abbildung 60: Verteilung des Gesamtaufwands zwischen Release 1.2.0 und Release 1.3.0

____________________________________________________________________________________________________


136

7.3.3. Verteilung der Stunden auf die Testphasen

7.3.3.1. Beschreibung

All entries were linked to one of the following test phases:

- Integration

- System

- Approval

- Overhead

7.3.3.2. Ergebnis

The distribution within these test phases is as follows:

Overall Rel12 Rel13 Overall Rel12 Rel13

Integration

Test Preparation 2200 1,8 1,8 0,0

184,9 184,9 0,0 Test Specification 2300 9,0 9,0 0,0

Test Execution 2400 118,8 118,8 0,0 7,4% 16,7% 0,0%

Test Analyzation 2500 55,4 55,4 0,0

System

Test Planning 3100 14,1 14,1 0,0

1111,7 716,0 387,1


Test Specification 3300 308,7 154,0 154,7

Test Execution 3400 469,3 347,1 122,3 44,7% 64,6% 28,0%


Test Conclusion 3600 15,6 7,0 8,6

Approval

Test Planning 4100 3,0 0,0 3,0

909,0 107,3 801,7


Test Specification 4300 141,6 9,5 132,1

Test Execution 4400 489,6 48,4 441,2 36,5% 9,7% 58,1%


Test Conclusion 4600 41,3 6,1 35,2

Overhead Meetings 9200 46,3 32,8 13,5 284,1 100,9 183,3

____________________________________________________________________________________________________


137

Tool Research/ Test infrastructure 9300 237,8 68,0 169,8 11,4% 9,1% 13,3%

Overall

2489,7 1109,1 1380,6

Tabelle 25: Gesamtaufwand pro Projektphase, pro Aktivität und nach Releases

Abbildung 61: Verteilung der Aufwände nach Projektphasen, je Release und Gesamt

7.3.4. Verteilung der Stunden auf Testaktivitäten


Each test phase contained several activities within this phase:

x100: Test Planning

x200: Test Preparation

x300: Test Specification

x400: Test Execution

Rel13

Rel12

Gesamt

____________________________________________________________________________________________________


138

x500: Test Analyzation

x600: Test Conclusion

7.3.5. Ergebnis

Overall Rel12 Rel13

Planning 17,1 0,8% 14,1 1,4% 3,0 0,3%

Preparation 85,7 3,9% 43,4 4,3% 42,3 3,5%

Specification 459,3 20,8% 172,5 17,1% 286,8 23,9%

Execution 1077,7 48,9% 514,3 51,0% 563,4 47,1%

Analyzation 509,0 23,1% 250,9 24,9% 258,2 21,6%

Conclusion 56,8 2,6% 13,1 1,3% 43,8 3,7%

2205,6 1008,3 1197,3

Tabelle 26: Gesamtaufwand pro Aktivität, nach Releases und Gesamt

____________________________________________________________________________________________________


139

Abbildung 62: Anteil der Aktivitäten am Gesamtaufwand, je Release und Gesamt

7.3.6. Verteilung der Stunden auf Systemkomponenten


During creation of the time tracking spreadsheets, 5 branches of activity were identified

GS Overall System (Sensor with software for PC-configuration)

KOM LIMA communication to sensor

LIZ Licensing of image processing modules (PC/sensor)

PC PC-Installer for weQube PC-Software

WS webserver of the sensor

7.3.6.2. Ergebnis

Der deutlich größte Anteil (96.4%) wurde der Systemkomponente "GS" zugeordnet. Im

Release 1.3.0 wurden alle Stunden auf "GS" gebucht.

GS KOM LIZ PC WS Gesamt

Integration

Preparation 1,8

1,8

Specification 9,0

9,0

Execution 100,6

18,3

118,8

Analyzation 36,1

19,3

55,4

System

Planning 11,6

2,5

14,1

Preparation 76,7

76,7

Specification 305,2

2,5 1,0 308,7

Execution 458,8

8,0 2,5 469,3

Analyzation 227,3

227,3

Conclusion 15,6

15,6

____________________________________________________________________________________________________


140

Approval

Planning 3,0

3,0

Preparation 7,3

7,3

Specification 141,6

141,6

Execution 488,6

1,0

489,6

Analyzation 226,3

226,3

Conclusion 41,3

41,3

Overhead Meetings 37,6 1,7 1,5 2,8 2,8 46,3

Res./ infrastr- 211,5 5,8 6,1 7,0 7,4 237,8

Overall 2399,6 7,5 7,6 61,3 13,7 2489,7

96,4% 0,3% 0,3% 2,5% 0,5%

Tabelle 27: Gesamtaufwand pro Aktivität je Systemkomponente



Abbildung 63: Gesamtaufwand in Stunden pro Woche und kumuliert (y-Achse rechts)

____________________________________________________________________________________________________


141

7.4.2. Gesamtaufwand von Rel12 und Rel13

Abbildung 64: Gesamtaufwand von Rel12 und Rel13 in Stunden pro Woche und kumuliert (y-Achse rechts)

XXX: Beschriftung X-Achse ?

____________________________________________________________________________________________________


142

7.4.3. Testphasen

7.4.3.1. Gesamtaufwand Stunden

Abbildung 65: Aufwand der Testphasen, Stunden kumuliert, je Testphase normiert

____________________________________________________________________________________________________


143

7.4.3.2. Release 1.2.0

Abbildung 66: Aufwand der Testphasen von Release 1.2.0, Stunden kumuliert, je Testphase normiert

7.4.3.3. Release 1.3.0

Abbildung 67: Aufwand der Testphasen von Release 1.3.0, Stunden kumuliert, je Testphase normiert

____________________________________________________________________________________________________


144

7.4.4. Aktivitäten

7.4.4.1. Gesamtaufwand hours

Abbildung 68: Aufwand der Aktivitäten, Stunden kumuliert, je Aktivität normiert

____________________________________________________________________________________________________


145

7.4.4.2. Release 1.2.0

Abbildung 69: Aufwand der Aktivitäten von Release 1.2.0, Stunden kumuliert, je Aktivität normiert

7.4.4.3. Release 1.3.0

Abbildung 70: Aufwand der Aktivitäten von Release 1.3.0, Stunden kumuliert, je Aktivität normiert

____________________________________________________________________________________________________


146

7.5. Statistische Auswertung

7.5.1. Gesamteinträge

Anzahl Summe Mittelwert Min Max

Integration

Test Preparation 2200 1 1,8 1,75 1,8 1,8

Test Specification 2300 3 9,0 3,00 1,0 6,0

Test Execution 2400 25 118,8 4,75 1,3 8,7

Test Analyzation 2500 22 55,4 2,52 0,4 6,0

System

Test Planning 3100 6 14,1 2,35 0,3 8,8



Test Execution 3400 135 469,3 3,48 0,4 8,9


Test Conclusion 3600 11 15,6 1,42 0,5 4,0

Approval

Test Planning 4100 2 3,0 1,50 1,0 2,0



Test Execution 4400 118 489,6 4,15 1,0 9,0


Test Conclusion 4600 35 41,3 1,18 0,3 6,1

Overhead Meetings 9200 72 46,3 0,64 0,2 4,0

Tool Research/ Test infrastructure 9300 79 237,8 3,01 0,2 9,2

Overall 878 2489,7 2,84 9,8 0,2

Tabelle 28: Statistische Kenngrößen je Aktivität

7.5.2. Sortierung nach Aktivität


Overhead 151 284,1 1,88 0,2 9,2

Planning (x100) 8 17,1 2,14 0,3 8,8

____________________________________________________________________________________________________


147

Preparation (x200) 46 85,7 1,86 0,3 8,4

Specification (x300) 151 459,3 3,04 0,5 9,8

Execution (x400) 278 1077,7 3,88 0,4 9,0

Analyzation (x500) 198 509,0 2,57 0,4 6,0

Conclusion (x600) 46 56,8 1,24 0,3 6,1

Tabelle 29: Statistische Kenngrößen je Aktivitätsgruppe

Abbildung 71: Korrelation von Gesamtumfang der Aktivitäten mit mittlerer Eintragsgröße

7.5.3. Sortierung nach Projektphase


Integration 51 184,9 3,63 0,4 8,7

System 374 1111,7 2,97 0,3 9,1

Approval 302 909,0 3,01 0,3 9,8

____________________________________________________________________________________________________


148

Overhead 151 284,1 1,88 0,2 9,2

Tabelle 30: Statistische Kenngrößen je Projektphase

Abbildung 72: Korrelation von Gesamtumfang der Projektphasen mit mittlerer Eintragsgröße

8. Projekt D

8.1. Eckdaten

Branche: IT


Produktgrösse: 100 – 1.000 Personenjahre Entwicklungsaufwand


____________________________________________________________________________________________________


149

8.2. Datenbasis

Vom Projektpartner wurden Daten aus 35 Projekten zur Verfügung gestellt. Jede Excel Datei

enthält ein oder mehr Projekte, die ihrerseits wieder nach Kategorien und Arbeitspaketen

unterteilt sind. Für jedes dieser Einträge sind folgende Spalten vorgesehen:

• Budget (Vorgabe)

• Budget

• Datum Plan

• Aufwand Plan

• Aufwand

• Istaufwand

• Restaufwand

• AufwDiff

• Fertigstellungsgrad in % (berechnet)

In dieser Auswertung werden nur die Spalten "Aufwand Plan" und "Istaufwand"

berücksichtigt.

Die Einträge sind über die Projekte nicht normiert. Um eine Vergleichbarkeit herzustellen

wurden alle Stunden manuell in eine der folgenden Kategorien unterteilt:

• 0 Bedeutung ???

• 1

• 2

• 3

• 4

• 5

• 6

• 7

• 8

• 9

• U

____________________________________________________________________________________________________


150

Insgesamt wurden 28 Projekte betrachtet.

8.3. Methodik

Nachdem die erwähnten Kategorien manuell zugeordnet wurden, wurden in Excel die

Summen der Kategorien pro Projekt sowie weitere Kennzahlen extrahiert.

Basierend auf diesen Daten werden einige Zusammenhänge grafisch dargestellt.

8.4. Ergebnisse

8.4.1. Übersichtsdaten

Abbildung 73: Darstellung der Projektgrößen (Ist-Aufwand)

____________________________________________________________________________________________________


151

Abbildung 74: Anteil der Kategorien über alle Projekte

8.4.2. Auswertung Kategorien

Abbildung 75: Anteil Kategorien über alle Projekte

____________________________________________________________________________________________________


152

8.4.3. Statistische Daten

Abbildung 76: Anzahl der Einträge über Projektgröße, X-Achse [h] logarithmisch

8.4.4. Ist / Planvergleich

Abbildung 77: Differenz Ist-Plan im Verhältnis zur Projektgröße [h] (Negativer Wert: Ist kleiner als Plan)

____________________________________________________________________________________________________


153

Abbildung 78: Relative Abweichung [%] Ist-Plan im Verhältnis zur Projektgröße [h]. Logarithmische X-Achse.

____________________________________________________________________________________________________


154

9. Zusammenfassung

Die durchgeführten Auswertungen wurden von den Partnerunternehmen durchwegs positiv

bewertet. Die Analysen erlaubten einen tieferen Blick in das „Innenleben“ der Testprojekte,

als es im normalen Tageschgeschäft und mit der (Un-) Genauigkeit der bestehenden

Zeiterfassungssysteme möglich wäre. Die Diskussion der Ergebnisse führt außerdem zu

einer Reflexion der Projektorganisation und zum Hinterfragen bestehender Abläufe.

Das Feedback zu den durchgeführten Veranstaltungen war ebenfalls sehr erfreulich.

Eine Weiterführung und Vertiefung der begonnenen Aktivitäten ist daher wünschenswert.

Im Zuge einer Weiterführung des Projektes könnten folgenden Aufgaben bearbeitet werden:

• Verbreiterung der Projektbasis durch Einbezug weiterer Unternehmen und Projekte.

• Projektübergreifende Vergleich und die Bewertung der Daten. Nach entsprechender

Normierung und Kalibrierung würden die Daten hinsichtlich Korrelationen untersucht,

z.B. ob ein Zusammenhang besteht zwischen Teamgröße und Feh-

lerfindungsproduktivität.

• Weiterentwicklung dieser Ergebnisse zu konkreten Guidelines.

• Validierung der entwickelten Guidelines. Wiederum in realen Projekten könnte

untersucht werden, welchen Nutzen die Anwendung der entwickelten Guidelines

bringt.

____________________________________________________________________________________________________


155

10. Anhang

10.1. Abbildungsverzeichnis

Abbildung 1: Fehlerklassen ([SNE], S. 264) ..........................................................................16

Abbildung 2: Ermittlung der Testproduktivität ([SNE], S.73) ..................................................18

Abbildung 3: Stufen der Testautomatisierung ([SNE], S. 237) ..............................................24

Abbildung 4: Der Fundamentale Testprozess (Quelle: [SEI], 2012) ......................................26

Abbildung 5: Darstellung der Qualitätskriterien nach ISO 9126 ([SEI], S.103) ......................28

Abbildung 6: Anregungen und Ideen zum Einstieg in die Testautomatisierung ([SEI], S. 151)

.............................................................................................................................................31

Abbildung 7: Beispielhafte Organisation verschiedener Testteamtypen ([DUS], S. 173) .......40

Abbildung 8: Beispiel einer Fehlerkurve auf Basis eines Fehlermodells, [KRO, S. 34] ..........58

Abbildung 9: Aufwände beim Softwaretest ohne Berücksichtigung der Wartung für

automatisierte Testfälle (Quelle: IWT) ..................................................................................60

Abbildung 10: Aufwände beim Softwaretest unter Berücksichtigung der Wartung für

automatisierte Testfälle (Quelle: IWT) ..................................................................................62

Abbildung 11: Phasen im Testprozess ([SCH], S. 9) ............................................................68

Abbildung 12: Phasen mit geringem Einfluss auf ROI ([SCH], S. 9)......................................69

Abbildung 13: Phasen mit starkem Einfluss auf ROI ([SCH], S. 10) ......................................70

Abbildung 14: Datenmodell zur Erfassung der Projektdaten .................................................79

Abbildung 15: Datenbankschema zur Aufwandserfassung ...................................................80

____________________________________________________________________________________________________


156

Abbildung 16: Excel-Tabelle zur Selbsterfassung der Arbeitszeit je Aktivität ........................81

Abbildung 17: Verteilung der Gesamtstunden auf die Mitarbeiter .........................................83

Abbildung 18: Verteilung des Gesamtaufwands auf die Aktivitäten ......................................84

Abbildung 19: Verteilung des Gesamtaufwands auf Aktivitäts-Kategorien ............................86

Abbildung 20: Verteilung der Overhead-Aufwände ...............................................................87

Abbildung 21: Aufwandsanteile der Mitarbeiter am Overhead ..............................................88

Abbildung 22: Vergleich der Verteilung der Aktivitäten im Regressionstest (innerer Kreis)

und Produkttest (äußerer Kreis) ...........................................................................................89

Abbildung 23: Aufwand in Stunden pro Woche und kumuliert (y-Achse rechts) ....................93

Abbildung 24: Häufigkeitsverteilung der Wochenstunden .....................................................94

Abbildung 25: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden) .................96

Abbildung 26: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden), je Kategorie

normiert ................................................................................................................................96

Abbildung 27: Zeitlicher Verlauf der Stunden je Aufwandskategorie, kumuliert .....................97

Abbildung 28: Zeitlicher Verlauf der Stunden je Aktivität..................................................... 102

Abbildung 29: Zeitlicher Verlauf der Stunden je Aktivität, je Aktivität normiert (?) ............... 102

Abbildung 30: Zeitlicher Verlauf der Aktivitäten der Testdurchführung, normiert ................. 103

Abbildung 31: Zeitlicher Verlauf der Aktivitäten des Regressiontest, in Stunden ................ 103

Abbildung 32: Verteilung des Gesamtaufwands auf die Aktivitäten .................................... 111

Abbildung 33: Verteilung des Gesamtaufwands auf Aktivitäts-Kategorien .......................... 112

Abbildung 34: Gesamtaufwand in Stunden pro Woche und kumuliert (y-Achse rechts) ...... 113

____________________________________________________________________________________________________


157

Abbildung 35: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden) ............... 114

Abbildung 36: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden), kumuliert

........................................................................................................................................... 114

Abbildung 37: Zeitlicher Verlauf der Stunden je Aufwandskategorie, kumuliert ................... 115

Abbildung 38: Aufwand der Aktivitäten, in Stunden pro Tag ............................................... 116

Abbildung 39: Aufwand der Aktivitäten, Stunden kumuliert ................................................. 116

Abbildung 40: Aufwand der Aktivitäten, Stunden kumuliert, je Aktivität normiert ................. 117

Abbildung 41: Aufwand der Overhead-Aktivitäten, in Stunden pro Tag ............................... 117

Abbildung 42: Aufwand der Overhead-Aktivitäten, Stunden kumuliert ................................ 118

Abbildung 43: Aufwand der Overhead-Aktivitäten, Stunden kumuliert, je Aktivität normiert 118

Abbildung 44: Anteil der Aktivitäten im Systemtest über 16 Zeitabschnitte ......................... 119

Abbildung 45: Anteil der Aktivitäten im Systemtest über 5 Zeitabschnitte ........................... 120

Abbildung 46: Anteil aller Aktivitäten über 10 Zeitabschnitte ............................................... 120

Abbildung 47: Anteil aller Aktivitäten über 10 Zeitabschnitte ............................................... 121

Abbildung 48: Anteil der Aktivität „Besprechungen“ am Gesamtaufwand über 10

Zeitabschnitte ..................................................................................................................... 121

Abbildung 49: Anteil der Aktivität „Besprechungen“ am Gesamtaufwand über 10

Zeitabschnitte ..................................................................................................................... 122

Abbildung 50: Anzahl der Bugeinträge aller Reporter über die Zeit, pro Woche und kumuliert

........................................................................................................................................... 125

Abbildung 51: Anzahl der Bugeinträge von Tester 1 über die Zeit, pro Woche und kumuliert

........................................................................................................................................... 126

____________________________________________________________________________________________________


158

Abbildung 52: Verlauf der Projektstundenerfassung aller Mitarbeiter, Stunden pro Woche und

kumuliert ............................................................................................................................ 126

Abbildung 53: Vergleich von Zeiterfassung und Projektstunden des Testers 1 ................... 127

Abbildung 54: Auftreten der Bug Einträge im Vergleich zur Zeiterfassung .......................... 128

Abbildung 55: Auftreten der Bug Einträge im Vergleich zu den Projektstunden ................. 129

Abbildung 56: Fehlerfindungsrate und Verhältnis Bug zu Arbeitszeit .................................. 129

Abbildung 57: Bug Einträge und Projektstunden von Mitarbeiter 2 ..................................... 130

Abbildung 58: Zusammenhang Bug Einträge und Projektstundenerfassung ....................... 131

Abbildung 59: Zusammenhang zwischen Anzahl Bugs (y-Achse) und Stundensumme pro

Mitarbeiter (x-Achse) .......................................................................................................... 131

Abbildung 60: Verteilung des Gesamtaufwands zwischen Release 1.2.0 und Release 1.3.0

........................................................................................................................................... 135

Abbildung 61: Verteilung der Aufwände nach Projektphasen, je Release und Gesamt ....... 137

Abbildung 62: Anteil der Aktivitäten am Gesamtaufwand, je Release und Gesamt ............. 139

Abbildung 63: Gesamtaufwand in Stunden pro Woche und kumuliert (y-Achse rechts) ...... 140

Abbildung 64: Gesamtaufwand von Rel12 und Rel13 in Stunden pro Woche und kumuliert (y-

Achse rechts) ..................................................................................................................... 141

Abbildung 65: Aufwand der Testphasen, Stunden kumuliert, je Testphase normiert ........... 142

Abbildung 66: Aufwand der Testphasen von Release 1.2.0, Stunden kumuliert, je Testphase

normiert .............................................................................................................................. 143

Abbildung 67: Aufwand der Testphasen von Release 1.3.0, Stunden kumuliert, je Testphase

normiert .............................................................................................................................. 143

____________________________________________________________________________________________________


159

Abbildung 68: Aufwand der Aktivitäten, Stunden kumuliert, je Aktivität normiert ................. 144

Abbildung 69: Aufwand der Aktivitäten von Release 1.2.0, Stunden kumuliert, je Aktivität

normiert .............................................................................................................................. 145

Abbildung 70: Aufwand der Aktivitäten von Release 1.3.0, Stunden kumuliert, je Aktivität

normiert .............................................................................................................................. 145

Abbildung 71: Korrelation von Gesamtumfang der Aktivitäten mit mittlerer Eintragsgröße .. 147

Abbildung 72: Korrelation von Gesamtumfang der Projektphasen mit mittlerer Eintragsgröße

........................................................................................................................................... 148

Abbildung 73: Darstellung der Projektgrößen (Ist-Aufwand) ............................................... 150

Abbildung 74: Anteil der Kategorien über alle Projekte ....................................................... 151

Abbildung 75: Anteil Kategorien über alle Projekte ............................................................ 151

Abbildung 76: Anzahl der Einträge über Projektgröße, X-Achse [h] logarithmisch .............. 152

Abbildung 77: Differenz Ist-Plan im Verhältnis zur Projektgröße [h] (Negativer Wert: Ist

kleiner als Plan) .................................................................................................................. 152

Abbildung 78: Relative Abweichung [%] Ist-Plan im Verhältnis zur Projektgröße [h].

Logarithmische X-Achse. .................................................................................................... 153

10.2. Tabellenverzeichnis

Tabelle 1: Aufwand je Aktivität ..............................................................................................85

Tabelle 2: Aufwand je Aktivitäts-Kategorie............................................................................86

____________________________________________________________________________________________________


160

Tabelle 3: Aufwand der Overhead-Aktivitäten .......................................................................87

Tabelle 4: Overhead-Aufwand je Mitarbeiter .........................................................................88

Tabelle 5: Aufwand je Aktivität im Produkttest ......................................................................89

Tabelle 6: Aufwand je Aktivität im Regressionstest ...............................................................89

Tabelle 7: Anzahl der Mitarbeiter je Aktivität , sortiert nach Aktivität .....................................90

Tabelle 8: Anzahl der Mitarbeiter je Aktivität , sortiert nach Anzahl der Mitarbeiter ...............91

Tabelle 9: Gesamtaufwand in Stunden pro Woche ...............................................................92

Tabelle 10: Arbeitszeit der Mitarbeiter je Projektwoche ........................................................93

Tabelle 11: Anzahl der buchenden Mitarbeiter je Projektwoche ............................................95

Tabelle 12: Aufwand der Aktivitäts-Kategorien je Projektwoche ...........................................95

Tabelle 13: Aufwand der Aktivitäts-Kategorien je Projektwoche, je Kategorie normiert .........96

Tabelle 14: Aufwand der Aktivitäts-Kategorien je Projektwoche, je Kategorie normiert,

kumuliert ..............................................................................................................................97

Tabelle 15: Aufwand aller Aktivitäten je Projektwoche, in Stunden .......................................99

Tabelle 16: Aufwand aller Aktivitäten je Projektwoche, in Stunden, je Aktivität normiert ..... 101

Tabelle 17: Anzahl der Mitarbeiter pro Aktivität je Projektwoche ......................................... 105

Tabelle 18: Geleistete Stunden bezogen auf die Anzahl der Mitarbeiter pro Aktivität je

Projektwoche ...................................................................................................................... 106

Tabelle 19: Übersicht über Kategorien, Aktivitäten und Gesamtaufwand ............................ 110

Tabelle 20: Gesamtaufwand je Kategorie ........................................................................... 111

Tabelle 21: Aufteilung des Aufwands der Overhead-Aktivitäten .......................................... 112

____________________________________________________________________________________________________


161

Tabelle 22: Übersicht statistische Daten je Aktivität ............................................................ 124

Tabelle 23: Übersicht Gesamtaufwand und Bugs pro Mitarbeiter ....................................... 132

Tabelle 24: Übersichtsdaten Release 1.2.0 und Release 1.3.0........................................... 135

Tabelle 25: Gesamtaufwand pro Projektphase, pro Aktivität und nach Releases ............... 137

Tabelle 26: Gesamtaufwand pro Aktivität, nach Releases und Gesamt .............................. 138

Tabelle 27: Gesamtaufwand pro Aktivität je Systemkomponente ....................................... 140

Tabelle 28: Statistische Kenngrößen je Aktivität ................................................................. 146

Tabelle 29: Statistische Kenngrößen je Aktivitätsgruppe .................................................... 147

Tabelle 30: Statistische Kenngrößen je Projektphase ......................................................... 148

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

[DUS] 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

____________________________________________________________________________________________________


162

http://www.softwarequalitymethods.com/papers/star99%20model%20paper.pd

f, zuletzt geprüft am 07.11.2013.

[KRO] Kropfitsch, Dietmar; Vigenschow, Uwe (2003): Das Fehlermodell:

Aufwandsschätzung und Planung von Tests; Objektspektrum 06/2003

[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

[SEI] Seidl, Richard; Baumgartner, Manfred; Bucsics, Thomas (2012): Basiswissen

Testautomatisierung. 1. Aufl. Heidelberg: dpunkt-Verlag

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

[SPI] 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-Verlag

[WIE] Wiemann, Matthias; Quantifizierung und Reduktion von testinduzierten

Qualitätskosten; Dissertation, Technische Universität München, 2010.

Verifikation bedienergeführter IT-Systeme unter ... · Verifikation bedienergeführter IT-Systeme...

Documents

Transcript of Verifikation bedienergeführter IT-Systeme unter ... · Verifikation bedienergeführter IT-Systeme...