Hochschule Wismar
Fakultät für Wirtschaftswissenschaften
Master - Thesis
Konzeption eines integrierten Testcenters
Abschlussarbeit zur Erlangung des Grades eines
Master of Science (M. Sc.)
in Wirtschaftsinformatik der Hochschule Wismar
eingereicht von: Martin Möller
geboren am 05. Juli 1986 in Wismar Studiengang Wirtschaftsinformatik
Matrikelnummer: 108507
Erstgutachter: Prof. Dr. Jürgen Cleve
Zweitgutachter: Prof. Dr. Dr. Herbert Neunteufel
Wismar, den 11. Juli 2012
„Grundsatz zum Verständnis der Softwareindustrie:
Alle großen Softwareentwicklungen wurden aufgrund gravierender Programmfehler verwirklicht.
Erste Folgerung:
Jedes Programm hat Fehler.
Zweite Folgerung:
Jedes Programm hat immer einen Fehler mehr.
Dritte Folgerung:
Die Beseitigung eines Fehlers ruft mindestens zwei neue hervor.“
(Murphys Gesetze zit. nach [Gra01, S. 56])
Inhaltsverzeichnis
Inhaltsverzeichnis IV
Abkürzungsverzeichnis VI
Abbildungsverzeichnis VIII
Tabellenverzeichnis IX
1. Einleitung 1
1.1. Motivation . . . 1
1.2. Zielsetzung und Abgrenzung . . . 2
1.3. Aufbau der Arbeit . . . 2
2. Grundlagen 5 2.1. Der Fehlerbegriff . . . 5
2.2. Der Softwaretest . . . 5
2.2.1. Das allgemeine V-Modell . . . 6
2.2.2. Statische Analyse und dynamischer Test . . . 7
2.2.3. Risikoorientiertes Testen . . . 8
2.2.4. Relevante Normen und Standards . . . 8
2.3. IT Infrastructure Library . . . 9
2.3.1. ITIL und der Softwaretest . . . 9
2.3.2. Schnittstellen zu anderen ITIL – Prozessen . . . 11
2.4. Zusammenfassung . . . 12
3. Ist-Zustand 15 3.1. Die DVZ M-V GmbH . . . 15
3.1.1. Geschichtlicher Abriss . . . 15
3.1.2. Aufgabenspektrum und Kernkompetenzen . . . 15
3.1.3. Das Projekt EL.MA . . . 16
3.2. Einschätzung des IST-Zustandes . . . 18
3.2.1. Testorganisation . . . 18
3.2.2. Testprozess . . . 18
3.2.3. Analyse des Testverhaltens . . . 18
3.2.4. Bewertung des Ist-Zustandes . . . 21
3.3. Zusammenfassung . . . 22
4. Soll-Konzept 23 4.1. Dem Ganzen einen Rahmen geben . . . 23
4.2. Testorganisation . . . 24
4.3. Prozesse des TQC . . . 26
4.3.1. Führungsprozesse . . . 26
4.3.2. Kernprozesse . . . 28
4.3.3. Supportprozesse . . . 38
4.4. Risikobetrachtung . . . 43
4.4.1. Risikokontext . . . 44
4.4.2. Risikoidentifikation . . . 44
4.4.3. Risikoanalyse . . . 47
4.4.4. Risikosteuerung . . . 48
4.4.5. Risikoüberwachung . . . 50
4.5. Service-Katalog . . . 50
4.5.1. Die Struktur des Service-Katalogs . . . 51
4.5.2. Business Service-Katalog . . . 51
4.5.3. Technischer Service-Katalog . . . 55
4.6. Metriken . . . 57
4.6.1. Auswahl . . . 57
4.6.2. Dokumentation . . . 60
4.6.3. Kategorien an Metriken . . . 62
4.7. Voraussetzung des Betriebes . . . 63
4.7.1. Personal . . . 64
4.7.2. Organisation . . . 65
4.8. Grobe Kostenschätzung . . . 71
4.8.1. Einführung . . . 71
4.8.2. Das Kostenmodell . . . 71
4.8.3. Kosten des Testcenters . . . 71
4.9. Zusammenfassung . . . 77
5. Zusammenfassung und Ausblick 79 5.1. Zusammenfassung . . . 79
5.2. Ausblick . . . 80
5.2.1. Das Konzept . . . 80
5.2.2. Technische Untersetzung . . . 80
5.2.3. Testen in der Zukunft der DVZ M-V GmbH . . . 81
Stichwortverzeichnis 86 Literaturverzeichnis 87 Ehrenwörtliche Erklärung 94 A. Ergebnisse der Umfrage iii B. Prozessmodelle ix B.1. Führungsprozesse . . . ix
B.2. Kernprozesse . . . x
B.2.1. Testmanagementprozesse . . . x
B.2.2. Dynamischer Testprozess . . . xxi
B.3. Supportprozesse . . . xxxi
B.3.1. Personalmangement . . . xxxi
B.3.2. Skillmanagement . . . xxxiv
C. Anlagen zum Beispielprojekt EL.MA xxxvii
D. Glossar xliii
Abkürzungsverzeichnis
BDSG Bundesdatenschutzgesetz
BPMN Business Process Model and Notation
BSI Bundesamt für Sicherheit in der Informationstechnik
CMS Configuration Management System
CSF Critical Success Factors
DIS Draft International Standard
DM Deutsche Mark
DOMEA® Dokumentenmanagement und elektronische Archivierung im IT-gestützten Geschäftsgang
DVZ M-V GmbH Datenverarbeitungszentrum Mecklenburg-Vorpommern GmbH EL.MA Elektronisches Magazin
FCM Faktor-Kriterien-Metriken
GmbH Gesellschaft mit beschränkter Haftung
GQM Goal-Question-Metric
HRMF Human Ressource Management Framework
i.A. in Auflösung
IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers ISO International Organization for Standardization ISTQB International Software Testing Qualifications Board
IT Information Technology
ITIL Information Technology Infrastructure Library
JTC1 Joint Technical Committee 1
LoC Lines of Code
OGC Office of Government Commerce
ProdHaftG Produkthaftungsgesetz
PStG Personenstandsgesetz
PT Personentag
RFC Request for Change
RPC Remote Procedure Call
SC7 Subcommittee 7
SigG Signaturgesetz
SMART spezifisch, messbar, akzeptiert, realistisch, terminiert
STD Standard
TCO Total Cost of Ownership
TMMi® Test Maturity Model integration
TPI Test Performance Indikator
TQC Test- und Qualitätscenter
TR Technische Richtlinie
TR-ESOR Technische Richtlinie zur Beweiswerterhaltung kryptographisch signier- ter Dokumente
UML Unified Modeling Language
UMTS Universal Mobile Telecommunications System
V2 Version 2
V3 Version 3
VE Volkseigen
VEB Volkseigener Betrieb
VW Volkswagen
W-LAN Wireless Lokal Area Network
WG26 Working Group 26
XML Extensible Markup Language
Abbildungsverzeichnis
1.1. Aufbau der Arbeit . . . 3
2.1. Allgemeines V-Modell . . . 6
2.2. ITIL Lifecycle . . . 10
2.3. Prozess Service Validation and Testing . . . 11
2.4. Das Kapitel Grundlagen in der Struktur der Arbeit . . . 13
3.1. Einordnung von TR-ESOR in die Gesamtarchitektur . . . 17
3.2. Architektur der Software EL.MA . . . 17
3.3. Das Kapitel Ist-Zustand in der Struktur der Arbeit . . . 22
4.1. Der organisatorische Rahmen des Test- und Qualitätscenters . . . 23
4.2. Führungs- und Kernprozesse des TQCs . . . 26
4.3. Überblick der Führungsprozesse . . . 27
4.4. Top-Level-Prozess des Test- und Qualitätscenters . . . 29
4.5. Die Supportprozesse im Überblick . . . 38
4.6. Der Risikoprozess nach Ahrendts . . . 43
4.7. Kategorisierung von Risiken . . . 44
4.8. Beispiele für identifizierte Risiken für das Projekt EL.MA . . . 45
4.9. Risikomatrix mit benannten Quadranten . . . 48
4.10. Struktur des Servicekatalogs nach ITIL . . . 51
4.11. Betrachtete Prozesse des Business Service-Katalogs für das TQC . . . 51
4.12. Business Service-Katalog für das TQC . . . 53
4.13. Service „Testkonzept erstellen“ im Business Service-Katalog . . . 54
4.14. Technischer Service-Katalog für das TQC . . . 56
4.15. Sub-Service „Äquivalenzklassenbildung“ im technischen Service-Katalog . . . 58
4.16. Der Metriken-Auswahlprozess im Überblick . . . 59
4.17. Voraussetzungsbeziehungen zur Metriken-Überprüfung . . . 62
4.18. Das magische Dreieck . . . 65
4.19. Dreistufiges Vorgehensmodell der DVZ M-V GmbH . . . 68
4.20. Das Kapitel Soll-Konzept in der Struktur der Arbeit . . . 78
5.1. Das Kapitel Zusammenfassung in der Struktur der Arbeit . . . 80
B.1. Der Prozess „Testspezifikationen erstellen“ . . . ix
B.2. Der Prozess „Gebrauch überwachen und kontrollieren“ . . . ix
B.3. Der Prozess „Spezifikationen ändern“ . . . x
B.4. Der Prozess „Test planen“ . . . x
B.5. Der Sub-Prozess „Kontext verstehen“ . . . xi
B.6. Der Sub-Prozess „Entwicklung des Testkonzeptes organisieren“ . . . xi
B.7. Der Sub-Prozess „Testrahmen abgrenzen“ . . . xii
B.8. Der Sub-Prozess „Risiken identifizieren und analysieren“ . . . xiii
B.9. Der Sub-Prozess „Risikomaßnahmen ermitteln“ . . . xiv
B.10.Der Sub-Prozess „Teststrategie erstellen“ . . . xiv
B.11.Der Sub-Prozess „Personal- und Zeitplanung bestimmen“ . . . xv
B.12.Der Sub-Prozess „Testkonzept dokumentieren“ . . . xvi
B.13.Der Sub-Prozess „Konsens zum Testkonzept gewinnen“ . . . xvi
B.14.Der Sub-Prozess „Testkonzept kommunizieren & verfügbar machen“ . . . xvi
B.15.Der Prozess „Test überwachen und steuern“ . . . xvii
B.16.Der Sub-Prozess „Monitoring einrichten“ . . . xvii
B.17.Der Sub-sub-Prozess „Prozess überwachen“ . . . xvii
B.18.Der Sub-sub-Prozess „Prozess steuern“ . . . xviii
B.19.Der Sub-sub-Prozess „Monitoring berichten“ . . . xviii
B.20.Der Prozess „Testabschluss“ . . . xix
B.21.Der Prozess „Testbestand archivieren“ . . . xix
B.22.Der Prozess „Lessons Learned durchführen“ . . . xix
B.23.Der Prozess „Testabschlussbericht erstellen“ . . . xx
B.24.Der Prozess „Test designen & Implementieren“ . . . xxi
B.25.Der Prozess „Funktionsgruppen identifizieren“ . . . xxii
B.26.Der Prozess „Testbedingungen ableiten“ . . . xxiii
B.27.Der Sub-Prozess „Testüberdeckungselemente ableiten“ . . . xxiii
B.28.Der Sub-Prozess „Testfälle ableiten“ . . . xxiii
B.29.Der Sub-Prozess „Testgruppen zusammenstellen“ . . . xxiv
B.30.Der Sub-Prozess „Testablauf erstellen“ . . . xxv
B.31.Der Prozess „Testumgebung vorbereiten“ . . . xxvi
B.32.Der Prozess „Testumgebung installieren“ . . . xxvi
B.33.Der Sub- Prozess „Testumgebung bereitstellen“ . . . xxvii
B.34.Der Sub- Prozess „Testumgebung warten“ . . . xxviii
B.35.Der Prozess „Test durchführen“ . . . xxviii
B.36.Der Sub-Prozess „Test durchführen“ . . . xxviii
B.37.Der Sub-Prozess „Testergebnisse vergleichen“ . . . xxix
B.38.Der Prozess „Testendebericht erstellen“ . . . xxix
B.39.Der Sub-Prozess „Testergebnisse analysieren“ . . . xxx
B.40.Der Prozess „Testfunktionen identifizieren“ . . . xxxi
B.41.Der Prozess „Stellenbeschreibungen erstellen“ . . . xxxii
B.42.Der Prozess „Testfunktionen besetzen“ . . . xxxii
B.43.Der Prozess „Testkarrierewege einführen“ . . . xxxiii
B.44.Der Prozess „Persönliche Entwicklungspläne entwickeln“ . . . xxxiii
B.45.Der Prozess „Strategischen Testschulungsbedarf entwickeln“ . . . xxxiv
B.46.Der Prozess „Testschulungsbedarf ausrichten“ . . . xxxiv
B.47.Der Prozess „Schulungskonzept erstellen“ . . . xxxv
B.48.Der Prozess „Testschulungsmöglichkeit etablieren“ . . . xxxv
B.49.Der Prozess „Schulung durchführen“ . . . xxxv
B.50.Der Prozess „Schulungsbelege erstellen“ . . . xxxvi
B.51.Der Prozess „Schulungseffektivität beurteilen“ . . . xxxvi
Tabellenverzeichnis
2.1. Relevante Normen und Standards für den Softwaretest . . . 9
4.1. Vor- und Nachteile der möglichen Testorganisationen . . . 25
4.2. Testrollen im Überblick . . . 39
4.3. Überblick über Risikoidentifikationstechniken und –hilfsmittel . . . 45
4.4. Merkmale der Risikoschablone . . . 46
4.5. Risikoklassen der Schadenshöhe für Programme . . . 47
4.6. Risikoklassen der Eintrittswahrscheinlichkeit . . . 48
4.7. Template des Business Service-Katalogs des TQCs . . . 53
4.8. Template des technischen Service-Katalogs des TQCs . . . 57
4.9. SMART-Kriterien . . . 60
4.10. Vorlage zur Kennzahlendefinition . . . 61
4.11. Hard- und Softwarekostenpositionen des TQCs . . . 72
4.12. Kostenpositionen im Betrieb des TQCs . . . 74
4.13. Kostenpositionen in der Verwaltung des TQCs . . . 76
4.14. Summe der Kostenpositionen des TQCs . . . 77
C.1. Risikoschablone am Beispiel EL.MA . . . xxxvii
C.2. Beispielhafte Ziele des Projektes EL.MA . . . xxxviii
C.3. Fragenauswahl zu den formulierten Zielen . . . xxxix C.4. Mögliche Metriken für das Projekt EL.MA . . . xl C.5. Kennzahlendefinition für das Projekt EL.MA . . . xli
1. Einleitung
1.1. Motivation
Es ist noch gar nicht so lange her, da stand in den Grundlagen-Lehrbüchern zum Studien- gang Wirtschaftsinformatik noch folgender Satz zum Thema Softwaretest: „Testen ist ein analytisches Verfahren, dasnach der Programmierung beginnt“ [Sta91, S. 283]. Jetzt, 21 Jah- re später, findet man in der Literatur diese Einordnung des Testprozesses nicht mehr. Viel eher trifft man auf Aussagen wie diese: „Die Planung einer so umfangreichen Aufgabe wie des Testens soll so früh wie möglich, am besten gleich zu Anfang des Softwareentwick- lungsprojekts, beginnen“ [Spi08a, S. 12]. Wie kam es, dass das Testen so priorisiert und die zeitliche Einordnung an den Beginn des Entwicklungsprozesses verschoben wurde?
Schon Stahlknecht schrieb dazu: „Solange Programme geschrieben und getestet werden, gibt es intensive Bemühungen sowohl von wissenschaftlicher Seite als auch in der DV-Praxis, den Testprozeß [sic!] zu systematisieren und effektiver zu gestalten“ [Sta91, S. 284]. Demnach verändern sich die Softwaretestprozesse stetig, um immer bessere Ergebnisse zu erzielen.
Darüber hinaus stellt der Faktor Komplexität zunehmend eine gewichtige Herausforderung in der Softwareindustrie dar und beschleunigt die Veränderung des Testprozesses (vgl. [Hof08, S. 3 ff]). Da sich die Informations- und Kommunikationstechnik in den letzten Jahrzehnten so sehr im Privatleben der Menschen etabliert hat und durch das Internet mit dessen Mög- lichkeiten noch einen „kräftigen Schub“ bekam, integriert sich die digitale Welt vermehrt im alltäglichen Leben (vgl. [Hof08, S. 1]). Integration heißt jedoch nicht nur Einbindung eines Objektes in ein System. Es heißt auch Kommunikation zu bestehenden Systemen.
Wer kommt denn heute noch ohne ein E-Mail-Programm mit integriertem Kalender und Aufgabenliste oder ohne ein Handy zurecht, mit dem man nicht nur telefonieren, sondern auch Nachrichten schreiben, per W-LAN oder UMTS im Internet surfen oder einfach seine Musik hören kann? Die Verbindung verschiedenster Aufgaben in einem Gerät oder durch eine Software wird stetig komplexer und macht Veränderungen in der Entwicklung solcher Systeme notwendig.
Das heißt aber auch, dass in der Entwicklungsphase solcher Produkte auf die jeweilige Kom- plexität eingegangen werden muss. Waren früher an einem System wenige Programmierer beteiligt, die das notwendige Wissen über das Produkt vereinten, so sind es heute viele ver- schiedene Entwicklungs-Teams, auf die sich das Wissen über das Produkt verteilt (vgl. [Hof08, S. 5]). Nicht jeder kann noch alles über die Umsetzung seines Produktes wissen, doch Unwis- senheit über komplexe Systeme macht das Auftreten von Fehlhandlungen wahrscheinlicher. Je komplexer somit die Systeme und je größer die Entwicklungsprojekte werden, je genauer muss der Softwaretest strukturiert werden, um den Großteil an wahrscheinlichen Fehlerzuständen, deren Anzahl stetig steigt, zu finden.
Da Software-Projekte jedoch unter ständigem Zeitmangel leiden, ist es nicht effektiv, einen optimalen Testprozess ganz ans Ende des Entwicklungsprozesses „zu verbannen“. Schon in den Anfangsphasen des Projektes muss die Planung der späteren Tests beginnen, um den Zeit- raum der Testdurchführung effizient ausnutzen zu können. Zudem muss das Testen schon von
Beginn an ein wichtiger Bestandteil des Softwareentwicklungsprozesses sein, denn schwerwie- gende Fehler werden nicht nur in der Implementierungsphase der Software gemacht, sondern auch schon in der Anforderungsanalyse. Und gerade diese frühen Defizite können die teu- ren und aufwendigen sein, da spätere Entwicklungen darauf aufbauen und viele Folgefehler verursacht werden (vgl. [SL04, S. 155 f]).
Zusammengefasst besteht die Aufgabe der Wirtschaftsinformatik darin, dem späteren Pro- dukt zu einer höchst möglichen Qualität zu verhelfen. Dabei müssen der effektive Einsatz von beschränkten Ressourcen, mithilfe eines systematischen Testprozesses, und die dazugehörigen Testverfahren berücksichtigt werden.
1.2. Zielsetzung und Abgrenzung
Die vorliegende Arbeit basiert auf der Einführung eines Testcenters innerhalb der DVZ Da- tenverarbeitungszentrum Mecklenburg-Vorpommern GmbH, kurz DVZ M-V GmbH, und soll in Form eines Konzeptes einen Beitrag zu der Systematisierung des Softwaretestprozesses leisten. Das Konzept zeigt, wie der Softwaretestprozess in bestehende Strukturen eingeglie- dert werden kann. Dem Testprozess wird dafür eine Organisationsform zugeordnet, die im Folgenden als Test- und Qualitätscenter (TQC) bezeichnet wird.
Den organisatorischen Rahmen bildet hierbei die IT Infrastructure Library (ITIL), wie sie auch in der DVZ M-V GmbH eingeführt ist und in die das Test- und Qualitätscenter inte- griert werden soll. Dafür wird, basierend auf den aktuell freigegebenen Normen-Entwürfen der ISO/IEC DIS 29119, der Softwaretestprozess abgebildet und durch Schulungsinhalte des International Software Testing Qualifications Board (ISTQB) sowie durch Inhalte des Reife- gradmodells Test Maturity Model integration (TMMi®) erweitert. Ausgewählte Prozesse, die besonders wichtig für den Testprozess sind, werden dabei genauer betrachtet, in Bezug auf die relevante Literatur erläutert und mithilfe eines Beispiels verdeutlicht. Weiterhin werden Prozesse dargestellt, die den Softwaretest unterstützen, jedoch nicht direkt in diesen einge- gliedert sind. Abschließend erfolgt eine Kostenschätzung, die sich auf die Einführung eines Testcenters bezieht.
Die konkrete Umsetzung des Konzeptes in der Form, dass z.B. gezielt Testverfahren beschrie- ben und evaluiert werden, wird nicht Teil dieser Arbeit sein. Auch wird nicht die grund- sätzliche Herangehensweise zur Erstellung eines Konzeptes berücksichtigt, da das erarbeitete Konzept in einem praktischen Projekt erstellt wurde und hier nicht abgewandelt werden soll.
1.3. Aufbau der Arbeit
Die Arbeit untergliedert sich in fünf Kapitel. In dem ersten Kapitel, der Einführung, wird die Bedeutung der Entwicklung der Testprozesse dargestellt und die Zielsetzung sowie die Abgrenzung der Arbeit vorstellt.
Das zweite Kapitel erläutert die Grundlagen bzgl. des Softwaretests und einzelner Themenbe- reiche, die innerhalb der Arbeit aufgegriffen werden. Zudem wird das Konzept ITIL erläutert und der Bezug zum Softwaretest dargestellt.
Kapitel drei gibt einen Überblick über die DVZ M-V GmbH und stellt die aktuelle Situation des Testens innerhalb des Unternehmens vor.
1.3. Aufbau der Arbeit
Abbildung 1.1.: Aufbau der Arbeit
Auf der Basis der aktuellen Situation wird in dem vierten Kapitel ein Konzept erstellt, das zunächst die passende Organisationsform für den Softwaretest für die DVZ M-V GmbH iden- tifiziert. Folgend werden Prozesse vorgestellt, die aus den relevanten Normen und Standards aus dem zweiten Kapitel zusammengesetzt und in der grafischen Spezifikationssprache Busi- ness Process Model and Notation 2.0 (BPMN) modelliert wurden. Dieser prozessorientierte Ansatz wird durch Verfahren für das risikoorientierte Testen erweitert. Für die Organisation und die Auswahl der jeweiligen Testarten bzw. Testentwurfsverfahren der einzelnen Entwick- lungsprojekte ist ein Service-Katalog auf Basis von ITIL erstellt worden. Zur Messung des Testfortschrittes und der Effizienz des Testens wird unter dem Abschnitt „Metriken“ eine Methode vorgestellt, die die Auswahl und die Dokumentation von passenden Kennzahlen darstellt und Voraussetzungen, die für die Einführung der Testorganisation wichtig erschei- nen, werden unter dem Abschnitt „Voraussetzungen des Betriebes“ angesprochen. Den Ab- schluss des Kapitels bildet letztendlich eine grobe Kostenschätzung für die Implementierung des Testcenters.
Das fünfte Kapitel fasst das vorangegangene Konzept zusammen und gibt einen Ausblick über die Weiterentwicklung des Konzeptes sowie die zukünftige Auswahl an technischen Un- tersetzungen.
Zur Veranschaulichung kann der Aufbau der Arbeit als ein Haus dargestellt werden, dessen Dach die „Einleitung“ darstellt, da sie die globalen Anforderungen an die Arbeit stellt. Ge- tragen wird das Dach durch die beiden Säulen „Grundlagen“ und dem „Ist-Zustand“, die sich in der Umsetzung voneinander unterscheiden. Diese beiden außenstehenden Säulen sol- len durch eine innere Säule, dem „Soll-Konzept“ ersetzt werden, das einen praxisorientierten Zustand erbringen soll, welches in der DVZ M-V GmbH eingesetzt werden kann und den wissenschaftlichen Anforderungen entsprechen muss. Den Abschluss bildet das Fundament, mit der Zusammenfassung der Arbeit und dem Ausblick auf die Entwicklungen des Testens in der DVZ M-V GmbH. Dieser Abschnitt wurde als Fundament gewählt, da an einem Haus, ob alt oder neu, fast immer nach einer Veränderung das Fundament erhalten bleibt. Dieses zeigt dem Betrachter häufig, wie sich das Gebäude darauf im Laufe der Zeit verändert hat (Zusammenfassung) und was zukünftig an Änderungen möglich ist, die das Fundament tragen kann (Ausblick).
Das Haus wird dem Leser durch den Verlauf der Arbeit begleiten, um ihm zu zeigen, wo er sich gerade befindet. Nach jedem Kapitel steht dafür eine Zusammenfassung bereit, in der ein Ausblick auf das nächste Kapitel oder weiteren Anforderungen dargestellt werden.
2. Grundlagen
2.1. Der Fehlerbegriff
Bevor auf den Softwaretest eingegangen wird, soll zunächst erläutert werden, wie der Begriff
„Fehler“ definiert ist und wie sich diese auf eine Software auswirken.
Der im allgemeinen Sprachgebrauch geführte Begriff „Fehler“ wird in Bezug auf den Softwa- retest von der ISTQB als „Fehlerzustand“ bezeichnet und wie folgt definiert:„Defekt [. . . ] in einer Komponente oder einem System, der eine geforderte Funktion des Produkts beeinträch- tigen kann [. . . ]“ [HH10, S. 20]. Diese Beeinträchtigung der geforderten Funktion kann sich unterschiedlich auswirken.
Die meisten Fehlerzustände, die nach der Auslieferung einer Software noch in dem Produkt enthalten sind, werden sicherlich nie entdeckt und erzeugen keine großen Beeinträchtigungen des Systems. Ein Beispiel dafür ist die Übergabe von Parametern zwischen zwei Systemkom- ponenten, die insofern nicht abgesichert sind, dass eine Überprüfung und Fehlerbehandlung bei der Übergabe von falschen Werten nicht erfolgt. Ist eine Überprüfung schon in der Be- nutzereingabe implementiert, wird sich diese Schwachstelle wohl nie bemerkbar machen und folglich keinen Schaden herbeiführen. Auch ein Rechtschreibfehler ist ein Beispiel eines Feh- lerzustandes und wird dem System wenig schaden, dieser könnte höchstens bei einem sehr korrekten Benutzer1 eine spöttische Bemerkung und ein Kopfschütteln verursachen.
Es gibt jedoch auch Fehlerzustände in Systemen, die den täglichen Geschäftsbetrieb eines Unternehmens stark beeinflussen und sogar komplett stoppen können. Ein gutes Beispiel hierfür ist der Ausfall des Internets durch einen Programmdefekt in der Router-Software.
Hat ein Dienstleistungsunternehmen seine Steuerung und den Zugriff auf Datenbestände über ein SAP-System realisiert, welches in einem entfernten Rechenzentrum installiert ist, und benutzt darüber hinaus IP-Telefone, ist zu vermuten, dass das Unternehmen für die Zeit bis zur Fehlerbehebung nahezu handlungsunfähig ist. In diesem temporären Zustand entstehen riesige, ungeplante Leerlaufzeiten, monetäre Auswirkungen aufgrund von bspw. fehlenden, vertraglich festgelegten Serviceleistungen sowie Kundenunzufriedenheit, wenn die Firma bei Fragen telefonisch oder per E-Mail nicht erreichbar ist.
2.2. Der Softwaretest
Der Softwaretest ist ein Werkzeug zur Qualitätssicherung des Produktes im Entwicklungs- und Weiterentwicklungsstadium. Er hat zum Einen das Ziel, bestehende Fehlerzustände in Anwendungssystemen zu lokalisieren und diese vor der Auslieferung an den Kunden durch die Entwicklungsteams beseitigen zu lassen. Zum Anderen soll der Test auch den Qualitäts- nachweis erbringen, in dem die (fast) fertige Software mit den Anforderungen verglichen und auf Konformität geprüft wird (vgl. [Spi08b, S. 3]).
1 In dieser Arbeit wird für die sprachliche Ästhetik stets die männliche Form verwendet. Damit sind Frauen natürlich nicht ausgeschlossen.
Abbildung 2.1.: Allgemeines V-Modell
Ursprünglich erfolgte der Softwaretest nach der Implementierung der Anwendung durch die Entwicklungsteams und stand am Ende der Entwicklungsphase (vgl. [Sta91, S. 283]). Durch die zunehmende Komplexität der Softwareprodukte (vgl. [Hof08, S. 5]) stieg auch die Anzahl der Fehler in diesen Systemen. Es wurde notwendig, den Softwaretest insofern zu optimie- ren, dass er so früh wie möglich in der Entwicklungsphase beginnt. Man unterscheidet in dieser Betrachtung zwei grundsätzliche Ansätze von Teststrategien. Den präventiven Ansatz, bei dem der Softwaretest frühzeitig beginnt, und den reaktiven Ansatz, wo er am Ende der Entwicklung steht. Dies heißt jedoch nicht, dass die Ansätze starr sind und der eine oder der andere besser ist. Vielmehr vermischen sich die Ansätze je nach geplanten Verfahren, die zum Einsatz kommen sollen (vgl. [Spi08a, S. 74]). Grundsätzlich sollte der Gesamtprozess je- doch schon in den frühen Phasen des Softwareentwicklungsprojektes geplant und strukturiert werden.
2.2.1. Das allgemeine V-Modell
Ein einfaches, präventiv orientiertes Vorgehensmodell für Softwareentwicklungsprojekte stellt das allgemeine V-Modell dar. Dieses ist nach der Softwaretest-Umfrage 2011 das mit insge- samt 36,5% mit Abstand meist verwendete Phasenmodell in der Praxis (vgl. [HSVW11b, S. 55]). Es schreibt den einzelnen Projektphasen der Softwareentwicklung eine entsprechende Testphase zu.
Grundsätzlich werden dabei die folgenden vier Testphasen unterschieden. Der Komponenten- test, je nach Programmiersprache auch Unit- oder Klassentest genannt, ist ein programmco- deorientierter Test, der sich mit dem Aufdecken von Fehlerzuständen in den grundlegenden Elementen der Software beschäftigt. Der Integrationstest testet aufbauend auf dem Kom- ponententest die Integration und die korrekte Kommunikation der einzelnen Komponenten miteinander. Der Systemtest überprüft die Gesamtkonfiguration der Software, wie bspw. die Installation und das Performanceverhalten. Als letzte Testphase erfolgt der Abnahmetest, der häufig auch in Form eines Beta-Tests erfolgt und die Akzeptanz des Kunden gegenüber dem Produkt betrachtet (vgl. [Spi08b, S. 14]).
In der Praxis werden die einzelnen Testphasen nicht unbedingt sequenziell abgehandelt, wie es aus dem V-Modell hervorgehen mag. Es besteht durchaus die Möglichkeit, dass sich mehrere Testphasen z. T. überdecken (vgl. [Spi08b, S. 13]). Beispielsweise muss der Komponententest nicht für die gesamte Anwendung erfolgt sein, damit der Integrationstest beginnen kann.
2.2. Der Softwaretest Es ist in Abhängigkeit von der festgelegten Teststrategie möglich, dass schon fertiggestellte Komponenten nach dem jeweiligen eigenen Komponententest auf ihre Kommunikation zu anderen Komponenten getestet werden können. Dieses Vorgehen ist insofern relevant, als durch das direkt folgende Testen Zeit in Form von Leerlaufzeit eingespart werden kann.
Wichtig ist jedoch, dass diese frühen Integrationstests strukturiert geplant werden, in der Form, dass die Reihenfolge der zu fertigenden Komponenten festgelegt wird, um eine sinnvolle Integration überhaupt ermöglichen zu können (vgl. [SL04, S. 54 ff]).
2.2.2. Statische Analyse und dynamischer Test
Innerhalb der jeweiligen Testphase werden verschiedene Techniken eingesetzt, die z. B. zu der Ermittlung von Testfällen und deren Eingabedaten oder als direkt durchzuführende Testar- ten herangezogen werden. Diese Techniken werden grundlegend in statische Analysen oder dynamische Tests klassifiziert (vgl. [Lig09, S. 37 ff]).
Statische Analysen, auch statische Tests genannt, sind dabei Prüfverfahren, die nicht nur auf den Programmcode oder die Anwendung begrenzt sind. Sie können auch dafür genutzt werden, Dokumente, wie Spezifikationen und Entwürfe, auf ihre Tauglichkeit zu prüfen.Lig- gesmeyer definiert dafür die vier folgenden Merkmale der statischen Analyse (vgl. [Lig09, S. 43]):
• der Programmcode wird nicht ausgeführt,
• die Durchführung der Verfahren kann auch ohne automatisierte Hilfe erfolgen,
• Testfälle werden nicht erstellt,
• Korrektheit und Zuverlässigkeit der Software kann nicht vollständig garantiert werden.
Beispiele für statische Analysen sind Reviews von Dokumenten oder Compiler, die ohne die Ausführung des Programmcodes diesen auf fehlerhafte Programmierkonventionen überprü- fen. Der dynamische Test hingegen basiert, im Gegensatz zur statischen Analyse, auf der Ausführung des Programmcodes. Die Anwendung wird dabei bewusst ausgeführt und mit Daten versorgt, um das erwartete und tatsächliche Verhalten vergleichen zu können. Auch für den dynamischen Test definiertLiggesmeyer vier Merkmale (vgl. [Lig09, S. 39]):
• die kompilierte und ausgeführte Anwendung wird mit Eingaben bestückt,
• die Anwendung kann in einem realen Umfeld getestet werden,
• der dynamische Test ist stichprobenartig,
• die Korrektheit der Software kann durch diese Techniken nicht bewiesen werden.
Die dem dynamischen Test zugeordneten Testentwurfsverfahren, die zu der Erstellung der Testfälle dienen, lassen sich in zwei Kategorien einordnen: dem White-Box-Test und dem Black-Box-Test. Dabei unterscheiden sich diese beiden Kategorien insofern, als dass inner- halb des White-Box-Tests der Programmcode bekannt ist und dementsprechend auch genutzt wird, um Testfälle zu erstellen. Der Black-Box-Test kennt hingegen die innere Struktur der Anwendung nicht, sodass demzufolge die Testfälle nur aus der Anforderungsspezifikation her- geleitet werden können (vgl. [SL04, S. 96 ff]).
2.2.3. Risikoorientiertes Testen
Eine Anwendung kann nie als fehlerfrei deklariert werden. Grund dafür ist, dass Fehler- zustände in allen Teilen der Software existieren können. Diese werden aber z.T. nur unter bestimmten Kombinationen von Eingabewerten durch eine Fehlerwirkung sichtbar. Um nun eine Anwendung als fehlerfrei bezeichnen zu können, müsste diese ausgetestet werden. Das heißt, dass sämtliche Kombinationen von Interaktionen, positiven und negativen Eingabe- werten und unter Berücksichtigung sämtliche Randbedingungen getestet werden müssten, die innerhalb des Programmes möglich sind (vgl. [SL04, S. 12 f]). Dementsprechend würde das Austesten eines einfachen Taschenrechners einen Tester für mehrere Jahrzehnte, wenn nicht sogar bis an sein Lebensende, in Vollzeit beschäftigen können.
Es ist somit nicht möglich, eine Software in angemessener Zeit und mit begrenztem Bud- get auszutesten. Trotzdem müssen die Fehlerzustände gefunden werden, die in der späteren produktiven Umgebung der Anwendung einen hohen Schaden verursachen können, da der Hersteller für diesen aufkommen muss (siehe Abschnitt 2.2.4).
Um diese Probleme des Testens zu vermindern, kann das risikoorientierte Testen angewandt werden. Dieses basiert darauf, dass die Risiken eines Produktes identifiziert und gewichtet werden. Risiken sind dabei Faktoren, die zu späteren Zeitpunkten zu Problemen oder Schä- den führen können (vgl. [HH10, S. 42]). Der darauf aufbauende Softwaretest priorisiert sich in seiner Ausführung dementsprechend auf die Risiken, die eine hohe Gewichtung erhalten. Nied- rig gewichtete Risiken werden hingegen nicht intensiv oder gar nicht getestet (vgl. [Spi08a, S. 226 f] und [Dia04, S. 50 f]).
Das Ziel dieses Vorgehens ist es, in einer effizienten Art und Weise die kritischen Bestandteile der Software ausreichend zu testen, um das Risiko möglicher zukünftiger Schäden zu mini- mieren. Diese Konzentration auf z.B. einzelne Module bewirkt, dass im produktiven Einsatz die Geschäftsprozesse des Kunden sichergestellt sind.
2.2.4. Relevante Normen und Standards
Edsger Dijkstra sagte im Jahre 1972 auf einer Konferenz, dass der Softwaretest die Anwesen- heit von Fehlerzuständen in einer Anwendung demonstrieren, jedoch nicht die Abwesenheit dieser sicherstellen kann [Dij72, S. 20]. Diese Aussage trifft ein Problem aus der Praxis der Softwareindustrie. Denn Firmen müssen Schäden, die ihre Produkte verursachen, ersetzen bzw. dafür haften2. Das ProdHaftG räumt dem Hersteller jedoch Ausnahmen ein, bei denen diese Ersatzpflicht entfällt:
„(2) Die Ersatzpflicht des Herstellers ist ausgeschlossen, wenn [...]
2. nach den Umständen davon auszugehen ist, daß das Produkt den Fehler, der den Schaden verursacht hat, noch nicht hatte, als der Hersteller es in den Verkehr brachte, [...]
5. der Fehler nach dem Stand der Wissenschaft und Technik in dem Zeitpunkt, in dem der Hersteller das Produkt in den Verkehr brachte, nicht erkannt werden konnte.“ (§1 Absatz 2 ProdHaftG) Die Ersatzpflicht erfolgt demnach für die in der Softwareindustrie relevanten Möglichkeiten nur, wenn der Fehler bei der Auslieferung nicht in dem Produkt vorlag oder durch Verfahren, die nach dem aktuellen Stand der Technik agieren, nicht gefunden werden konnten (vgl.
[Lig09, S. 382]). Da eine Software niemals als fehlerfrei betrachtet werden kann, fällt somit der erste Haftungsausschluss aus der Betrachtung heraus. Die zweite Option stellt jedoch den Softwaretester vor die Frage, welches der jeweils „aktuelle Stand der Technik“ ist. Aktuell geltende Normen und Standards können dafür die passende Antwort geben.
2 Vgl. ProdHaftG §1 Absatz 1
2.3. IT Infrastructure Library Allerdings existieren für den Softwaretest mehrere Normen und Standards, die zu unterschied- lichen Zeiten erstellt wurden, für die unterschiedlichsten Aspekte innerhalb des Testprozesses relevant sind und wiederum andere Bereiche nicht berühren (vgl. [DZ11, S. 6]). Der Testmana- ger muss dabei abschätzen, welche Normen und Standards er für seine aktuelle Projektphase berücksichtigt und welche er vielleicht auch kombiniert. In der Tabelle 2.1 werden die auf den Softwaretest bezogenen, wichtigsten Normen und Standards aufgeführt.
Kürzel Bezeichnung
BS 7925 – 1 Glossary of Terms used in Software Testing BS 7925 – 2 Standard for Software Component Testing
DIN 66271 Software-Fehler und ihre Beurteilung durch Lieferanten und Kunden
IEEE STD 610.12 – 1990 Standard Glossary of Software Engineering Terminology IEEE STD 829 – 2008 Standard for Software and System Test Documentation IEEE STD 928.1 – 2005 Standard Dictionary of Measures of the Software
Aspects of Dependability
IEEE STD 1008 – 1987 Standard for Software Unit Testing
IEEE STD 1012 – 1998 Standard for Software Verification and Validation IEEE STD 1028 – 2008 Standard for Software Reviews and Audits IEEE STD 1044 – 2009 Standard Classification for Software Anomalies IEEE STD 1044.1 – 1995 Guide to Classification for Software Anomalies
IEEE STD 1061 – 1998 Standard for a Software Quality Metrics Methodology Tabelle 2.1.: Relevante Normen und Standards für den Softwaretest
Derzeitig arbeitet die Working Group 26 (WG26) der ISO/IEC JTC1/SC7 namens „Softwa- re and Systems Engineering committee“ an einer Norm, die einen ganzheitlichen Ansatz zur Betrachtung des Softwaretests bieten und einen Großteil der bestehenden Standards erset- zen soll. Diese ISO/IEC 29119, die sich zurzeit noch im Entwurfsstadium befindet, wird die Bereiche der Terminologie, des Testprozesses, der Testdokumentation und der Testtechniken abdecken (vgl. [DZ11, S. 6 f]). Aktuell ist noch kein Teil der ISO/IEC 29119 freigegeben, jedoch wurden bereits die Teile Testprozess (ISO/IEC DIS 29119-2) und Testdokumentation (ISO/IEC DIS 29119-3) als Normentwürfe veröffentlicht, sodass keine gravierenden Änderun- gen mehr an diesen beiden Teilen zu erwarten sind.
2.3. IT Infrastructure Library
2.3.1. ITIL und der Softwaretest
Die IT Infrastructure Library, kurz ITIL genannt, ist eine Sammlung von Best-Practise zur service-orientierten Strukturierung von IT-Organisationen. Sie wird von dem Office of Go- vernment Commerce (OGC), einer britischen Behörde, weiterentwickelt und ist mittlerweile in der dritten Version verfügbar. ITIL besteht aus fünf Kernpublikationen, die gemeinschaft- lich einen Lebenszyklus, den Service Lifecycle, bilden, in deren Betrachtung als Service be- zeichnete Dienstleistungen stehen. Diese Services müssen jedoch nicht nur Dienstleistungen darstellen. Sie können auch mit Software in Verbindung gebracht werden.
Abbildung 2.2.: ITIL Lifecycle
ITIL beginnt dabei mit der Servicestrategie (Service Strategy), in deren Rahmen die Strategie für die Dienstleistungen und das IT-Management konzeptioniert wird (vgl. [Buc08, S. 20 ff]).
Im Servicedesign (Service Design) wird darauf aufbauend der Service entworfen (vgl. [Buc08, S. 27 ff]) und in der Serviceüberführung (Service Transition) in das produktive Umfeld im- plementiert (vgl. [Buc08, S. 32 ff]). Für die ordnungsgemäße Ausführung der Dienstleistung sorgt der Servicebetrieb (Service Operation) (vgl. [Buc08, S. 37 ff]). Die stetige Anpassung, die wiederum eine Änderung der Servicestrategie oder des Servicedesigns erfordern kann, ver- antwortet die kontinuierliche Verbesserung (Continual Improvement) (vgl. [Buc08, S. 42 ff]).
Vergleicht man die Kernpublikationen der zweiten mit der dritten Version von ITIL, so wird deutlich, dass das Thema Testen erst in der neueren Publikation detailliert thematisiert wird.
In der Version zwei sucht der Leser vergeblich nach einem Prozess, der ausschließlich das Testen beschreibt. Vielmehr trifft man auf allgemeine Aussagen, wie folgende im Rahmen des Release-Managements: „These procedure should be tested before they are brought into use.“
[Cen00, S. 134].
Auch die einschlägige Literatur abseits der offiziellen ITIL V2 – Publikationen ist nicht de- taillierter. Ganz im Gegenteil findet man sogar Aussagen, die missverstanden werden können oder nach der fundamentalen Theorie des Softwaretestens gänzlich falsch sind. Ein Beispiel dafür ist bei Köhler zu finden: „Besonders bei Applikationssoftware-Veränderungen [. . . ] ist eine [. . . ] Softwareverteilung von ausgetesteter [sic!] Software notwendig.“ [Köh07, S. 46].
Schon die Basisliteratur des Softwaretests sagt, dass das „Austesten“3 von Software ein un- möglicher Akt ist, da zu viele Kombinationen und Randbedingungen beachtet und getestet werden müssten (vgl. [SL04, S. 12 f]). Die dementsprechend hohen Kosten- und Zeitaufwände, die investiert werden würden, liegen sicherlich nicht im Sinne der service-orientierten ITIL.
Deutlich wird aus diesem Beispiel aber, dass mutmaßlich die Akzeptanz der ITIL-Experten zum Thema Testen in dieser Zeit nicht sonderlich hoch war.
In ITIL V3 ist der Test von Services in der Publikation „Service Transition“ detaillierter dar- gestellt. Der nun eigenständige Abschnitt „Service Validation and Testing“ beschreibt einen Prozess mit spezifizierten Ein- und Ausgangsdokumenten und Kennzahlen. Dieser Prozess
3 Austesten bedeutet, dass eine Software einem vollständigen Test unterzogen wird. Siehe dazu Abschnitt 2.2.3 auf Seite 8
2.3. IT Infrastructure Library
Abbildung 2.3.: Prozess Service Validation and Testing in Anlehnung an [RLW09, S. 63]
betrachtet nicht nur den Test von Software, sondern vollumfänglich alle Services, die den Service Lifecycle durchlaufen (vgl. [Off07b, S. 115 ff]).
Allerdings gibt die Publikation nur einen relativ einfachen Rahmen für das Testen. Zwar werden verschiedene Testarten kurz aufgezählt und z.T. auch erläutert, aber eine genaue Einordnung und Detaillierung des Testprozesses erfolgt nicht.
2.3.2. Schnittstellen zu anderen ITIL – Prozessen
2.3.2.1. Change Management
Das Change Management ist in dem Prozess Service Transition eingegliedert und ist verant- wortlich für alle Änderungen an Services, die bereits eingeführt sind, sowie die Einführung von neuen Services in eine Organisation (vgl. [Bei10, S. 97]). Das Change Management steu- ert nicht nur die einfache Einführung einer Software und dessen Aktualisierungen, sondern betrachtet in der Änderung (Change) des Systems die Schnittstellen zu anderen Systemen, den betriebswirtschaftlichen Nutzen und entsprechende Risiken, wie der Störung von Ge- schäftsprozessen während der Einführung einer Veränderung.
Die Schwerpunkte liegen dabei in der Identifizierung und Steuerung von Auswirkungen auf das Unternehmen, verursacht durch Changes. Auch die Planung und Durchführung der Ein- führung von Änderungen sind wesentliche Bestandteile des Aufgabenbereichs (vgl. [Bei10, S. 100 ff]).
Da das Change Management die Einführung einer Software oder dessen Aktualisierungen verantwortet, muss es die zu integrierenden Bestandteile überprüfen und genehmigen. Da- bei ist die Testdokumentation der vorhergegangenen Testphase eine wichtige Basis, die die Entscheidung des Change Managements maßgeblich beeinflusst.
2.3.2.2. Release und Deployment Management
Das Release und Deployment Management, folgend nur Release Management, ist ebenfalls in dem Prozess Service Transition eingeordnet und verantwortet die Planung und Durchfüh- rung von Änderungen von bestehenden und die Einführungen neuer Services. Im Fokus der
Betrachtung steht das Release, das eigenständige oder Sammlungen von Changes beinhaltet (vgl. [Bei10, S. 110 ff]).
Die Schwerpunkte dieses Prozesses liegen im Wesentlichen in der Zeit- und Ressourcenplanung zur Erstellung und dem „Ausrollen“ eines Release. Dabei ist die Kommunikation zum Change Management, Service Management und der Testorganisation ein wichtiger Bestandteil.
2.3.2.3. Configuration Management
Das Configuration Management führt die Dokumentation und Archivierung von Service- und Infrastrukturkomponenten durch (vgl. [Buc08, S. 53 f]).
Bspw. sind sämtliche Bestandteile der Büroausstattung eines Unternehmens innerhalb des Configuration Managements beschrieben, mit deren wichtigsten Informationen, wie Standort und Alter, um u.a. eine schnelle Zuordnung zu gewährleisten. Neben Stühlen und Tischen wird jedoch auch Software dokumentiert und archiviert. Grund dafür ist, dass es in einigen Bereichen, wie auch im Softwaretest, wichtig sein kann, eine ältere Version einer Anwendung nutzen zu können. Die Nachvollziehung einer Fehlerwirkung bei einem Kunden mit einer älteren Version der Software ist ein gutes Beispiel.
2.4. Zusammenfassung
Das Kapitel gab einen groben Überblick über die grundlegenden Begriffe und Themengebiete des Softwaretests und stellte mit dem risikoorientiertem Testen einen grundlegenden Ansatz in diesem Bereich dar. Vorgestellt wurden auch die relevanten Normen und Standards, die in dem Testumfeld zum Einsatz kommen oder berücksichtigt werden müssen, um im Zweifelsfall Haftungsausschlüsse bei rechtlichen Problemen geltend zu machen. Nebenbei geben sie einen Überblick über mögliche Prozesse und Methoden, die in einer Testorganisation genutzt werden können.
ITIL, ein De-facto-Standard der Strukturierung von IT-Organisationen, bildet den Software- test ab der Version drei ab und gibt Unternehmen die Möglichkeit den Testprozess strukturiert in ihre ITIL-Prozesse zu integrieren. ITIL zeigt dabei Schnittstellen zu anderen relevanten ITIL-Prozessen auf. Allerdings stellt die Library nur die obersten Prozessebenen dar, sodass die Unternehmen eine Aufschlüsselung der einzelnen Abläufe selbst erstellen müssen.
Der Schwerpunkt der Arbeit wird demnach darin bestehen, den Testprozess mittels der rele- vanten Normen und Standards zu detaillieren und einzelne Ansätze genauer zu betrachten, sodass ein Prozess entsteht, der ITIL-konform ist und in seinem Detaillierungsgrad den ak- tuellen Stand der Technik widerspiegelt.
2.4. Zusammenfassung
Abbildung 2.4.: Das Kapitel Grundlagen in der Struktur der Arbeit
3. Ist-Zustand
3.1. Die DVZ M-V GmbH
3.1.1. Geschichtlicher Abriss
Die Ursprünge der DVZ M-V GmbH entstanden im Jahr 1966 mit der Gründung der „VEB Maschinelles Rechnen“, die die Lochkartenabteilung der statistischen Bezirksstelle ablösen sollte. Diese wurde 1975 mit dem „VE Rechenbetrieb Binnenhandel Schwerin“ zusammenge- führt und firmierte in den Folgejahren bis zur Wende unter den Namen „VEB Datenverar- beitungszentrum Schwerin“.
Nach der Wiedervereinigung wurde das Unternehmen am 01. Juli 1990 in eine GmbH umge- wandelt mit der Bezeichnung „Datenverarbeitungszentrum Schwerin GmbH i.A.“ und 1992 für eine DM an das Land Mecklenburg-Vorpommern verkauft, welches bis heute alleiniger Gesellschafter des Unternehmens ist. Ein Jahr später erfolgte die Umbenennung in die noch heute getragene Bezeichnung „DVZ Datenverarbeitungszentrum Mecklenburg-Vorpommern GmbH“ mit der Kurzbezeichnung „DVZ M-V GmbH“ (vgl. [Lud10, S. 2]).
3.1.2. Aufgabenspektrum und Kernkompetenzen
Die DVZ M-V GmbH agiert als zentraler IT-Dienstleister der Landesverwaltung Mecklenburg- Vorpommern. Sie übernimmt die wesentlichen Aufgaben mit Bezug zur Informationstechnik, wie der Bereitstellung und des Betriebes von Hardware sowie der Erstellung und Weiter- entwicklung von Software für Behörden, Ämter und Organisationen des Landes, wie der Feuerwehr.
Neben dem Hauptkundensegment, der Landesverwaltung Mecklenburg-Vorpommern, exis- tiert ein eigenständiger Betriebsteil, der Dienstleistungen für die Wirtschaft und Kommunen innerhalb und außerhalb des Bundeslandes anbietet (vgl. [DVZ09, S. 4]).
Die wesentlichen Angebote des Datenverarbeitungszentrums umfassen nach [DVZ09, S. 10 ff]:
IT-Consulting, zu dem die Bereiche IT-Strategieberatung, IT-Infrastruktur, Informations- sicherheit und IT-Projektmanagement gehören;
eGovernment-Dienste, die ein Leistungsangebot von Basiskomponenten, wie Dokumenten- Management-Systeme bis hin zu der virtuellen Poststelle für die Landesverwaltung bie- ten;
Fachapplikationen, die die wesentlichen Prozesse der öffentlichen Verwaltung in den Be- reichen Sozial-, Personal-, Finanz-, Polizei-, Justizverfahren, Geoinformationen und In- ternet unterstützen;
Managed Services, die die ITIL-konforme Dienstleistungserbringung der technischen Un- terstützung bereitstellt, wie IP-Telefonie und den typischen Verwaltungsarbeitsplatz der Landesverwaltung;
Sicherheitsinfrastrukturen, in denen u.a. die sichere Verwaltung der Daten der Landes- verwaltung Mecklenburg-Vorpommern durch spezielle Firewall-Lösungen gewährleistet und das Landesverwaltungsnetz betrieben wird;
Rechenzentrum, neben dessen TIER 3-Betrieb u.a. auch die Bereitstellung von Rechen- leistung und die Betreuung der Kunden bei Störungen durch einen zentralen Service Desk erfolgt;
Zentrale Beschaffung, die es der Landesverwaltung erlaubt auf einem Online-Portal not- wendige, technische Ressourcen zu bestellen und durch die DVZ M-V GmbH aufzubauen und betreiben zu lassen;
Technischer Service, in dem die Installation und Wartung von Systemen für den Kunden durchgeführt wird und der einen technischen Vor-Ort-Service bietet;
Seminare und Trainings, in denen die Angestellten des öffentlichen Dienstes und der Wirtschaft über Anwendungen, Verfahren und soziale Kompetenzen geschult werden können.
3.1.3. Das Projekt EL.MA
Die praktischen Teile der vorliegenden Arbeit werden anhand eines konkreten Beispiels detail- lierter betrachtet. Dieses Beispiel ist abgeleitet von einem in der DVZ M-V GmbH laufenden Projekt namens Elektronisches Magazin, kurz EL.MA.
EL.MA ist eine von der DVZ M-V GmbH erstellte Software zur Unterstützung der Lang- zeitspeicherung von kyptografisch signierten Dokumenten. Sie soll den Beweiswert der Doku- mente für eine große Zeitspanne über Jahre hinweg sicherstellen. Der Einsatz erfolgt zurzeit in dem Bereich des Personenstandswesens, in dem standesamtliche Urkunden zwischen 30 und 110 Jahre gem. § 5 Absatz 5 PStG (Personenstandsgesetz) aufbewahrt werden müssen, bevor sie an das jeweils zuständige Archiv zu übergeben sind (vgl. [Leh12, S. 23 ff]).
Die Architektur von EL.MA ist durch das Bundesamt für Sicherheit in der Informations- technik (BSI) in der Technischen Richtlinie (TR) 03125 mit der Bezeichnung „Beweiswert- erhaltung kryptographisch signierter Dokumente“ (TR-ESOR) festgelegt und definiert es als Middleware (vgl. [Bun11, S. 13 ff]).
EL.MA fungiert dabei als Bindeglied zwischen der Applikationsschicht, die als Benutzer- schnittstelle für die Aufnahme und Bearbeitung der Dokumente zuständig ist, und dem Lang- zeitspeichersystem, das die Dokumente in einem XML-basierten Dateiformat aufbewahrt.
Das elektronische Magazin hat die Aufgabe die aufgenommenen, signierten Daten aus der Applikationsschicht zu übernehmen und diese auf ihre korrekte Signatur gem. Signaturgesetz (SigG) zu prüfen, bevor sie in den Langzeitspeicher überführt werden. Wiederum werden die bestehenden Signaturen im Langzeitspeicher auf ihre Gültigkeit überprüft und laufend erneuert (siehe dazu [Lor10, S. 25 ff]).
Die innere Struktur von EL.MA besteht aus insgesamt fünf eigenständigen Modulen. Aus Sichtweise einer Dokumentenspeicherung werden zunächst die Daten und Dokumente aus der Applikation über eine Adapterschicht, die auf Basis der Schnittstellenformate der An- wendung realisiert ist, übertragen. Diese bildet damit die Schnittstelle zwischen der Appli- kationsschicht und EL.MA. Das Modul ArchiSafe übernimmt die Daten und Dokumente und prüft, ob der jeweilige Standesbeamte berechtigt ist, das Dokument abzuspeichern. Je nach Zugriffsberechtigung übergibt ArchiSafe das Dokument an das ArchiSig-Modul, des- sen Aufgabe es ist, dieses auf seine ordnungsgemäße Signatur gem. SigG zu prüfen. Diese
3.1. Die DVZ M-V GmbH
Abbildung 3.1.: Einordnung von TR-ESOR in die Gesamtarchitektur
Abbildung 3.2.: Architektur der Software EL.MA
Signaturprüfung erfolgt durch Funktionalitäten, die durch das Krypto-Modul bereitgestellt werden. Dabei werden die relevanten Daten an das Krypto-Modul übergeben, welches die eigentliche Überprüfung durchführt, und gibt das Ergebnis an das ArchiSig-Modul zurück.
Ist das Ergebnis der Prüfung positiv, so wird das Dokument, mit den relevanten Daten, in den Langzeitspeicher überführt und durch das ArchiSig-Modul regelmäßig mit einer neuen Signatur mittels qualifiziertem Zeitstempel versehen (Übersignatur). Der Langzeitspeicher ist in der Umsetzung des DVZ M-V GmbH ein Teil des Systems (vgl. [Lor10, S. 25 ff] und [LLB11]).
Erfolgt durch den Standesbeamten nur eine Abfrage der Daten, z.B. zur Erstellung einer Geburtsurkunde, so werden das ArchiSig- und das Krypto-Modul nicht angesprochen. In diesem Fall erfolgt nach der Zugriffsprüfung durch ArchiSafe eine direkte Anfrage an den Langzeitspeicher, der wiederum die Antwort direkt an das ArchiSafe-Modul zurückgibt.
3.2. Einschätzung des IST-Zustandes
3.2.1. Testorganisation
Die Testorganisationsform der DVZ M-V GmbH ist nach Zimmermann ein „traditionelles“
Gebilde und in ihrer Ausführung den einzelnen Entwicklungsteams zugeordnet (vgl. [Zim10, S. 22]). Die DVZ M-V GmbH verfolgt somit einen dezentralen Ansatz, wobei jedes Projekt für sich seine Testprozesse und Testschwerpunkte definiert und eigene Testwerkzeuge einsetzt.
Die Rolle der Tester wird dabei von den Entwicklern selbst eingenommen, die jedoch meist nicht über das notwendige Wissen über den Softwaretest verfügen (vgl. [Spi08a, S. 100]). Aus eigenen Erfahrungen kann gesagt werden, dass im Gegensatz zu dem „traditionellen“ Ansatz z.T. auch der Softwaretest in den Projekten von einer einzelnen Person durchgeführt wird.
Dieses entspricht einer geringen Trennung der Testaktivitäten von den Entwicklungen, die eine effizientere Form der Überprüfung darstellen (vgl. [HL10, S. 1]).
Aus einem Artikel von Zimmermann geht hervor, dass die DVZ M-V GmbH in ihrer lang- fristiger Planung einen zentralen Ansatz für die Durchführung der Testaktivitäten verfolgt und die Nachteile der bisherigen Lösung, dem dezentralen Ansatz, erkannt wurden. Dazu ist angedacht, ein eigenständiges Test- und Qualitätscenter zu konzeptionieren und einzuführen.
Auf der Grundlage eines durch die DVZ M-V GmbH erstellten Grobkonzeptes wurde das TQC im Rahmen des Entwicklungsprojektes DOMEA® (Dokumentenmanagement und elek- tronische Archivierung im IT-gestützten Geschäftsgang) eingeführt und erprobt, was nach Zimmermann die erste von drei Implementierungsphasen ausmachte. In den folgenden zwei Phasen werden zukünftig weitere etablierte Fachverfahren in das Aufgabenfeld des TQCs einbezogen und die Testautomation eingeführt (vgl. [Zim10, S. 22 ff]).
3.2.2. Testprozess
Wie die Testorganisation ist auch die Einordnung des Testprozesses des Pilotprojektes TQC in die ITIL-Landschaft in dem Artikel von Zimmermann beschrieben, welches aus dem in- ternen Grobkonzept der DVZ M-V GmbH stammt. Dabei wird der Testprozess dem Release Management zugeordnet, wie es in der ITIL V2 beschrieben ist (vgl. [Cen00, S. 134]). Der Softwaretest beginnt nachdem die Entwicklung des Releases und der Komponententest durch die Entwickler abgeschlossen ist. Die DVZ M-V GmbH verfolgt damit einen reaktiven Ansatz ihrer Testaktivitäten (Siehe Abschnitt 2.2 auf Seite 5).
3.2.3. Analyse des Testverhaltens
Aus den, dem Autor vorliegenden, Dokumenten und Veröffentlichungen ist eine Einschätzung der organisatorischen Sichtweise des Softwaretests möglich. Allerdings fehlen weitere Informa- tionen, die beschreiben, inwieweit mit dem Thema Testen in der DVZ M-V GmbH alltäglich umgegangen wird.
Als Informationsquelle sollte eine Umfrage zum Thema Softwaretest in der DVZ M-V GmbH dienen. Diese hatte das Ziel, detailliertere Auskünfte zum Testverhalten des Unternehmens zu erhalten und einen Überblick zu geben, welche Testtechniken und Testwerkzeuge eingesetzt werden.
3.2. Einschätzung des IST-Zustandes 3.2.3.1. Umfrage
Die Umfrage erfolgte in einer Zeitspanne von insgesamt zwei Monaten und war nur für einen beschränkten Teilnehmerkreis, den IT-nahen Mitarbeitern der DVZ M-V GmbH, zugäng- lich. Sie umfasste 27 Fragen und untergliederte sich thematisch in zwei Bereiche: allgemeine Informationen und Testverhalten.
In den allgemeinen Informationen wurden die Teilnehmer gebeten, eine Aussage über ihr Arbeitsumfeld zu geben. Dieses beinhaltete bspw. den Entwicklungsbereich, in dem sie sich befanden (Webentwicklung, Anwendungsentwicklung oder technische Lösungen), sowie die gängigen Programmiersprachen, die in ihren aktuellen Projekten verwendet wurden.
In dem zweiten Teil der Umfrage wurden den Teilnehmern Fragen zu dem Umgang mit dem Thema Softwaretest gestellt. Angefangen mit Angaben über den Einsatz von Anwendungen zur Unterstützung der Anforderungsanalyse über verwendete Testarten bis hin zur Qualifi- kation des Testteams wurden Informationen abgefragt.
Die technische Umsetzung der Umfrage erfolgte über einem Microsoft Sharepoint Server (Windows SharePoint Services 3.0) mithilfe der Funktion „Umfrage“.
3.2.3.2. Teilnahme
Innerhalb der DVZ M-V GmbH wurden insgesamt 15 Sachgebiete angeschrieben, die zusam- men etwa 190 Mitarbeiter verfügen und sich mit dem Thema Softwaretest durch ihre Aufga- bengebiete beschäftigen sollten. Zudem kamen elf einzelne Mitarbeiter, die Testaufgaben in Projekten übernehmen. Damit umfasste die Zielgruppe der Umfrage circa 200 Personen.
Die Anzahl der verfügbaren Antworten am Ende der Umfragezeit betrugen insgesamt sechs.
Etwa sechs weitere Mitarbeiter haben die Umfrage geöffnet, aber nicht beendet, sodass auf ihre Antworten nicht zugegriffen werden konnte. Damit ergibt sich eine Beteiligung von ins- gesamt 6%, wobei nur 3% aller Mitarbeiter verwertbare Ergebnisse abgegeben haben.
3.2.3.3. Ergebnisse
Die tabellarische Zusammenstellung der Ergebnisse, auf die im Folgenden zurückgegriffen wird, sind im Abschnitt A im Anhang zu finden. Enthalten sind darin alle Fragen und Ant- worten, die in Bezug auf der folgenden Auswertung wichtig erscheinen. Antwortmöglichkeiten oder Fragen, die von allen Umfrageteilnehmern ausgelassen wurden, sind ebenfalls nicht in der Zusammenstellung enthalten.
Der große Anteil der Teilnehmer, insgesamt vier, ist in dem Bereich der Anwendungsentwick- lung tätig. Dieses spiegelt sich auch in der Nutzung der Programmier- und Skriptsprachen wider, die vorwiegend in der Anwendungsentwicklung zum Einsatz kommen.
Die Anforderungsanalyse wird bei keinem der Teilnehmer durch eine spezielle Software un- terstützt. Für die Anforderungsanalyse kommen nur die Microsoft Office Produkte Word und Excel zur Anwendung, die wohl eher der reinen Dokumentation der Anforderungen dienen.
Die in der Testdurchführung ausgeführten Testfälle, die mit der Anforderungsspezifikation zu vergleichen sind, werden durchgehend manuell gegenübergestellt und nicht automatisiert.
Die Testplanung beginnt in zweidrittel aller Fälle nachdem die Entwicklungstätigkeiten ab- geschlossen sind und nur in einem Drittel während der Anforderungsanalyse beim Kunden.
Dieses belegt auch die Grundaussage von Zimmermann, die die Testorganisation innerhalb der DVZ M-V GmbH als ein „traditionelles Gebilde“ beschreibt (vgl. [Zim10, S. 22]).
Der Abschluss der Testaktivitäten erfolgt vornehmlich mit der Ausführung aller Testfälle und Fehlernachtests. Vereinzelt werden die Aktivitäten erst abgeschlossen, wenn das Vertrauen in die Software gegeben ist oder jede Anforderung mindestens einmal getestet wurde. Ein Teilnehmer gab an, dass die Testaktivitäten nie abgeschlossen werden. Vermutlich ist damit die periodische Release-Testphase gemeint.
Die zeitliche Inanspruchnahme der Testphase wurde gleichmäßig verteilt auf kurze Testphasen von ein paar Tagen und lange Testphasen von ein bis zwei Monaten. Ein weiterer gleichgroßer Teil gab an, dass die jeweiligen Testzeiten in Abhängigkeit des Projekts stehen. Die Anzahl der Testphasen vor der Produktivstellung sind vornehmlich drei, wobei es auch vereinzelt zu zwei bis nur einer Testphase kommt.
Die Frage nach dem verwendeten Vorgehensmodell in den jeweiligen Projekten erhielt eine ernüchternde Antwort. Gerade mal ein Teilnehmer gab an, ein Vorgehensmodell zu verwenden und zwar das „Unified Process“. Alle weiteren fünf Teilnehmer nutzen keine Vorgehensmo- delle.
Erfreulich sind die vielfältigen Aussagen über die verwendeten Testarten und Testentwurfsver- fahren in den Projekten. Besonders die Anzahl der nicht kategorisierten Arten und Verfahren ist mannigfaltig. Auch Testwerkzeuge werden vielfältig eingesetzt. Vornehmlich werden da- bei Testmanagement-, Fehler- und Abweichungs-, statische Analyse-, Testausführungs- und Vergleichswerkzeuge eingesetzt.
Zu den Metriken ergab sich, dass zwar wenigstens ein Drittel der Teilnehmer Kennzahlen innerhalb des Testprozesses aufnehmen, allerdings wurden unter Nachfrage nur zwei Metriken aufgenommen.
Die Frage nach der Qualifizierung der Projektmitarbeiter in dem Bereich des Softwaretests ergab, dass keine Qualifikationen bestehen. Erfragt wurde auch, wie hoch die Anzahl an Testern in den Projekten ist, was ergab, dass die Hälfte der Befragten keine eigenständigen Tester in den Unternehmungen beschäftigt. Die andere Hälfte gab an, ein bis drei Tester in den Projekten zu haben.
Die abschließenden Fragen sollten den Einsatz von Standards und Normen innerhalb der Testphase wiedergeben. Allerdings werden in den Projekten der Teilnehmer keine verwendet.
3.2.3.4. Auswertung
Durch die geringe Beteiligung in Hinblick auf die Gesamtzahl der betroffenen Mitarbeiter ist die Umfrage nicht repräsentativ. Wird jedoch davon ausgegangen, dass die stichprobenartigen Ergebnisse die Testkultur der DVZ M-V GmbH widerspiegeln, so sind Schwerpunktthemen für die Optimierung der Entwicklungsprozesse des Unternehmens zu erkennen.
Das Management der DVZ M-V GmbH muss den Testprozess, wie auch das Anforderungsma- nagement, mehr fördern und in den Entwicklungslebenszyklus einbinden. Neben strengeren Vorgaben sollte dabei eine effektivere Weiterbildungspolitik verfolgt werden, da davon aus- gegangen werden kann, dass durch die geringe Qualifizierung der Mitarbeiter in Bezug auf das Testen wenig Betrachtung auf dem Softwaretest und das Anforderungsmanagement ge- setzt wird. Zwar existieren Kenntnisse über einzelne Testarten und Testentwurfsverfahren, allerdings führt dieses nicht zu einem strukturierten Testprozess oder die Annahme und Ver- wendung von Vorgehensmodellen. Die konsequente Nutzung von strukturierten Modellen ist
3.2. Einschätzung des IST-Zustandes jedoch eine Voraussetzung für das Testmanagement, um durch standardisierte Schnittstellen in den Entwicklungsprozess einzufließen.
Für die zu konzeptionierende Testorganisation ergeben sich Aufgaben u.a. in Hinblick auf die Werkzeugunterstützung. Zwar werden Werkzeuge verwendet, allerdings vielfältig und ohne das Potenzial zu nutzen, wie in etwa dem Monitoring durch eine gezielte Erfassung von Kennzahlen. Das Management sollte die Aufnahme und Auswertung von Metriken fordern, um die Effektivität des Testens bewerten zu können. Werden keine Kennzahlen gefordert, werden sie auch nicht aufgenommen.
Zudem muss die Vielzahl an Programmiersprachen berücksichtigt werden, welche Einfluss auf die Nutzung von Testautomatisierungssoftware hat. Es erscheint sinnvoll, sich dabei zu- nächst auf den Bereich der Anwendungsentwicklung zu konzentrieren, da dieser einen Großteil der Entwicklungstätigkeiten ausmacht und erst nach der Etablierung dieser Werkzeuge die Bereiche der technischen Lösungen und der Webentwicklung zu betrachten.
Eine weitere Aufgabe der Testorganisation besteht darin, Vorgaben für das Testen, unabhän- gig von der Nutzung der Dienstleistungen des Testcenters in den Projekten, zu entwickeln.
Dieses würde die Entwicklungsprojekte in den Testphasen erheblich unterstützen, sei es in der Auswahl von Metriken oder der strukturierten Dokumentation.
3.2.4. Bewertung des Ist-Zustandes
Die DVZ M-V GmbH verfolgt vornehmlich einen dezentralen Ansatz des Softwaretests, sodass die Trennung zwischen der Entwicklung und dem Testen in den Projekten nicht gegeben ist.
Dieses Vorgehen sollte zukünftig vermieden werden, um die Testergebnisse effizienter gestalten zu können (vgl. [HL10, S. 1]).
Grundlage dafür ist, dass das Management des Unternehmens das Thema Softwaretest in seiner Bedeutung erkennt, da die Einführung einer zentralen Struktur durch die Leitung und Unterstützung der Unternehmensführung erfolgen muss. Dieser Zustand kann aus den spärlichen Ergebnissen der Umfrage interpretiert werden, da anscheinend die Mitarbeiter des Unternehmens wenig Interesse an dem Thema zeigen. Dieses Interesse wird jedoch nur erlangt, wenn es auch Vorgaben durch die Leitung gibt, nach denen sich das Personal zu richten hat.
Der Softwaretest wurde in der DVZ M-V GmbH als ein sehr effektives Qualitätsmanagemen- tinstrument erkannt. Es soll daher ein strukturierter Testprozess entstehen, der die aktuelle Testsituation verbessert und einen zentralen Ansatz verfolgt. In einem Pilotprojekt wird be- reits eine neue Struktur erprobt, die durch das vorliegende Konzept optimiert werden soll.
Ein Schwerpunkt der späteren Umsetzung des folgenden Konzeptes wird nicht der Aufbau der Testorganisation oder der Testdurchführung als solches sein. Vielmehr liegt die Gefahr darin, dass es an Unterstützung mangeln könnte, die eingeführten Prozesse und erstellten Vorgaben durch das Testcenter durchzusetzen. Daher muss das Management auf Basis der folgenden Konzeption und der später noch vorgestellten organisatorischen Spezifikationen klare Erwartungshaltungen sowie Vorgaben definieren und durchsetzen.
3.3. Zusammenfassung
Das Kapitel stellte einen groben Überblick über die Geschichte und die Dienstleistungen der DVZ M-V GmbH dar. Das vorgestellte Projekt EL.MA, wird in der folgenden Konzeption aufgegriffen, um aufgeführte Verfahren und Methoden an einem Beispiel erläutern zu können.
Zurzeit wird in dem Unternehmen ein dezentraler Ansatz der Testorganisation verfolgt. Das Unternehmen hat aber den Stellenwert des Softwaretests erkannt und erprobt in einem Pi- lotprojekt ein Grobkonzept, welches das Test- und Qualitätscenter beschreibt und in drei Einführungsphasen untergliedert ist.
Für die folgende Konzeption wurde in der DVZ M-V GmbH eine Umfrage durchgeführt, um zu erfahren, wie sich das Testen in den aktuellen Entwicklungsprojekten verhält. Die Teilnahme an der Umfrage waren jedoch so gering, dass diese nicht repräsentativ ist. Deuten kann man dieses als allgemeines Desinteresse zum Thema Softwaretest, was ursächlich an dem fehlenden Fachwissen liegen kann und an den bisher fehlenden Vorgaben durch das Management.
Abbildung 3.3.: Das Kapitel Ist-Zustand in der Struktur der Arbeit
4. Soll-Konzept
4.1. Dem Ganzen einen Rahmen geben
Das folgende Kapitel beschreibt den organisatorischen Rahmen des Test- und Qualitätscen- ters. Zunächst wird dafür auf die Testorganisation und die grundlegenden Prozessen einge- gangen, die innerhalb des TQCs durchlaufen werden können und die in Führungs-, Kern-, und Supportprozesse unterschieden werden. Darin wird die Identifizierung bis hin zur Über- wachung von Risiken definiert, die in dem Abschnitt Risikobetrachtung detaillierter erläutert werden sollen. Der dann folgende Servicekatalog baut auf den vorherigen Schritten auf und beschreibt die eigentlichen Dienstleistungen, die das Testcenter den Entwicklungsabteilun- gen anbieten kann, wie z.B. die relevanten Testarten. Die Kennzahlen, die u.a. für den Ser- vicekatalog wichtig sind, werden in dem Abschnitt Metriken behandelt und vorgestellt. Die notwendigen Betriebsvoraussetzungen bilden den Abschluss des Rahmens und geben an, was in der Organisation getan werden muss, um das Testcenter erfolgreich in das Unternehmen einzuführen. Am Ende dieses Kapitels wird es wirtschaftlich. Das Testcenter wird hier auf die sprichwörtliche „Waagschale“ gelegt und die anfallenden Kosten werden grob ermittelt, um einen finanziellen Eindruck des Test- und Qualitätscenter gewinnen zu können.
Abbildung 4.1.: Der organisatorische Rahmen des Test- und Qualitätscenters
4.2. Testorganisation
Die Wahl einer geeigneten Testorganisation bildet das Fundament für den Testprozess. Aus dieser bilden sich verschiedene Schwerpunkte für die Konzeption der Testaktivitäten, sodass die Organisationsform zunächst identifiziert werden soll.
Die Formen der Testorganisation sind vielfältig und es gibt keine, die grundsätzlich als „Al- lerheilmittel“ bezeichnet werden kann. Vielmehr müssen Vor- und Nachteile der einzelnen Optionen betrachtet und auf Grundlage der Anforderungen des Unternehmens gewichtet werden, sodass die zu konzipierende Testorganisation dem firmeninternen Rahmen entspricht (vgl. [Spi08a, S. 99]).
Aus der Literatur lassen sich fünf grundsätzliche Organisationsformen ableiten (vgl. z.B.
[Spi08a, S. 99 ff], [Wöl12, S. 15] oder [HL10, S. 1]):
• Entwickler sind auch gleichzeitig Tester,
• es besteht ein eigenes Testteam innerhalb eines Projekts,
• es besteht ein unternehmensweites Testcenter,
• es besteht ein unternehmensweites und serviceorientiertes Testcenter,
• outsourcing der Testprozesse.
Die Anforderungen der DVZ M-V GmbH an die Testorganisation sind durch den „Maßnah- menkatalog zur E-Government-Strategie des Landes Mecklenburg-Vorpommern“ vorgegeben, aus dem sich folgende Anforderungen bzgl. der Organisation ableiten lassen (vgl. [Leh12, S. 4]):
• Die Testorganisation ist zur Kosteneinsparung zu zentralisieren.
• Die Testaktivitäten sind bedarfsgerecht anzubieten.
Weiterhin besteht die Anforderung, die Testorganisation in Anlehnung an ITIL zu struktu- rieren und die wesentlichen Prinzipien daraus zu nutzen. Der Grundsatz von ITIL liegt dabei auf der Serviceorientierung, in der Form, dass einzelne Dienstleistungen in einem Katalog zusammengefasst sind und dem jeweiligen Kunden, d.h. auch internen Strukturen, anforde- rungsspezifisch als Services angeboten werden können (vgl. [SS08, S. 11]).
Die wesentlichen Kriterien aus den aufgeführten Anforderungen sind somit:
• Zentralität,
• Serviceorientierung / Bedarfsorientiert.
Stellt man die Anforderungen den Vor- und Nachteilen der einzelnen Testorganisationen aus Tabelle 4.1 auf der nächsten Seite gegenüber, so ist dementsprechend das serviceorientierte Testcenter zu wählen, dass die zwei wesentlichen Kriterien erfüllt.
4.2. Testorganisation
Organisation Vorteile Nachteile
Entwickler = Tester
• Schnelle Fehlersuche
• Schnelle Fehlerbehebung
• Keine Einarbeitungszeit ins Testobjekt
• Entwickler haben wenig Test-Know-How
• Entwickler sehen Fehler in eigenen Produkten nicht, da Vertrauen in eigene Arbeit
• Schlecht zu koordinieren Testteam
• Besser planbar
• Spezialisierung auf Softwaretest
• Einstufung der Tester als potentielle Feinde
• Gesamtüberlickblick geht verloren
Internes Testcenter
• Professionalisierung der Mitarbeiter
• Kosteneinsparung durch zentrale Infrastrukturen
• Durchgehende Möglichkeit der Eigenoptimierung
• Mehrere Testprojekte gleichzeitig abwickelbar
• Höhere Produktqualität durch Standardisierung
• Lange Kommunikationswege
• Kein bis wenig Know-How über Testobjekt
• Vertrauensminderung durch steigende Intransparenz
• Langfristiger Einsatz von Personal
• Hoher Fixkostenanteil
Service- orientiertes Testcenter
• Testleistung auf Wunsch
• Einfache Kostentransparenz
• Hohe ITIL-Konformität
• Definierte Ergebnisse und Abläufe
• Spagat zwischen Standardisierung und individuellem Prozess
• Marketing-Leistung im eigenen Unternehmen nötig
Outsourcing
• Transparenz
• Vertrauen in Qualität des Produktes
• Dienstleister ist steuerbar
• Wirtschaftlichkeit
• Kulturelle Differenzen
• Kommunikationsprobleme
• Politische/wirtschaftliche Rahmenbedingungen
• Schutz des geistigen Eigentums schwierig
Tabelle 4.1.: Vor- und Nachteile der möglichen Testorganisationen nach [Möc12, S. 5 f], [Spi08a, S. 99 ff] und [Wöl12, S. 18]
