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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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?
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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“:
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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).
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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).
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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).
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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).
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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?
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
𝑇𝑇 = 𝐸(𝑇𝑇ℎ. 𝑇.𝑍𝑇𝐸𝑇𝑇𝐸𝑇𝑇𝑇𝑇𝑍𝑇𝑇,𝑇𝑇𝐴. 𝑆𝑇𝑇𝐸𝑆ℎ𝑇𝑇,𝐸𝑇𝐸.𝑇.𝐸𝑇𝑇𝑇. , 𝑆)
𝑇𝑇 = 𝐸(𝑇𝑇ℎ. 𝑇.𝑍𝑇𝐸𝑇𝑇𝐸𝑇𝑇𝑇𝑇𝑍𝑇𝑇,𝑇𝑇𝐴. 𝑆𝑇𝑇𝐸𝑆ℎ𝑇𝑇,𝐸𝑇𝐸.𝑇.𝐸𝑇𝑇𝑇. ,𝑇𝑇𝐴.𝑅𝑇𝐸𝑇𝐸𝑇𝑇𝑇, 𝑆
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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:
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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?
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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 ?
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
77
d) Stundensumme je Mitarbeiter und Systemkomponente (auf Summenblatt II)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
79
Abbildung 14: Datenmodell zur Erfassung der Projektdaten
Mitarbeiter Aktivität
Aufwand
KW
1 1
n Stunden
n
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
81
Abbildung 16: Excel-Tabelle zur Selbsterfassung der Arbeitszeit je Aktivität
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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%
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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 %
Administration, Maintenance, HW 51,5 1,55 %
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 %
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
87
5.3.4. Verteilung Overhead
Bezeichnung Stunden Anteil %
Administration, Maintenance, HW 51,5 11,7 %
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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%
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
%
9300 Supportmanagement
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
9300 Supportmanagement
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
9300 Supportmanagement
2 1,3
Tabelle 18: Geleistete Stunden bezogen auf die Anzahl der Mitarbeiter pro Aktivität je Projektwoche
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
Produktgrösse: 1 – 10 Personenjahre Entwicklungsaufwand
Beginn Entwicklung: ??
6.2. Systematik
6.2.1. Datenerfassung
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
ausgeführt. Darstellung und Pivotierung erfolgte dann in Excel.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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. Übersichtsdaten
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"
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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. Zeitlicher Verlauf
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
113
6.4.2. Gesamtaufwand
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
114
Abbildung 35: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden)
Abbildung 36: Zeitlicher Verlauf der Stunden je Aufwandskategorie (in Stunden), kumuliert
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
115
Abbildung 37: Zeitlicher Verlauf der Stunden je Aufwandskategorie, kumuliert
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
116
6.4.3.1. Systemtest
Abbildung 38: Aufwand der Aktivitäten, in Stunden pro Tag
Abbildung 39: Aufwand der Aktivitäten, Stunden kumuliert
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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…
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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:
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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):
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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:
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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:
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
131
Abbildung 58: Zusammenhang Bug Einträge und Projektstundenerfassung
Abbildung 59: Zusammenhang zwischen Anzahl Bugs (y-Achse) und Stundensumme pro Mitarbeiter (x-Achse)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
Unternehmensgrösse: 100 – 1.000 MA
Produktgrösse: 1 – 10 Personenjahre Entwicklungsaufwand
Beginn Entwicklung: ??
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
134
7.2. Systematik
7.2.1. Datenerfassung
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
ausgeführt. Darstellung und Pivotierung erfolgte dann in Excel.
Es wurden zwei Releases der betrachteten Software vermessen und analysiert:
• Release 1.2.0 (kurz: Rel12)
• Release 1.3.0 (kurz: Rel13)
7.3. Übersichtsdaten
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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 Preparation 3200 76,7 40,6 36,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 Analyzation 3500 227,3 153,3 74,1
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 Preparation 4200 7,3 1,1 6,2
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 Analyzation 4500 226,3 42,3 184,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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
7.3.4.1. Beschreibung
Each test phase contained several activities within this phase:
x100: Test Planning
x200: Test Preparation
x300: Test Specification
x400: Test Execution
Rel13
Rel12
Gesamt
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
139
Abbildung 62: Anteil der Aktivitäten am Gesamtaufwand, je Release und Gesamt
7.3.6. Verteilung der Stunden auf Systemkomponenten
7.3.6.1. Beschreibung
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
7.4. Zeitlicher Verlauf
7.4.1. Gesamtaufwand
Abbildung 63: Gesamtaufwand in Stunden pro Woche und kumuliert (y-Achse rechts)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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 ?
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
142
7.4.3. Testphasen
7.4.3.1. Gesamtaufwand Stunden
Abbildung 65: Aufwand der Testphasen, Stunden kumuliert, je Testphase normiert
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
144
7.4.4. Aktivitäten
7.4.4.1. Gesamtaufwand hours
Abbildung 68: Aufwand der Aktivitäten, Stunden kumuliert, je Aktivität normiert
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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 Preparation 3200 39 76,7 1,97 0,3 8,4
Test Specification 3300 96 308,7 3,22 0,5 9,1
Test Execution 3400 135 469,3 3,48 0,4 8,9
Test Analyzation 3500 87 227,3 2,61 0,5 5,6
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 Preparation 4200 6 7,3 1,21 1,0 2,2
Test Specification 4300 52 141,6 2,72 1,0 9,8
Test Execution 4400 118 489,6 4,15 1,0 9,0
Test Analyzation 4500 89 226,3 2,54 1,0 5,7
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
Anzahl Summe Mittelwert Min Max
Overhead 151 284,1 1,88 0,2 9,2
Planning (x100) 8 17,1 2,14 0,3 8,8
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
Anzahl Summe Mittelwert Min Max
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
Unternehmensgrösse: 100 – 1.000 MA
Produktgrösse: 100 – 1.000 Personenjahre Entwicklungsaufwand
Beginn Entwicklung: ??
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
151
Abbildung 74: Anteil der Kategorien über alle Projekte
8.4.2. Auswertung Kategorien
Abbildung 75: Anteil Kategorien über alle Projekte
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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)
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
153
Abbildung 78: Relative Abweichung [%] Ist-Plan im Verhältnis zur Projektgröße [h]. Logarithmische X-Achse.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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
____________________________________________________________________________________________________
IWT Wirtschaft und Technik GmbH, c/o DHBW RV, Fallenbrunnen 2, 88045 Friedrichshafen www.iwt-wirtschaft-und-technik.de
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.
Top Related