Einsatz von Test-Tools im Rahmen der Zusammenarbeit zwischen Tester und Entwickler

Aus Winfwiki

Name des Autors / der Autoren:	Patricia Stein, Patrick Bücking, Neli Liedtke
Titel der Arbeit:	Einsatz von Test-Tools im Rahmen der Zusammenarbeit zwischen Tester und Entwickler
Hochschule und Studienort:	FOM Essen

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Tabellenverzeichnis 4 Einleitung / Motivation 5 Grundlagen 5.1 Verwendungszweck von Software-Test-Tools 5.2 Einordnung von Test-Tools und warum überhaupt Tests automatisieren 5.3 Notwendigkeit von Test-Tools bei Software- Entwicklung 6 Arten der Kommunikation zwischen Tester und Entwickler 6.1 Persönliche Kommunikation 6.1.1 Meetings / Workshops 6.1.2 Story-Cards 6.1.3 Telefon / Telefonkonferenzen 6.1.4 Klassische textbasierte Kommunikationsformen 6.2 Kommunikation per Software 6.2.1 E-Mails (z.B. mit Outlook) 6.2.2 Knowledge Management Systeme 6.2.3 weitere Kommunikations- und Austauschinstrumente 7 Test-Verfahren und - Modelle 7.1 Dynamisches / Statisches testen 7.1.1 Dynamische Tests 7.1.2 Statische Tests 7.2 Blackbox 7.2.1 Anwendertest 7.2.2 Akzeptanztest 7.2.3 Alpha-/ Beta-Test 7.2.3.1 Alpha-Test 7.2.3.2 Beta-Test 7.3 Whitebox 7.4 Graybox 7.5 Checklisten 7.6 Last- / Nutzer-Test 7.7 Performance-Test 7.8 Rückfall-Test / Regressions-Test 7.9 Stress-Test 8 Test-Tools 8.1 Bug Tracking Tools 8.1.1 Bugzilla 8.1.2 Jira 8.1.3 Mantis 8.2 Issue-Tracking Tools 8.2.1 JFire 8.2.2 Open Ticket Request System 8.2.3 Request Tracker 8.3 Vor- und Nachteile der Bug Tracking- und Issue Tracking Tools 8.4 Ablauf eines Test-Szenarios 9 Qualitätssicherung / Projektmanagement 9.1 Projektmanagement-Tools 9.2 Agiles Qualitätsmanagement 9.3 Personen und Wechselwirkungen 9.4 Zusammenarbeit mit Kunden 10 Vergleiche 10.1 Kommunikation mit und ohne Software-Test-Tools 10.2 Vergleich Bugtracking-Tools 10.3 Vergleich Issuetracking-Tools 11 Fazit 12 Fußnoten 13 Literatur- und Quellenverzeichnis 14 Relevante Links

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
EC-Karte	Electronic Cash-Karte
IEEE	Institute of Electrical and Electronics Engineers
OTRS	Open Ticket Request System
QS	Qualitätssicherung
RT	Request Tracker
SAP	Systeme, Anwendungen, Produkte

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Anforderung
2	Grenzwerttest
3	Bugzilla Logo
4	Bugzilla Homepage
5	Bugzilla Startseite
6	Bugzilla Report
7	Jira Logo
8	Jira Startseite
9	Mantis Logo
10	Mantis Startseite
11	JFire Logo
12	JFire Startseite
13	OTSR Webinterface
14	OTSR Infrastruktur
15	RT Kommunikation
16	Netways Request Tracker Startseite
17	Anfrageverarbeitung
18	Ablauf Fehlererkennung
19	Kommunikation allgemein
20	Kommunikation mit Aufgaben

3 Tabellenverzeichnis

Tabelle Nr.	Titel
1	Vor- und Nachteile des Gebrauchs von Test-Tools
2	Vor- und Nachteile der Bug Tracking- und Issue Tracking Tools
3	Kommunikation mit und ohne Software-Test-Tools
4	Vergleich Bugtracking-Tools
5	Vergleich Issuetracking-Tools

4 Einleitung / Motivation

Die Softwareentwicklung ist ein aufwendiger und komplexer Prozess. Im Rahmen der Programmierung von Software kommt es immer wieder zu Fehlern im Quellcode, die das Programm oder das ganze System zum Absturz bringen können. Auch wenn es keine offensichtlichen Fehler, wie Abstürze oder Fehlermeldungen gibt, kann es logische Fehler geben, die falsche Ergebnisse bei Berechnungen ausgeben. Diese Fehler vollkommen auszuschließen ist praktisch unmöglich, aber es ist möglich sie einzugrenzen oder zumindest dafür zu sorgen, dass durch einen aufgetretenen Fehler keine fatalen Folgefehler entstehen. Ein Folgefehler könnte z.B. dafür sorgen, dass eine Datenbank inkonsistent wird wenn aus einen vorherigen Modul falsche Werte übergeben werden. Ein weiterer grosser Nachteil ist, dass das Beseitigen von Fehlern enorme Kosten verursachen kann, wenn sie nicht frühzeitig ermittelt und beseitigt werden.

Ein gutes Beispiel ist die aktuelle Problematik der nicht funktionierenden EC-Karten, die auf Grund eines Softwarefehlers dafür sorgt, dass Bankautomaten und Kartenterminals mit der Jahreszahl 2010 nicht zurechtkommen. Das Ergebnis ist, das Bankkunden mit Ihrer EC-Karte kein Geld am Automaten abheben oder im Laden direkt per Karte bezahlen können^[1]. Das Entfernen des Fehlers durch tauschen der Karten, würde die Banken 240 Millionen Euro kosten^[2]. Dazu kommen noch die Kosten für das Abheben von Bargeld bei anderen Geldautomaten, die zumindest die Sparkassen erstatten wollen^[3].

Um solche Fehlerfälle einzugrenzen, ist es wichtig Software zu Testen. Dabei werden einzelne Programmabschnitte, Module und ganze Programme getestet. Da ein Test von jeder Funktion mit jeder möglichen Eingabekombination eines Programms viel zu aufwendig wäre, arbeiten Entwickler und so genannte Tester zusammen um das Testen und die Testfälle so effizient und aussagekräftig wie möglich zu gestalten. Die Tester sind dabei einzelne Personen oder ganze Organisationen die sich aus Entwicklern, Anwendern, und sachkundigem IT-Personal zusammensetzen. Damit eine gute Zusammenarbeit zwischen den beteiligten Personen entsteht werden unterschiedliche Tools in den unterschiedlichen Phasen der Entwicklung eingesetzt. Mit diesen Tools soll die Kommunikation zwischen den beteiligten Personen verbessert werden. Ebenfalls soll das Fehlerfinden effizienter und systematischer gestaltet werden.

Im Rahmen dieser Arbeit sollen einige dieser Tools vorgestellt werden. Es sollen die unterschiedlichen Einsatzmöglichkeiten und Notwendigkeiten der Tools gezeigt werden und wie sie zur Fehlerfindung und Behebung beitragen. Ebenfalls soll die Bedeutung des Testens genauer veranschaulicht werden. Des Weiteren wird geklärt wie wichtig die Tester für die Herstellung von qualitativ hochwertiger Software sind. Am Ende dieser Ausarbeitung sollte jeder Leser einen guten Überblick über das Verhältnis zwischen Entwickler und Tester haben und welche Tools sich beim Testen als hilfreich erweisen können.

5 Grundlagen

Software bestimmt unser tägliches Leben. Kaum ein technisches Gerät kommt ohne Software aus, kaum ein Unternehmen könnte ohne Software existieren. Im Laufe der Jahre hat sich die Softwaregestaltung stark verbessert, weiterentwickelt und an die Ansprüche des Anwenders angepasst, dass sich die Komplexität vervielfacht hat.

5.1 Verwendungszweck von Software-Test-Tools

Wettbewerbsfähige und erfolgreiche Softwareprodukte bedingen neben der Qualität der angebotenen Funktionen zunehmend die Nachvollziehbarkeit der entsprechenden Entwicklungsprozesse, d.h. wie die Software entstanden ist und welchen Regeln und Normen sie entspricht. Das Einhalten von Normen und Standards im Bereich Softwareentwicklung zeigt einen hohen Grad an Professionalität und die Qualität der Softwareprodukte. Auftraggeber im öffentlichen Bereich und Firmen fordern immer mehr die Zertifizierung nach bestehenden Normen.

P. Kiehl zufolge existieren für die Softwareentwicklung Normen

• zur Darstellung von Algorithmen und Programmabläufen
• zur Dokumentation der Programmentwicklung, von Programmen und Daten
• zu Gütebedingungen und Prüfbestimmungen für Software
• zum Qualitätsmanagement für Software
• zur Leistungsbewertung von Informationsverarbeitungssystemen. [Kiehl, 2001] ^[4]

Der fortschreitende Einsatz der Softwareentwicklung erfordert zusätzlich adäquate Werkzeugunterstützung beim Testen.

Die Ziele des Softwaretests sind:

• Fehler vor Produktiveinsatz finden und korrigieren
• Sicherstellen der angeforderten Funktionalitäten
• Kürzere Entwicklungszeiten
• Erhöhung der Planbarkeit (Termin und Kosten)
• Bessere Aufgabenverteilung
• Steigerung der ausgelieferten Qualität
• Reduktion der Fehlerfolgekosten

Testen führt nur dann zu einer Qualitätsverbesserung, wenn Fehler aufgedeckt und behoben werden. Ziel des Testens ist es, vorhandene Fehler zu finden und nicht die Abwesenheit von Fehlern zu zeigen. Ein vollständiger Test, der alle möglichen Eingabewerte und –kombinationen samt allen möglichen Randbedingungen und Ablaufpfaden berücksichtigt, ist jedoch aufgrund des Aufwands praktisch nicht durchführbar.

5.2 Einordnung von Test-Tools und warum überhaupt Tests automatisieren

Mit zunehmender Komplexität moderner Anwendungen, ist die Automatisierung von Tests immer mehr zu einer Programmierdisziplin geworden ^[5]. Unter Testautomatisierung wird verstanden, dass die „Verwaltung und Durchführung von Testaktivitäten einschließlich der Entwicklung und Ausführung von Testskripts zur Überprüfung von Testanforderungen mit Hilfe eines automatisierten Testwerkzeugs“ ^[6] erfolgt. In modernen Testteams gibt es die Rolle des Testautomatisierers. Dieser bringt sowohl Wissen aus dem Bereich Software Engineering als auch sehr gute Kenntnisse der eingesetzten Test-Tools und Programmiersprachen auf. Natürlich dürfen ihm auch ein solides Grundlagenwissen und Testerfahrung nicht fehlen ^[7].

Im Rahmen der Testautomatisierung werden verschiedene Test-Tools in Einsatz gebracht. Der Begriff Test-Tool definiert M. Pol wie folgt:

„Ein Testtool ist ein automatisiertes Hilfsmittel, das bei einer oder mehreren Testaktivitäten, beispielsweise Planung und Verwaltung, Spezifikation, Aufbau von Ausgangsdateien, Testdurchführung und Beurteilung, Unterstützung leistet.“ [Pol, 2000]^[8]

Durch den Einsatz von Test-Tools wird ermöglicht große Programmteile relativ schnell zu überprüfen. Automatisierte Testfälle sind unabhängig vom Fach- bzw. Anwendungswissen der Mitarbeiter ausführbar und somit auch langfristig wiederholbar. Bei Wiederholungstests ist es durch die Automatisierung sichergestellt, dass die Testfälle immer gleich und vollständig ablaufen. Weiter kann mehrmals in gleicher Qualität und Ablauflogik mit geringem Aufwand der entsprechende Testfall wiederholt werden.

Hier muss genau überlegt werden, ob manuell erstellte und umgesetzte Tests eingesetzt werden sollen, oder ob nicht software-gestützte Testaustomatisierungen effektiver wären.

Bei den manuellen Testausführungen führt der Tester die im Testfall beschriebenen Aktionen mit den vorgegebene Testdaten durch, nimmt alle beschriebenen Überprüfungen vor und protokolliert anschließend das Testergebnis und wertet dieses aus. Dadurch fließt das Fach- bzw. Anwendungswissen der Tester implizit in die Testläufe ein, ermöglicht aber Abweichungen vom Testpfad und Ableitung neuer Testfälle. Der gesamte Testprozess (Mitarbeiter, Testdatenbereitstellung, Testläufe, Testprotokollierung, Teststatistik usw.) wird manuell koordiniert und überwacht. Eine Gefahr bei der Durchführung von manueller Testausführung besteht darin, Fehlerdetails in der Masse der Testläufe zu übersehen.

Zusammenfassend die Vor- und Nachteile des Gebrauchs von Test-Tools nach M. Pol, [Pol, 2000]^[9]:

Vorteile:	Nachteile:
Eine umfangreiche Menge von Tests können ohne Kontrolle und automatisch durchgeführt werden, z.B. über Nacht. Dies gilt besonders für Regressionstests.	Die meisten kommerziell erhältlichen Werkzeuge sind sehr teuer.
Automatisierung von sich wiederholenden und oft lästigen Testaktivitäten führt zu höherer Zuverlässigkeit dieser Aktivitäten und zu höherer Zufriedenheit im Testteam, was wiederum zu höherer Produktivität führt.	Viele Testwerkzeuge erfordern viel Aufwand für den erfolgreichen Einsatz, und sind daher nur profitabel für große Projekte, oder für große Firmen mit vielen Projekten.
Testwerkzeuge sorgen dafür, dass die Testdaten bei aufeinander folgenden Tests die gleichen sind, so dass Gewissheit über die Zuverlässigkeit der Ausgangssituation und der Daten besteht.	Die Verwendung von Testwerkzeugen erfordert einen strukturierten Testprozess und viel Disziplin. Unternehmen, welche diese Kriterien nicht erfüllen, riskieren, ihre Marktsituation zu verschlechtern, indem sie teuer Werkzeuge kaufen und dann nicht einsetzen.
Werkzeuge können Fehler finden, die manuell nur schwer zu erkennen sind, z.B. memory leaks.
Das Erzeugen grosser Mengen an Testdaten kann automatisch mit Hilfe eines Testwerkzeugs erfolgen. Die Eingabe von initialen Daten muss lediglich einmal erfolgen und nicht bei jedem Test erneut.

Tabelle 1: Vor- und Nachteile des Gebrauchs von Test-Tools

5.3 Notwendigkeit von Test-Tools bei Software- Entwicklung

Im Gegensatz zu den manuellen Tests belastet der automatisierte Test die Mitarbeiter nicht, kostet keine direkte Arbeitszeit im Rahmen der Durchführung und ist von dem Fach- bzw. Anwendungswissen der Tester eher unabhängig. Die Testfälle können beschrieben werden und können außerhalb der Arbeitszeit systemisch durchgeführt werden. Der Initialaufwand bei der Planung von automatisierten Tests ist höher im Vergleich zu manuellen Tests, die Auswertung der Daten nach der Testdurchführung ist dann aber effizienter. Somit lohnen sich automatisierte Tests nicht immer - das Projektvolumen ent­scheidet mit über den Einsatz automatisierter Tests, da finanzieller und zeitlicher Aufwand für die Automatisierung von Tests in angemessenem Rahmen zum Gesamtvolumen des Projekts stehen müssen. Wegen der "Wiederholbarkeit" (Reproduzierbarkeit) und der geringeren Fehler-Quote werden automatisierte Tests im Rahmen von Regressionstests und bei größeren Softwareprojekten bevorzugt. Nicht automatisiert testbar sind Bereiche wie Usability oder Design einer Anwendung.

6 Arten der Kommunikation zwischen Tester und Entwickler

Immer komplexer werdende Softwareprojekte stellen zunehmend höhere Anforderungen an die Test- und Entwicklungsteams. Die zwei Teams sollen jederzeit über Änderungen von Projektinformationen benachrichtigt werden, um zeitaufwändige Recherchen zu vermeiden. Änderungen an der Projektdokumentation sollen einfach und von überall aus möglich sein. Die richtige Wahl der Kommunikationsinstrumente ist oft entscheidend für den Projekt-Fortschritt. Je nach Projektumfang und nach Art der miteinander kommunizierenden Menschen sind andere Instrumente (z.B. Telefon-/Videokonferenzen, persönliches Gespräch, Fax, E-Mail, etc.) entweder sinnvoll oder hemmend.

6.1 Persönliche Kommunikation

Unter „persönliche Kommunikation“ ist hier die „traditionelle“ Kommunikation zweier oder mehrerer Menschen in Form von Telefonaten, Gesprächen oder Austausch von handschriftlichen Notizen gemeint.

Die persönliche Kommunikation eignet sich vor allem bei

• hochdynamischen Projekten/Projektphasen, d.h. Projektsituationen mit sich ständig ändernden Rahmenbedingungen, bei denen ein permanent hoher Abstimmungsbedarf der Teammitglieder gegeben ist.

• Projekte mit hohem strategischen Wert für das Unternehmen, an denen ggf. auch Mitglieder der Geschäftsleitung beteiligt sind und in einem vergleichsweise hohen Grad der Vertraulichkeit unterliegen. In diesem Zusammenhang ist die Geheimhaltung einfacher zu gewährleisten und zu kontrollieren. ^[10]

6.1.1 Meetings / Workshops

Meetings und Workshops sind wichtige Elemente des Softwareentwicklungsprojektes. Sie dienen als Instrumente zur Koordinierung, Kontrolle und Motivation und erfüllen gleichzeitig eine Orientierungs- sowie eine Bewertungsfunktion.

"In einem Meeting oder in einer Besprechung kommen die Projektmitglieder zusammen, um sich gegenseitig zu informieren, konkrete, vorher bekannte Fragen und Probleme zu besprechen und Entscheidungen über die Fortführung der Arbeit zu treffen.

Workshops werden durchgeführt, um Ideen zu entwickeln oder Probleme zu klären. Die genaue Frage oder Problemstellung wird oft erst während des Workshops transparent." ^[11]

Die Ergebnisse des Meetings / Workshops werden in einem Protokoll festgehalten. Das Protokoll ist eine verbindliche Arbeitsgrundlage für alle Aktivitäten nach dem Meeting / Workshop.

Diese Art der Kommunikation eignet sich für die sogenannten „konventionellen“ Teams. Als konventionelle Projektteams werden Projektteams bezeichnet, die am selben Ort in denselben Organisation zusammenarbeiten und bei denen der Schwerpunkt auf der persönlichen Kommunikation liegt.^[12]

6.1.2 Story-Cards

Im Rahmen der Kommunikation zwischen Entwickler und Anwender ist es erforderlich, dass der Anwender dem Entwickler sagt, was mit welcher Funktion und welchem Ergebnis er gerne programmiert haben möchte. Zu diesem Zweck sollte der Anwender lernen Story-Card zu schreiben, die wiedergeben, wie die Abläufe für sein Problem aussehen. Diese Story-Cards werden aber nicht nur für das Programmieren neuer Funktionen eingesetzt, sondern auch um automatisierte Testfälle zu erstellen. Das Ergebnis dieser Tests soll dabei nicht direkt Fehler erkennen, die das Programm zum Absturz bringen, sondern eher Ablauffehler aufdecken. Bei diesen Fehlern wird nicht das ausgegeben, was eigentlich hätte herauskommen sollen. Somit sollte ein Test vom Anwender so konzipiert sein das er sagen kann: „Wenn diese Tests fehlerfrei laufen dann bin ich mir sicher, dass das System fehlerfrei läuft.“^[13] Was alles auf eine Story-Card gehört ist nicht genau festgeschrieben. Es ist eher eine Absprachezwischen Anwender/Tester und Entwickler. Mögliche Punkte die aufgenommen werden können, neben der Funktions- / Testbeschreibung sind:

• Titel
• Datum
• Autor
• Art der Karte (Fehlerbehebung, Refactoring, technische Anforderung, etc.)
• Akzeptanztest
• verantwortlicher Entwickler
• geschätzter und tatsächlicher Aufwand
• Datum der Fertigstellung ^[14]

Um die Verwendung etwas zu verdeutlichen hier mal ein Beispiel für die Erstellung eines Programms für die Erstellung von Netzplänen:
^[15]
Abbildung Nr.1 :Anforderung

6.1.3 Telefon / Telefonkonferenzen

Telefonkonferenzen (auch als Conference Calls bezeichnet) sind eine kostengünstige Alternative zu persönlichen Treffen und werden immer häufiger durchgeführt. Allerdings sind sie anstrengender als Präsenzmeetings, weil die Informationen ausschließlich akustisch ausgetauscht werden und die Teilnehmer sich stark konzentrieren müssen. Ein weiterer Nachteil der Telefonkonferenzen ist der fehlende Blickkontakt. Dies kann nun durch Videokonferenzen eliminiert werden.

6.1.4 Klassische textbasierte Kommunikationsformen

Zu den klassischen textbasierten Kommunikationsformen gehören Post, Brief, Fax, schwarzes Brett, regelmäßige Newsletter und Verteilermappen. Für größere Unternehmen und Projekte ist diese Art der Kommunikation zwischen den Teammitgliedern ungeeignet. ^[16]

6.2 Kommunikation per Software

Bei der Kommunikation per Software steht der Mensch-Computer-Kommunikation im Vordergrund. Die Kommunikation per Software eignet sich vor allem bei virtuellen Teams. „Von virtuellen Teams kann gesprochen werden, wenn ein Großteil der Mitglieder (mehr als 50%) dauerhaft räumlich und/oder zeitlich getrennt zusammenarbeiten und überwiegend elektronisch miteinander kommunizieren“ ^[17]

Ziel ist:

• eine schnellere und zuverlässige Kommunikation aller Mitarbeiter untereinander
• schnelleres Wiederfinden von Information
• höhere Sicherheit und weniger Verlust bei der Informationssicherung.

6.2.1 E-Mails (z.B. mit Outlook)

E–Mails sind mittlerweile das wichtigste Kommunikationsmedium im geschäftlichen Alltag und auch aus dem Projektalltag nicht mehr wegzudenken. Nicht an letzter Stelle wegen der einfachen Handhabung und schnellen Auslieferung. Bei der Kommunikation per E-Mail handelt es sich um eine "asynchrone" Kommunikation - die Information wird in einem Zeitpunkt verfasst und später vom Empfänger verarbeitet. Dadurch ist die Kommunikation per E-Mail tendenziell langsamer und für komplexe Geschäftsvorgänge nicht geeignet.

6.2.2 Knowledge Management Systeme

Knowledge Management Systeme werden im Projekt genutzt, um Wissen untereinander auszutauschen. Damit werden Netzwerke und Wissenslebenszyklen organisationsweit oder für jenen Teil der Organisation unterstützt, der von einer Wissensmanagement-Initiative fokussiert wird. ^[18] Schließlich geht es bei Wissensmanagement darum, innovative Einsatzmöglichkeiten von Informations- und Kommunikationstechnologien zu nutzen.^[19]

Folgende Systeme können im Rahmen des Informationsaustausches zwischen den Entwickler und Tester genutzt werden:

• Wiki
• Projektinfotheken (im Intranet oder webbasiert im Internet)
• Sharepoint

6.2.3 weitere Kommunikations- und Austauschinstrumente

Weitere Kommunikations-, Informations- und Austauschinstrumente sind z.B.:

• Foren
• Chats
• Workflow Management Systeme (z.B. von SAP, Lotus Notes, IBM)
• Messangers
• Skype / NetViewer
• RSS Feeds
• Podcast

7 Test-Verfahren und - Modelle

Innerhalb der Software Entwicklung durchläuft ein Programm verschiedene Phasen des Testens. Die Anzahl der Phasen hängt von der Größe des Projektes ab. Der hier gezeigte Ablauf veranschaulicht den einfachsten Fall in Anlehnung an die IEEE-Norm 1012-1986 („Software Verification and Valiedation Plans“). Innerhalb dieser Phasen ist der Anwender mehr oder weniger in die Tests involviert. Zu den Testphasen gehören das

• Modultesten
• Integrationstesten
• Systemtesten
• Abnahmetesten

Dabei wird in jeder Phase die folgenden Aufgaben durchgeführt:

1. Testplan erstellen
   Im Testplan wird das Ziel, der Umfang, die Testverfahren, die Ressourcen und der Zeitplan wann wer was testet festgelegt.
2. Testentwurf erstellen
   Im Testentwurf wird genau festgelegt wie die Ziele des Testplans erreicht werden sollen und ob das getestete Objekt den Test bestanden hat oder nicht. Ebenfalls wird definiert mit welchem Test genau jedes einzelne Testobjekt getestet wird
3. Testfallspezifikation
   In der Testfallspezifikation wird vereinbart mit welchen Eingaben der entsprechende Test durchgeführt wird und was für Ausgaben erwartet werden. Des Weiteren werden die Sonderanforderungen an die Software, wie Testhardware und Betriebssystem festgelegt.
4. Testvorgehensspezifikation
   In der Testvorgehensspezifikation wird die Reihenfolge der Tests, so wie die Art der Protokollierung des durchzuführenden Szenarios und dessen Ergebnis festgelegt.
5. Test Durchführung
   Die Tests werden durchgeführt und alle Unregelmäßigkeiten und Ergebnisse im Testbericht dokumentiert.
6. Testanalyse
   Bei der Testanalyse werden die Ergebnisse der Tests ausgewertet und entschieden ob der Test das gewünschte Ergebnis gezeigt hat oder ob der Test ein weiteres Mal durchgeführt werden muss^[20]

7.1 Dynamisches / Statisches testen

Beim Testen von Programmen werden die Tests mit bestimmten Test-Tools oder Methoden durchgeführt. Diese Tools oder Methoden werden in zwei Kategorien eingeteilt, den dynamischen und den statischen Tools.

7.1.1 Dynamische Tests

Beim dynamischen Testen wird ein Programm oder ein Programmteil während der Ausführung des Programms getestet. Dabei werden willkürliche oder gezielte Werte in das Programm eingegeben. Durch diese stichprobenartigen Eingaben kann die Anwesenheit von Fehlern nachgewiesen werden. Das Bedeutet allerdings nicht, dass nur weil kein Fehler beim Test gefunden wurde,dass das Programm fehlerfrei ist. Es schränkt lediglich die Wahrscheinlichkeit ein, dass ein Fehler im Betrieb auftritt. Alle Dynamischen Testverfahren besitzen die folgenden vier Eigenschaften:

• Es wird mit der kompilierten, ausführbaren Applikation getestet und in diese konkrete Eingabewerte eingegeben.
• Deser Tests kann im Produktivsystem des Kunden durchgeführt werden.
• Das dynamische Testen ist ein Stichprobenverfahren.
• Das dynamische Testen kann die hundertprozentich Fehlerfreiheit nicht beweisen.

Die Auswahl der für den Test verwendeten Eingaben, ist relevant für die relative Fehlerfreiheit. Um hundertprozentig sicher zu sein, dass ein Programm keine Fehler enthält, ist es erforderlich alle möglichen Eingaben (richtige und falsche) fortlaufend zu Testen. Diese Verfahren wird als "Erschöpfender Test" bezeichnet. Ein solcher Test ist auf Grund der vielen Kombinationsmöglichkeiten praktisch nur sehr selten durchführbar. Aus diesem Grund ist es erforderlich, dass die stichprobenartigen Tests mit repräsentativen, fehler intensieven, redundanzarmen und ökonomischen Eingaben durchgeführt werden. ^[21].

7.1.2 Statische Tests

Beim statischen Testen wird das Programm nicht ausgeführt. Die Tests des Programms werden anhand von angefertigten Grafiken oder Tabellen durchgeführt. Die Statischen Tests besitzen die folgenden Eigenschaften:

• Die Software wird beim Testen nicht als lauffähiges Programm ausgeführt.
• Bei jedem statischen Test ist kein PC erforderlich
• Es wirden keine Testfallszenarien für den Test erstellt.
• Nach der Durchführung des Tests kann das Programm immer noch fehlerhaft sein^[22].

7.2 Blackbox

Der Blackbox-Test oder auch Ein- / Ausgabe-Testen genannt, ist ein Testverfahren, bei dem der Tester ein Außenstehender ist, der nichts mit der Programmierung des Programm zu tun hat. Der Tester ist nicht mit den internen Abläufen des zu prüfenden Programms vertraut. Seine Aufgebe ist es, durch Eingaben und Ausgaben im Programm, Auffälligkeiten, die nicht den Spezifikationen des Programms entsprechen zu Tage zu fördern ^[23]. Ein Entwickler wäre mit seinem eigenen Programm viel zu schonend und würde ehr versuchen, einen Nachweis zu erbringen, dass sein Programm funktioniert, als bewusst Fehler zu finden, und diese preis zu geben. Das Finden von Fehlern ist somit elementar für den Tester. Somit gilt ein BlackBox-Test als gescheitert, wenn keine Fehler gefunden werden. Wenn beim Testen ein Fehler gefunden wird, dokumentiert der Tester den Fehler und auf welchem Weg er ihn produziert hat und lässt den Entwickler den Fehler klassifizieren und beheben.^[24] Um mit dem Blackbox-Test jeden möglichen Fehlerfall zu testen, wäre es erforderlich, alle Arten von Eingabekombinationen zu testen, die als maximale Eingabe erlaubt sind. Zu den erlaubten Eingaben müssten auch noch alle Arten von nicht erlaubten Eingaben getestet werden(z.B. Zahlen wo Buchstaben erwartet werden, etc.)^[25]. Da es viel zu aufwendig wäre dies alles durchzutesten, erstellt der Tester ein sogenanntes Test-Szenario.

Mit Hilfe des Pflichtenheftes des Kunden sowie mit dem Designkonzept der Entwickler, wird das Testkonzept gebildet. Im Testkonzept ist hinterleget was mit welchem Ziel getestet wird und wie etwas getestet wird. Ebenso wird definiert in welcher Reihenfolge bestimmte Module getestet werden und was für Ergebnisse hier erwartet. So darf z.B. das eine Modul nicht starten, wenn das Modul zuvor einen Fehler hat. Mit Hilfe des Testkonzeptes werden die Test-Szenarien gebildet^[26].

Ein mögliches Test-Szenario ist z.B. die Grenzwertmethode. Bei der Grenzwertmethode werden die jeweiligen Ober- und Untergrenzen der erlaubten Eingaben sowie die Ober- und Untergrenzen der nicht erlaubten Eingaben getestet. Die folgende Grafik soll dies etwas verdeutlichen: ^[27]

Abbildung Nr.2 :Grenzwerttest

7.2.1 Anwendertest

Beim Anwendertest wird das lauffähige Programm einer Gruppe von zukünftigen Anwendern bereitgestellt. Wie beim Blackbox-Test geben die Anwender willkürlich Werte ein und nutzen Funktionen oder testen ganz speziell bestimmte Bereiche. Mit Hilfe von ausgewählten Tools, werden dabei die Anschläge der Anwender aufgezeichnet. Die so durchgeführten Aktionen können dann bei Änderungen am Programm jederzeit automatisch wiederholt werden um zu testen, ob das Programm immer noch funktioniert. Änderungen wie das Umpositionieren von einzelnen Feldern können dabei in der aufgezeichneten Version korrigiert werden, so dass diese Tests weiterhin funktional bleiben^[28].

7.2.2 Akzeptanztest

Beim Akzeptanztest(High-Level-Test) setzen der Anwender, der im Normalfall der Kunde ist und der Hersteller der Software den BlackBox-Test ein um die Funktonalität der Software zu testen. Diese Tests werden unter realen Bedingungen ausgeführt. Das heißt mit der Hardware und dem Betriebssystem des Kunden oder einem Gleichwertigen^[29]. Grund für diesen Test ist aber nicht das primäre Finden von Fehlern, sondern die Prüfung ob die Software den Wünschen des Kunden entspricht, die im Pflichtenheft vereinbart wurden. Das Ergebnis wird in Prüfprotokollen festgehalten^[30].
Der Anwender testet dabei die Benutzbarkeit der Anwendung. Ein zukünftiger Systemadministrator überprüft hingegen die Widerherstellung nach einem Systemfehler, die Benutzerverwaltung, die Wartbarkeit und die Sicherheit des Programms.
Dieser Test ist sehr wichtig denn er hat rechtliche Relevanz, in wie weit der Vertrag zwischen Kunde und Hersteller efüllt wurde^[31].

7.2.3 Alpha-/ Beta-Test

Wenn Software nicht für einen bestimmten Kunden bestimmt ist, sondern vom Hersteller für den Massenmarkt konzipiert ist, gibt es keine dedizierten Anwender die die Software Testen können. Da einige Fehler nur im Betrieb auffallen werden Alpha- und Beta-Tests durchgeführt.

7.2.3.1 Alpha-Test

Der Alpha-Test wird beim Hersteller durchgeführt. Dafür werden oft spezielle Usability-Labors eingesetzt. In den Usability-Labors testen dann ausgewählte Anwender, die ein repräsentative Größe der zukünftigen Zielgruppe darstellen. Primäres Ziel ist nicht das Finden von Fehlern, sondern das Ausrichten der Software auf die angepeilte Zielgruppe^[32].

7.2.3.2 Beta-Test

Der Beta-Test wird beim Anwender durchgeführt. Hier gilt es Fehler zu finden auf den verschiedenen Umgebungen der Kunden. Da es hier um keine einheitliche Hardware und Software beim Kunden gibt, ist das Fehler finden zum Teil sehr aufwendig. Um Fehler etwas einzugrenzen, wird die Anzahl der User die am Beta-Test teilnehmen nur allmählich erhöht.
Die Phase bei der nur eine begrenzte Anzahl an Usern zugelassen wird, wird Close-Beta bezeichnet. Wenn gegen Ende der Beta-Phase eine unbegrenzte Anzahl an Usern zugelassen werden, wird dies als Open-Beta bezeichnet^[33].

7.3 Whitebox

„Ein Whitebox-Test prüft die innere Struktur eines Testobjektes auf Korrektheit und Vollständigkeit, d.h. die Systemstrukturen und Programmabläufe sind bekannt und der Programmcode wird analysiert.“ ^[34]. Dadurch, dass die innere Programmstruktur getestet wird, wird der Whitebox-Test auch innerer Test oder Strukturtest genannt.

Der Whitebox-Test wird meist von der Entwicklung durchgeführt. Die Testdurchführung kann aber auch von dem Testteam erfolgen, sofern die Tester den Programmcode verstehen und sich mit der verwendeten Programmiersprache auskennen. Dabei werden einzelnen Modulen, einzelnen Funktionen und Schnittstellen auf die Qualität des Quellcodes hin überprüft. Im Rahmen des Whitebox-Tests wird angestrebt möglichst alle Programmstrukturen zu durchlaufen. Bei diesem Testverfahren wird von einem „kontrollflussbezogenem Test“ gesprochen. Dabei wird versucht möglichst alle Datenklassen zu testen. Entsprechend wird diese Variante als „datenflussbezogener Test“ bezeichnet.

G. Thaller schreibt dazu: „Beim White Box Test liegt der Programmcode wie bei einer Landkarte offen vor uns. Wir können verfolgen, wie der Kontrollfluss des Programms verläuft. Wir sehen die Daten und die Auswirkungen beim Setzen gewisser Werte. Wir verstehen die Logik des Programms und können uns vorstellen, wie sich das Programm in einer bestimmten Situation verhalten wird.“ ^[35].

Sämtliche Module sowie Modulverbindungen werden, meist im Rahmen der Implementierung, einzeln getestet. Dabei wird sichergestellt, dass alle Anweisungen und Verzweigungen im Kontrollfluss mindestens einmal ausgeführt bzw. verfolgt werden. Eine vollständige Testfall-Abdeckung führt zu einer astronomisch hohen Zahl von Testfällen. Deswegen bietet sich der Whitebox-Test nur bei kleineren oder bei modular aufgebauten Programmen an. „Die Beurteilung der Korrektheit der erzeugten Ausgabewerte geschieht gegen die Spezifikation.“ ^[36] und stellt eine weitere Schwäche des White Box Tests dar - durch diese intensive Überprüfung kann nicht sichergestellt werden, ob das Programm mit der Spezifikation übereinstimmt. Fehlende Funktionen sowie Fehler in den Daten können nicht durch den Whitebox-Test aufgedeckt werden. So kann der Entwickler eine im Lastenheft beschriebene Funktion übersehen oder falsch verstanden haben. Des Weiteren können Tippfehler (Beispiel bei Vergleichsoperatoren - anstatt <= ein <) im Rahmen der Entwicklung entstehen, die durch den White Box Test nicht geprüft werden kann ^[37].

7.4 Graybox

Das Graybox Testverfahren setzt sich aus Merkmalen von Blackbox und Whitebox Test zusammen. Ähnlich dem Blackbox Test werden Korrektheit und Zuverlässigkeit der Ein- / Ausgabe von Programm oder Modul überprüft. Zum Auffinden und Auswerten der Testfälle wird der Sourcecode zurate gezogen, was der Whitebox – Anteil in diesem Testverfahren ist. Wie beim Blackbox Test üblich wird von der Kenntnis interner Abläufe und Strukturen ausgehend Testfälle, Risikobetrachtungen und Testmethoden entwickelt. Dazu werden Werkzeuge eingesetzt, die auch von Softwareentwicklern bei der Auffindung von Fehlerursachen in der Softwareentwicklung benutzt werden.
Diese dienen der Beobachtung von Vorgängen innerhalb der Software. Der Graybox- Test passt nicht in das mentale Modell von Black- und White-box Test:

• Software als Zusammenspiel vieler Komponenten betrachten
• Testfälle für Risiko-Komponenten entwickeln, alle anderen außen vorlassen
• Ausgehend von Vorstellung über Kommunikationswege und Nachrichtenaustausch

Der Graybox Test wird vorwiegend zum Testen von Software mit veränderlichen Umgebungsparametern verwendet, z. B.Webapplikation bei Unkenntnis über Existenz von Browsern, Clients und Servern testen, ohne die Kenntnis über eine Notwendigkeit von Verbindungen zwischen beiden Komponenten.

• Webapplikation wie Desktopanwendung betrachten.
• In Bezug auf mentales Modell andere Testfälle ableiten als bei Kenntnis der Funktionalität von Webapplikation.
• Fehler: Gesuchte und Fehler, die von Browser- Hersteller und Kommunikations- Anbieter zu beheben sind.

Wahl- Verfahren bei Rapid Application Testing beruht auf den Einsatztbereichen der funktionale Tests (Verfügbarkeit, Zuverlässigkeit, Performance, Belastbarkeit). „Gray-box testing consists of methods and tools derived from the knowledge of the applications internals and the environment with which it interacts, that can be apllied in black-box-testing to enhance productivity, bug finding and bug analysing efficiency.“^[38]

7.5 Checklisten

In der Checkliste wird ein bestimmter Testfall beschrieben. Dabei enthält der Testfall im Wesentlichen Aussagen darüber:

• was getestet werden soll / welches Ziel hat der Test

• eine Beschreibung dessen, was zu tun ist (Der Ablauf jedes Testfalls ist so beschreiben, dass der Tester weiß, was er konkret tun soll.)

• welche Ergebnisse erwartet werden.

Zusätzlich kann eine Checkliste Informationen über Ansprechpartner, betroffene Systembereiche und Testfall-Nummern enthalten. Die Checklisten werden in der Regel vom Testteam entworfen und bearbeitet. Pro Checkliste/Anwendungsfall müssen genügend Testfälle zur Überprüfung aller Normal-, Sonder und Fehlerfälle vorhanden sein. Die einzelnen Testfälle werden nach den Integrationsschritten gruppiert, nach deren Abschluss sie durchgeführt werden sollen, und detailliert beschrieben. Im Anschluss erfolgt die Dokumentation der durchgeführten Testfälle und ihrer Ergebnisse. Der Tester protokolliert welche Eingabedaten konkret verwendet wurden, ob im Rahmen der Durchführung des Tests ein unerwartetes Systemverhalten beobachtet wurde, welche Probleme aufgetreten sind und welche Korrekturen in diesem Zusammenhang vorgenommen werden sollen.

7.6 Last- / Nutzer-Test

Lasttests dienen der Analyse der Verarbeitungsdauer von Anfragen eines Programms bei steigernder Systemlast. Diese Tests gehören zu den Performancetests. Die steigende Systemlast wird durch die Anzahl der zeitgleich agierenden Benutzer, der Größe der zu bearbeitenden Dateien, Anzahl der Datensätze oder Ähnlichem beeinflusst.^[39]

7.7 Performance-Test

Um herauszufinden wie schnell ein Programm eine Aufgabe bearbeitet, werden Performancetests durchgeführt. Hauptziel ist die Ermittlung der Verarbeitungsgeschwindigkeit aller Programmteile und ob diese annehmbar ist. Meist sind Performancetests Teil der Endabnahme eines Programms, wenn die Performance Teil der Anforderungen des Programms war.
Performancetests eignen sich zudem auch als Regressionstests.

Performancetests können meist gut automatisiert werden. Gerade wenn ein Performance-Vergleich zwischen verschiedenen Systembedingungen erfolgen soll und eine Benutzeroberfläche Teil des Tests ist, lohnt sich die Automatisierung. Durch Capture & Replay, Aufzeichnen und Abspielen von Aktionen von Benutzern bei einem Test können unterschiedliche Reaktionszeiten unterbunden werden.^[40]

7.8 Rückfall-Test / Regressions-Test

Als Regression (Rückschritt) wird eine Verschlechterung der Funktion eines Programms nach Änderung oder Erweiterung bezeichnet. Mit Regressionstests sollen mögliche Verschlechterungen aufgespürt werden. Es soll primär sichergestellt werden, dass alle bestehenden Funktionen weiterhin fehlerfrei arbeiten und bereits behobene Fehler in späteren Programmversionen nicht erneut auftreten. Die Regressionstests sollten nach jeder Änderung oder vor einer Freigabe erfolgen. Das Potenzial für eine Automatisierung ist sehr hoch, aber nicht immer von Vorteil, da automatisierte Regressionstests schnell unbrauchbar werden.

Gute Regressionstests umfassen eine große Anzahl externer und interner Programmfunkionen. Diese Tests sind breit angelegt. Sehr gut eignen sich Stichprobentests mit grosser Menge an validierten Eingabedaten als Regressionstests. Bereits erfolgreich behandelte Daten bei vorherigen Programmversionen müssten bei neueren Versionen auch anstandslos bearbeitet werden. Bei erfolgloser Verarbeitung werden wichtige Informationen zu den möglichen Programmfehlern generiert.

Performancetests eignen sich auch als Regressionstests. Verlängert oder verkürzt sich die Ausführungszeit von im Vorfeld bereits getesteter Transaktionen auf dem gleichen Rechner, so sollten diese Programmteile erneut angesehen und gegebenenfalls korrigiert werden..^[41]

7.9 Stress-Test

Der Stresstest gehört zu den Funktionstests. Hierbei wird die Reaktion eines Systems auf außergewöhnlich hohe Belastungen analysiert. Gerade bei Applikationen mit vielen Dialogprogrammen kann der Stresstest relevante Ergebnisse liefern. Das System wird mit einer Vielzahl des errechneten Maximums an parallelen Dialogen belastet und so geprüft, ob die Applikation dicht aufeinanderfolgende Aktionen bearbeiten kann oder nicht.
Ziele sind dabei die Verifizierung der Software, Nachweis der richtigen Komponentenfunktionalität, Belastbarkeitsanalyse des Systems und die Fehlererkennung vor Programmfreigabe.

8 Test-Tools

Jahrelang wurde Fehlerverwaltungssoftware fast ausschließlich von großen Softwarefirmen verwendet. Stattdessen erfolgte die Kommunikation einfach per E-Maillisten und E-Mails zur Verfolgung der Fehlerstati. Diese Verfahrensart birgt großes Risikopotenzial und führt oft dazu, dass Fehler, die von den Entwicklern als unwichtig angesehen werden, vergessen oder ignoriert werden.

8.1 Bug Tracking Tools

Fehlerverfolgungssysteme ("Bug-Tracking Systems") erlauben es einzelnen oder ganzen Gruppen von Entwicklern effektiv ausstehende Probleme der eigenen Produkte zu verfolgen.
Wenn von einem "Bug" gesprochen wird, ist ein Fehler im Computerprogramm gemeint. Bugs können Probleme in Software oder Hardware verursachen und schlimmstenfalls das ganze System zum Absturz bringen. "Bug" kommt aus dem Englischen und bedeutet ursprünglich "Käfer", "Wanze" oder "Motte". Das Entfernen oder Beheben eines solchen "Bugs" wird als "Debugging", also "Entmotten" oder "Fehler beheben" bezeichnet.

Integrierte Fehlerverfolgungssysteme helfen die Ausfallzeiten zu verkürzen, die Produktivität und die Benutzerzufriedenheit zu steigern. Mit Hilfe eines Fehlerverfolgungssystems ist es den Entwicklern möglich, während des gesamten Entwicklungsprozesses mit Testern und Endnutzern in Verbindung zu stehen und so jederzeit auf Probleme und Wünsche dieser eingehen zu können.
Diese Art der Fehlerverfolgung hat Kostensenkungspotential. Durch eine umfassende Protokollierung von IT-Support, der Erstellung und Bereitstellung einer Wissensdatenbank für eine interne Telefon-Hotline oder einer einheitlichen, intuitiven Dokumentation ungewöhnlicher System- oder Softwareprobleme kann unternehmensweit auf Fehler und Probleme eingegangen und reagiert werden.

8.1.1 Bugzilla

Bugzilla gehört zu den Fehler- oder Problem-Verwaltungsprogrammen und ist ein skalierbares Bug Tracking Tools, es ist somit eine an Änderungen anpassungsfähige Software. Diese Tools erlauben es einzelnen Personen oder Entwicklergruppen, ungelöste Probleme oder Verbesserungsvorschläge zu verfolgen.

Terry Weissman schrieb Bugzilla in der Programmiersprache TCL, um die rudimentäre Fehlerdatenbank zu ersetzten, die intern von Netscape Communications benutzt wurde. Später wurde Bugzilla nach Perl portiert. Bugzilla ist ein OpenSource- Tool und heute das de-facto-Standard-Fehlerverwaltungssystem, mit den alle anderen verglichen werden.

Bugzilla wird ständig weiterentwickelt und beinhaltet wichtige und hilfreiche Funktionen, wie zum Beispiel:

• Integrierte und produktspezifische Sicherheitsprozeduren
• Abhängigkeiten zwischen Fehlern (Bugs) und Erstellung von Abhängigkeitsgraphen (deren graphische Darstellung)
• Erweiterte Funktionen für die Erstellung vollständige Änderungsaufzeichnung in Form von Berichten
• Ein robustes und stabiles RDBMS(Relational Database Management System)-System
• Weitreichende Konfigurationsmöglichkeiten
• Ein sehr gut verständlicher und durchdachter Lebenszyklus der "Fehler"
• Web-, E-Mail-, XML-, Konsolen- und HTTP-Schnittstellen
• Integrationsmöglichkeit in ein automatisches Software-Konfigurationssystem dank seiner Perforce- und CVS-Unterstützung (durch die Bugzilla-E-Mail-Schnittstellen und die Check-in/Check-out-Skripte)

• Eine leistungsstarke Suche
• Leichtes Aktualisieren auf neue Versionen
• Vollständige Sicherheitsüberprüfung und Nutzung den taint-Modus von Perl
• Vollständig anpassbare und/oder lokalisierbare Web-Benutzerschnittstelle

Bugzilla ist sehr flexibel und an verschiedenste Situationen anpassbar.
Mögliche Anwendungsbeispiele sind der Einsatz für Ticketsysteme im IT-Support und als Systemadministrations- und Systemverteilungsmanagement- Tool. Des Weiteren wird Bugzilla für die Fehlerverfolgung während Entwurf und Entwicklung von Computer-Chips (vor und nach der Herstellung) eingesetzt und viele renommierte Marktführer im IT- Bereich, wie zum Beispiel Redhat, Loki-Software, Mandriva und VA-Systems, nutzen Bugzilla für die Software- und Hardwarefehlerverfolgung.

Bugzilla stellt in Kombination mit Systemen wie CVS, Bonsai oder auch Perforce SCM eine einfach zu nutzende und leistungsstarke Lösung für das Konfigurationsmanagement und Reproduktionsprobleme dar.

Bugzilla ermöglicht es die Produktivität und Verantwortlichkeit einzelner Angestellter dramatisch zu steigern. Mit Hilfe eines dokumentierten Arbeitsablaufs(Workflow) können positive Rückmeldungen für das Geleistete weitergegeben werden.
„Wie oft sind Sie schon am Morgen mit dem Gedanken aufgewacht, welche Pläne Sie sich für heute vorgenommen haben - aber Sie konnten sich nicht mehr daran erinnern? Planen Sie einfach mit Bugzilla und Sie haben einen Eintrag, mit dem sie Ihre nächsten Meilensteine bestimmen können, die Integration neuer Produktversionen festlegen und durch Benutzung der Bugzilla E-Mail-Integration kritische Entscheidungen in verschiedenen Diskussionen verfolgen können.“^[42]

8.1.2 Jira

JIRA ist ein Software-Tool, das für Fehlerverfolgung, Änderungsmanagement und Projektmanagement in Software-Entwicklungsprojekten eingesetzt werden kann. Es ist funktional und einfach gestaltet, so dass es sofort und flexibel einsetzbar ist. JIRA gehört zu den Bug Tracking Tools, wird aber auch den Issue Tracking und Project Management Tool zugeordnet.

Es gibt drei Versionen von JIRA, bei allen sind die grundsätzlichen Funktionen eines Bug-Trackers eingebunden.
Dazu gehören Funktionen wie eine gut überlegte und intuitiv nutzbare Benutzeroberfläche (hier ein Web-Interface), so dass Sie sofort mit JIRA arbeiten können. Alle Vorgänge sind übersichtlich angeordnet und Informationen befinden sich genau dort, wo sie benötigt werden: sortiert nach Projekten, Komponenten oder Versionen. JIRA ist ein sehr leistungsstarkes, leicht integrierbares Programm und lässt sich optimal an das jeweilige Unternehmensumfeld anpassen. Durch die einfach strukturierte Weboberfläche ist JIRA selbst für Laien leicht verständlich und ein hilfreiches Werkzeug im täglichen Gebrauch.

Funktionen:

• Einfach zu erstellende Suchabfragen für alle Vorgänge
• Wieder verwendbare Abfrage-Filter
• E-Mailversand der Abfrageergebnisse in verschiedenen Dokument-Formaten
• Vorgänge sind miteinander im gesamten Projekt dynamisch verlinkbar
• Vorgänge können untergeordnete Teilvorgänge haben
• Alle Informationen auf einen Blick (dynamisch konfigurierbar)
• Frei definierbare Felder, Eingabemasken und Workflows
• Offene bidirektionale Schnittstellen zu gängigen Formaten (Excel, Word, PDF, CSV, XML, E-Mail u.v.m.)
• Flexibilität durch Bereitstellen verschiedener Interfaces zur Integration innerhalb Ihres Intranets (SOAP, XML-RPC, REST u.s.w.)

JIRA ist nicht mehr nur ein Bug-Tracking-Tool. Mittlerweile ist JIRA mit einem Funktionsumfang ausgestattet, der es ermöglicht den gesamten Entwicklungsprozess - angefangen bei der Planung und Aufgabenzuweisung, über Zeiterfassung und Berichte, bis hin zu Fehlern und Bugs abzudecken.
Entwickler können direkt, zum Beispiel aus Eclipse oder IntelliJ IDEs, Fehler einordnen oder Aufgaben zuordnen und aktualisieren. Der gesamte Quellcode, Anwendungen und Wiki-Seiten können direkt mit den JIRA-Issues verbunden werden. Mit einer vergleichsweise riesigen Auswahl an verschiedenen Plugins ist JIRA als ein sehr leistungsfähiges und agiles Projektmanagement-Tool verwendbar.

8.1.3 Mantis

Mantis ist ein Web-basiertes Bug-Tracking-Tool. Es ist ein in PHP geschriebenes Open-Source-Computerprogramm und unterstützt eine Vielzahl an Datenbanken wie MySQL, MS SQL, PostgreSQL and DB2.
Es wird zur Verwaltung und Verfolgung von Hinweisen auf Programmfehler (englisch: bug reports ) und von Feature-Requests (Wünschen nach zusätzlichen Funktionen) eingesetzt.

In Mantis wird jeder Problembericht einem von mehreren, vom eingebauten Workflow vorgegebenen Zustand zugeordnet (z. B. Neu, Zugewiesen, Behoben, Geschlossen). Für Zustandsänderungen werden entsprechende Zugriffsrechte benötigt.

Während des Lebenszyklus eines Fehlerberichts ist es allen berechtigten Projektteilnehmern zu jedem Zeitpunkt möglich, Kommentare zu einem Bericht hinzuzufügen. Das System verlangt bei jeder Zustandsänderung erläuternde Kommentare, so dass die Bearbeitung jedes Problems per zugehörigem Bericht gut nachvollziehbar ist.

Mantis bietet einen großen Umfang an Filtermöglichkeiten, um die wichtigste Funktion eines Bug-Trackers zu gewährleisten: Es wird eine Übersicht über anstehende und behobene Fehlerberichte und ein Überblick über den Gesamtzustand eines Projekts ermöglicht.

Der Projektmanager kann zu jeder Zeit umfangreiche Statistiken über das Projekt abrufen.

Mantis ermöglicht mit automatischen oder von Projektteilnehmern eingestellten Erinnerungen (per E-Mail) eine gezielte Kommunikation innerhalb eines Projekts.

8.2 Issue-Tracking Tools

Ein Issue-Tracking-System oder auch Ticket-System oder kurz TTL genannt, ist ein System zum erfassen von Störungen. Es wird normalerweise in Callcentern oder Helpdesks eingesetzt um Abläufe zu dokumentieren. Das Prinzip ist wie bei einem Laufzettel. Eine Person meldet ein Problem, eine Neuerung oder ein Änderungswunsch bei einer zuständigen Stelle an. Diese Stelle erfasst dann ein sogenanntes „Ticket“. Das Ticket entspricht dem Laufzettel, nur eben in elektronischer Form. Innerhalb des Tickets werden erforderliche Daten erfasst, die für die Bearbeitung des Tickets benötigt werden. Dazu gehört im Normalfall auch immer die Dringlichkeit der Störung um Sie entsprechend zu eskalieren und ausreichend Ressourcen in die Bearbeitung zu investieren. Nach der Erfassung wird das Ticket an eine mögliche Person weitergegeben, die zur Lösung des Problems beitragen kann. Diese Person dokumentiert Ihre bearbeitungsschritte im Ticket und reicht das Ticket an den nächsten weiter, wenn das Problem noch nicht gelöst wurde. Wurde das Problem behoben, wird das Ticket geschlossen. Auf diese Weise wird der gesamte Bearbeitungsprozess dokumentiert und die Zusammenarbeit der verschiedenen Mitarbeiter, die eventuell auch noch in verschiedenen Bereichen arbeiten, koordiniert. Somit können verschiedene Spezialisten die sich in ihrem Bereich gut auskennen ihr Wissen einbringen und jeder kann nachvollziehen, was bereits durch den oder die vorherigen Mitarbeiter versucht, verändert oder behoben wurde^[43].

Wenn die Informationen im System sauber dokumentiert sind kann das Ticket System mit der Zeit auch als Wissensdatenbank genutzt werden. Tritt ein Fehler ein weiteres mal auf, so kann im Ticket in Erfahrung gebracht werden wie das Problem beim letzten mal behoben wurden und so schneller bearbeitet werden^[44].

8.2.1 JFire

JFire ist ein Open Source ERP-Projekt. Es wurde für mehrere Sprachen erstellt und soll sowohl für Große als auch für kleine Firmen geeignet sein. Durch eine Vielzahl an unterschiedlichen Modulen, bietet es ein breites Funktionspektrum. Das Programm besteht aus einer Client / Server-Komponente. Der Client sowie der Server wurden vollständig in Java erstellt. Somit ist diese Software Plattform unabhängig und läuft sowohl auf Windows als auch auf Unix Systemen problemlos. Der Anwender kann auf dem Server per Webinterface arbeiten oder mit der Clientsoftware. Die Clientsoftware basiert auf dem Eclipse RCP (Rich Client Plattform) die auch von anderen Programmen als Client verwendet wird und somit eine Suite verschiedener Anwendungen auf dem Client bereitstellen kann.

Innerhalb des JFire gibt es ein Modul für das Issue-Tracking-System. Dieses Tool wird auch selber von JFire zur Bearbeitung von Fehlern und Wünschen der Anwender eingesetzt.

Als Informationen können standardmäßig Informationen wie:

• Ticket-Ersteller
• Ticket-ID
• Kategorie
• Reproduzierbarkeit
• aktueller Bearbeitungsstaus
• Priorität
• etc.

erfasst werden. Nach Bedarf können auch eigene Auswahlfelder oder frei formulierbare Felder erstellt werden. Die Informationen zu den Tickets werden nach Bedarf allen oder nur bestimmten registrierten Anwendern bereitgestellt. Dies sichert den Datenschutz der preisgegebenen Informationen. Wird dieses Tool in Verbindung mit anderen Modulen von JFire eingesetzt, können die Information untereinander verlinkt werden. Wird JFire in einer Software Entwicklungsfirma eingesetzt, so kann ein Auftrag vom Kunden für die Erstellung der Software erstellt werden. Ist die Software entwickelt worden und wird bei Kunden als Beta getestet, so kann zu jedem Fehler ein Ticket über den Auftrag erstellt werden. Das vereinfacht für den Entwickler die Zuordnung des Fehlers zum entsprechenden Projekt.

Durch Verwendung verschiedener Ansichten und Farben ist dieses Tool sehr übersichtlich und bietet durch den Open Source Charakter viele Möglichkeiten zu Individualität und Anpassung an die eigenen Bedürfnisse. Das macht das Tool vielfälltig einsetzbar^[45].

8.2.2 Open Ticket Request System

Open Ticket Request System(OTRS) ist ein Open Source Issue Tracking System, das für alle Arten von HTML basierten Browsern erstellt wurde. Es wird in Gänze auf JavaScript, Flash und Java Applets für die Webseite verzichtet, um einen problemlosen Zugriff von PC oder Handy zu ermöglichen. Als Plattform für den Server kann sowohl Windows als auch Unix eingesetzt werden. Ebenfalls steht eine große Auswahl an möglichen Datenbanken für das System bereit. Dazu gehört z.B. Oracle, Mysql oder Postgres. Der Melder sowie der Bearbeiter eines Tickets kann sich über ein Webinterface anmelden um das System zu nutzen. Der Melder hat zusätzlich die Möglichkeit ein Ticket per E-Mail, SMS oder FAX auf zu geben. An das Ticket können Daten angehängt werden, wie z.B. Screenshots oder Bug-Tracking-Reports. Eine erfasste Störung bekommt eine Ticket-ID, die das Ticket eindeutig identifiziert. Somit kann der Melder durch Angabe seiner Ticket-ID sein Ticket schnell wiederfinden. Den aktuellen Status eines Ticket kann der Melder jederzeit über das Webinterface abrufen. Somit ist er ständig informiert was mit seinem Ticket passiert bzw. was bisher schon unternommen wurde.

Das Webinterface steht in mehreren Sprachen zu Verfügung, um einen mehrsprachigen Kundenkreis bedienen zu können. Die erstellten Tickets werden manuell oder automatisch an die Entsprechende Queue weitergeleitet. Eine Queue ist ein Arbeitsbereich der Firma, wie z. B. Entwicklung, Design, Support, etc. Zu jeder Queue gehören Mitarbeiter der Abteilung. Die Mitarbeiter werden Agent genannt. Ein Agent kann zu mehreren Queues gehören.

Der Agent kann das Ticket bearbeiten und dann weiterleiten oder das Ticket schließen. Auch ein Zusammenlegen von Tickets ist möglich, wenn z.B. mehr als ein Melder den gleichen Bug hatten und diesen Fehler unabhängig voneinander melden, so können diese Tickets zu einem Ticket vereint werden, so das nicht mehrere Entwickler an dem gleichen Problem arbeiten. Ebenfalls eine nützliche Funktion ist das Sperren eines Tickets wehrend der Bearbeitung durch einen Agent. Somit kann nur ein Agent das Ticket editieren.

Um sicherzustellen das ein vom Kunden erstellte Ticket nicht untergeht wird eskaliert. Das bedeutet, dass bei Tickets bei denen, die

• Reaktionszeit (Zeit bis zum ersten reagieren durch eine Zuständige Person)
• Updatezeit (Zeit zwischen einer Änderung am Ticket z.B. Bearbeitungsschritt, Weiterleitung, etc.)
• Lösungszeit (Zeit von der Aufnahme bis zum Abschluss des Tickets)

ein bestimmten Zeitraum überschritten haben, eine Nachricht an alle Personen der Queue geschickt wird. Nach einer noch längeren Zeit könnte dann z.B. eine E-Mail an den Abteilungsleiter versendet werden. Besonders die Reaktionszeit kann bei einigen Supportverträgen wichtig sein, die ein Reaktionszeit von z.B. 4 Stunde beinhalten. Ein Vertragsbruch durch nicht reagieren kann teuer werden und sollte somit nicht vorkommen.
Bei Problemen mit OTRS selber steht eine große Community bereit, sowie ein kostenpflichtiger Support durch die Hersteller von ORTS selber. Erweiterungen für diese Software werden ebenfalls durch die Community bereitgestellt. Dies ist möglich, da der Sourcecode frei heruntergeladen und verändert werden kann. Die Möglichkeit über den Hersteller gegen Bezahlung Features oder Änderungen programmieren zu lassen besteht auch^[46].

8.2.3 Request Tracker

Request Tracker (RT) ist ein in Perl geschriebenes Open-Source Trouble-Ticket-System. Es dient der Koordinierung und Anfragenbearbeitung (Trouble-Tickets) per E-Mail.
Durch die Umsetzung in objektorientiertem Perl ist das Tool durch manuelle Erweiterung weitestgehend an eigene Bedürfnisse und Anforderungen anpassbar und um weitere Funktionen erweiterbar. Der Entwickler Jesse Vincent hat dazu extra ein FAQ-Manager-Modul mit Namen RTFM (RTFaqManager)geschrieben, dessen Kürzel stark an „Read the fucking manual“ (Deutsch: „Lies das verdammte Handbuch“) anspielt.

RT ist eine große Hilfe bei der Verfolgung von Aufgaben, der Lösung von Problemen, Wissensgenerierung und der Zusammenarbeit im Unternehmen:

• Es bietet einfache Möglichkeiten der Zustimmung, Fallweitergabe, Priorisierung, Suche, Eskalation und ein Berichtswesen
• Zu jedem Ticket werden alle relevanten Daten und Metadaten gespeichert
• Mehrere Projekte können parallel von mehreren Teams bearbeitet werden
• Ähnlich einem Projektmanagementtool können Maßnahmen, Termine und Zeitvorgaben eingestellt werden
• Das intuitiv zu nutzende Web-Interface beinhaltet eine leicht bedienbare Suche, die Endnutzern die Erstellung komplexer Abfragen durch Drag & Drop ermöglichen

Beispiel:

• Ein Benutzer sendet per E-Mail eine Anfrage an RT
• RT schickt per E-Mail eine Kennung zurück, auf die der Benutzer in der weiteren Korrespondenz Bezug nehmen kann.
• gleichzeitig sendet RT die Anfrage des Benutzers an die Bearbeiter
• ein Bearbeiter beantwortet die Anfrage, die Antwort wird von RT archiviert und an den Benutzer weitergesendet.

Der RequestTracker von NETWAYS basiert auf der Open Source dem Request Tracker von Jesse Vincent (Bestpractical).

Das Tool ist ein leistungsfähiges Business Tracking System. Es ermöglicht eine einfache Nachverfolgung von Anfragen, Fehlermeldungen oder E-Mails und beschleunigt die Kommunikation zwischen Mitarbeitern und Kunden.

• Historie der gesamten Kommunikationsvorgänge
• Aufgaben können zusammen mit wichtigen Informationen zugewiesen werden
• Details der Korrespondenz können jederzeit nachvollzogen werden
• technischen Kundendienst und Helpdesk vereinfachen
• interne Workflows standardisieren
• Software Bugs tracken
• Marketing Leads nachverfolgen
• Webinterface
• E-Mail Interface
• Dank vieler Erweiterungen an jeweilige Anforderungen anpassbar

Einsatzmöglichkeiten:

• Trouble Ticketing
• Helpdesk
• IT Support
• Lead Tracking
• Workflowmanagement
• Projectmanagement
• Internes Procurement
• Störungsmanagement

Abbildung Nr. 17: Anfrageverarbeitung

Beispiel: Anfrageverarbeitung

Eine Kundenanfrage erzeugt im System ein sogenanntes Ticket. Dieses Ticket bekommt eindeutige Kennnummer. Bearbeitet ein Mitarbeiter dieses Ticket oder stellt eine Rückfrage, wird diese Nummer kodiert mit der ausgehenden E-Mail verschickt. Antwortet der Kunde auf diese E-Mail, kann das System aufgrund der Ticketnummer die E-Mail der ursprünglichen Anfrage zuordnen.
Per Eingabe der Ticketnummer in die Weboberfläche kann der Bearbeiter alle Informationen des Vorgangs direkt einsehen.

Die Absenderadresse aller ausgehenden E-Mails ist eine allgemeine Adresse des Systems. Antworten von Kunden werden direkt dem System zugestellt. So kapselt der RequestTracker alle Kommunikationsvorgänge. Der zuständige Bearbeiter kann wechseln ohne dass der Kunde etwas mitbekommt.

Beispiel für einen Workflow

• Ein Kunde schreibt eine E-Mail an die Adresse support@ihre-firma.de und schildert ein Problem oder stellt eine Anfrage.
  
• RequestTracker speichert diese Anfrage in seiner Datenbank und schickt dem Kunden eine Eingangsbestätigung inkl. einer Vorgangsnummer, auf die der Kunde in seiner weiteren Korrespondenz zu diesem Thema verweisen kann.
  
• RequestTracker leitet die Anfrage an die zuständigen Mitarbeiter weiter.
  
• Ein Mitarbeiter weist sich die Anfrage selbst zu und beantwortet die Fragen des Kunden.
  
• Die Antwort wird automatisch in der Datenbank gespeichert und anschließend an den Kunden weitergeleitet.
  
• Anschließend kann der Mitarbeiter die Anfrage als erledigt markieren."^[47]
  

8.3 Vor- und Nachteile der Bug Tracking- und Issue Tracking Tools

Wie in Kapitel 8.1 beschrieben wird mit der Hilfe von Issue- und Bug-Tracking sowohl Anforderungs-, Änderungs und Fehlermanagement betrieben. Die Erfassung, Verwaltung und systematische Verfolgung aller Issues/Bugs stellt einen Grundpfeiler für erfolgreiches Projekt- und Organisationsmanagement dar.

Neben der zahlreiche Vorteile wie z.B. die Verbesserung der Kundenkommunikation zwischen den Beteiligten bieten die Issues- und Bug-Tracking-Tools auch nennenswerte Nachteile.

Vorteile	Nachteile
Einheitliches System für Änderungsvorschläge, Erweiterungen und Fehlerbehandlungen	Schulungen der Mitarbeiter und der Kunden
Automatisches Feedback nach Fehlerbehebung an Projektleiter, Entwickler, Testabteilung und an Kunden	Kosten durch Infrastruturbereitstellung und Support
Statusabfrage per Web-Interface	Kosten für Erweiterungen oder Individualisierung von Software
Klar geregelte Struktur der Abläufe	Akzeptanz der Anwender nicht immer gegeben
Aufbau einer Wissensdatenbank	Blindes Vertrauen in bereits erprobte Verfahren
Zielgerichtete und organisierte Kommunikation zwischen Anwendern	Abhängigkeit von der Software
Zentrale Fortschrittskontrolle und Terminübersicht	Übergangsphase während Softwareeinführung unkoordiniert
Analyseoptionen für Controlling	Doppelte Erfassung von Anfragen während Enführungsphase der Software

Tabelle 2: Vor- und Nachteile der Bug Tracking- und Issue Tracking Tools

8.4 Ablauf eines Test-Szenarios

Es gibt verschiedene Test-Tool um einen Bug, einen Verbesserungsvorschlag oder eine Anregung zu erfassen. Dabei ist der Ablauf immer gleich:

• der Kunde findet einen Bug und meldet diesen an das Callcenter
• der Tester findet einen Bug z.B. beim Regressionstest und meldet diesen an die Entwicklung.
  
  

Der Prozess kann sowohl vom Kunden als auch vom Tester initiiert werden. Die Bugs werden erfasst (Issue-Tracking-System oder Bug-Tracking-Tool) und von der Entwicklung bearbeitet. Anschließend erfolgt die Rückmeldung an den Kunden bzw. an den Tester.

Im Jahreswechsel ist es zu einem großen Fehler bei einem Teil der Kunden der Sparkassen, Privatbanken und Landesbanken gekommen. Durch einen Programmierfehler in den EMV-Chips der in den EC- und Kreditkarten verbaut ist, konnten 30.000.000 Kunden kein Geld an Geldautomaten abholen. Ebenso ging das Zahlen per Karte an 200.000 Kartenterminals nicht. Das Problem entstand durch einen Fehler der dafür sorgte, dass die Geräte nicht mit der Jahreszahl 2010 zurechtkamen^[48][49].
Anhand dieses Beispiels soll der grobe Ablauf der entdecken und beheben des Fehlers bei der Sparkasse gezeigt werden. Die Sparkasse wird hier als Beispiel verwendet, da Sie sich eines Issuetracking Systems zur Fehlerbearbeitung bedienen^[50].

Die Abläufe nach der Erfassung werden aus den Standardabläufen in Unternehmen hergeleitet und müssen nicht auf die Sparkasse zutreffen:

Beim Versuch mit der EC-Karte zu bezahlen oder Geld am Automaten abzuheben wird ein Fehler vom Kunden festgestellt. Durch die Meldung an das Callcenter der Sparkassen bzw. durch melden an die Mitarbeiter der Sparkasse in den Kundencentern, wird der Fehler im Issuetracking System erfasst und weitergegeben. Ein zuständiger Mitarbeiter versucht den Fehler nachzustellen und eine Lösung für das Problem zu finden. Ist der Fehler lokalisiert worden, wird eine Lösung für das Problem gesucht und der Fehler behoben. Anschließend wird die Änderung getestet ob durch die Fehlerbehebung keine weiteren Fehler entstanden sind. Der Kunde wird über die Bearbeitung und die Lösung des Problems informiert.

Abbildung Nr.18: Ablauf Fehlererkennung

9 Qualitätssicherung / Projektmanagement

Eine mögliche Definition des Begriffs Qualitätssicherung gibt die Norm DIN 55350: Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht. ^[51]

Die Qualitätssicherung lässt sich in zwei Bereiche unterteilen, der produktiven und analytischen Qualitätssicherung. Zur produktiven Qualitätssicherung gehören die Maßnahmen zur Produktverbesserung und zur analytischen die Maßnahmen zur Qualitätsüberprüfung. Demnach gehören die Softwaretests zu den analytischen Qualitätssicherungsmaßnahmen.

Die Qualitätssicherung befasst sich mit Festlegung einer Qualitätspolitik und Überwachung der vorher festgelegten Kontrollaktivitäten auf der Managementebene eines Unternehmens. Die entsprechenden Vorschriften bezüglich Aufbau, Organisation, Zuständigkeiten und Mittel für die Durchführung sind üblicherweise in einem Qualitätshandbuch zusammengefasst. Die praktische Umsetzung erfolgt in Form eines Systems zur Qualitätssicherung.
Hauptaufgaben der Qualitätssicherung sind Qualitätsplanung, die Qualitätslenkung und die Qualitätsprüfung.
QS hilft Prozesse zu verbessern, es garantiert nicht automatisch die Umsetzung ausschließlich hochwertiger Produkte. Es hilft die Wahrscheinlichkeit dafür zu steigern.

Das Projektmanagement ermöglicht eine geregelte Planung, Kontrolle und Steuerung von Projekten. Bestandteile sind Projektorganisation, Projektleitung, Definition der zu nutzenden Instrumente, Techniken und alle erfolgssichernden Maßnahmen. Durch die Bereitstellung von systematisiertem Erfahrungswissen und aufbereiteten wissenschaftlichen Erkenntnissen für die Durchführung von Projekten ist es von großen Nutzen bei der Gesamtprojektplanung. ^[52]

Unter Beachtung der Qualitätssicherungsaspekte und Nutzung der Grundsätze des Projektmanagement ist die Regelung und Koordination der Kommunikation zwischen Tester und Entwickler effektiv gestaltbar. Ergebnisse können einheitlich erfasst, sowie Kritik und Anregungen festgehalten und umgesetzt werden. Es entstehen keine Unstimmigkeiten zwischen den Beteiligten, da Zuständigkeiten, Maßnahmen, Ressourcen, Berichte und Termine für alle zentral gepflegt und zur Verfügung stehen.

9.1 Projektmanagement-Tools

Projektmanagementsoftware hilft bei der Vermeidung oder Minimierung von Gefahren, Risiken, Probleme und Fehlern. Mit dem Einsatz entsprechender Software werden Aufwand und Mühe, Zeit und somit Geld eingespart. Bei gut organisierten, zielorientierten und in Schritten geplantem Vorgehen mit hoher Wahrscheinlichkeit einen zeitlichen und/oder einen wirtschaftlichen Vorteil zu bringen ist der Einsatz von Projektmanagementsoftware wichtig und effektiv.^[53]

Projekte scheitern meist, weil bestimmte Punkte nicht ausreichend berücksichtigt werden. So werden Projektziele nicht genau definiert oder es fehlen messbare Vorgaben für Ergebnisse. Die Projektpläne sind nicht detailliert genug was die Ressourcenplanung angeht. Die Projektbeteiligten unterstützen sich nicht richtig und es wird keine Risikoanalyse durchgeführt. Mit Hilfe eines Projektmanagement-Tools können diese Risiken einfach abgeschwächt werden.

Zu den grundlegenden Funktionen gehören:

• Terminplanung
• Meilenstein-Planung mit Erfolgs- und Fortschrittskontrollen
• Ressourcenplanung
• Dokumentation von Projektunterlagen (Protokolle, Anforderungskataloge etc.)

Der gesamte Austausch zwischen Tester und Entwickler kann mit Hilfe der Projektmanagement-Tools geregelt und koordiniert werden. Feedback und Änderungen von Quellcode, Änderungen der Anforderungen und Auswertungen verschiedener Tests können entsprechend der verwendeten Software bearbeitet und gespeichert werden.
Besonders effektiv lassen sich Test-Tools zusammen mit Projektmanagement-Tools einsetzen, wenn die Beteiligten räumlich voneinander getrennt sind, wie es bei virtuellen Teams der Fall ist. Spontane Absprachen oder Meetings können nicht erfolgen, wenn sich die Tester und Entwickler in unterschiedlichen Gebäuden, Städten, Firmen oder Zeitzonen befinden.
„Aus den Augen, aus dem Sinn" — dies ist die Aussage eines bekannten Sprichworts. In Bezug auf virtuelle Teams erhält das Sprichwort eine neue Bedeutung. Bei dieser besonderen Form der Teamarbeit arbeiten die Mitglieder an verschiedenen Orten und kommunizieren aus diesem Grunde vor allem über elektronische Medien (E-Mail. Tele , Fax. etc.). ^[54]

Sehr bekannte Projektmanagement-Tools sind:

• MS Project
• OpenProj
• Redmine

9.2 Agiles Qualitätsmanagement

Beweglich bleiben in der Entwicklung des Produkts, auch unter Berücksichtigung sich ständig ändernder Bedürfnisse des Kunden.

Das „Manifesto for Agile Software Development“^[55] besteht aus 4 Bewertungen:

• Personen und Wechselwirkungen (höher bewertet als Prozesse und Werkzeuge)
• Funktionierende Software (höher als umfassende Dokumentation)
• Zusammenarbeit mit Kunden (höher als Vertragsverhandlungen)
• Reagieren auf Änderungen (höher als Planerfüllung)

9.3 Personen und Wechselwirkungen

Weg von der Vorstellung, dass ein bestimmter Personenkreis das Testen übernimmt und somit Qualität gewährleistet. Alle der am Entwicklungsprozess Beteiligten sind für die Qualität seines Teilproduktes selbst verantwortlich. Mit Qualitätsmanagement ist gemeint, dass jeder dafür sorgen muss, dass die notwendige Zeit, die Infrastruktur und das benötigte Know How verfügbar sind.
Voraussetzung dafür ist, dass alle Mitentwickler Kenntnis über das Qualitätsziel und die bereits ermittelten Risiken haben. Zudem sollte jeder in der ihm zugeteilten Rolle als Fachspezialist, Entwickler, Architekt oder Unterstützer in den benötigten Qualitätssicherungstechniken geschult sein.

Um einen Erfolg bei der Entwicklung zu sichern, sollten einzelne Bereiche und die verantwortlichen Personen festgehalten werden. Bei der Softwareentwicklung könnte dies über Modularisierung der Software und einer Aufgabenverteilung innerhalb des Teams erreicht werden. Weiter muss die Entwicklung gegen Fehlschläge abgesichert werden indem ein gutes Management, eine realistischer Zeitplan mit einzelnen Meilensteinen, regelmäßige Reviews des bereits Umgesetzten und kompetenter, verfügbarer Ansprechpartner auf Kundenseite miteinbezogen werden.

Der produktive Einsatz der Wechselwirkungen aller Beteiligten untereinander fördert die Aufdeckung der meisten Fehler. So können die verschiedenen Mitglieder des Teams die Arbeiten der anderen nutzen und es ist gewünscht, diese konstruktiv zu kritisieren. Durch viele kleine Module kann konstant die Umsetzung des Gewünschten überprüft und frühzeitig Änderungen eingebaut werden.

Ein aktiver Austausch zwischen den Beteiligten kann über die Verbreitung und den Austausch von Dokumenten, Plänen und Teilprodukten, Absprachen, Fehleranalyse und Verbesserungsvorschlägen erreicht und gesteuert werden. Dabei sollten sich immer mindestens zwei Personen zu einem Bereich austauschen und sich gegenseitig um Gegentestung oder Zwischenberichte bitten dürfen. Eine geregelte Kommunikation ist hier nicht erwünscht, der Austausch soll unter allen Beteiligten erfolgen. Auftretende Konflikte werden untereinander im direkten Gespräch gelöst.

In der Softwareentwicklung steht die funktionierende Software im Vordergrund. Sie stellt den Erfolgsindikator dar und nicht die Dokumente, Pläne oder Modelle. Die Qualitätssicherung ist demzufolge ein wichtiger Teil des Entwicklungsprozesses. Parallel zur Softwareentwicklung muss per Qualitätssicherungsmethode der aktuelle Stand festgehalten werden.

• Dokumente und Modelle mit Reviews verknüpfen
• Funktionen, Prozeduren, Klassen, Module und Komponenten mit automatisierten oder interaktiven Test Units und implementierten Laufzeittests per Design-By-Contract Konstrukte verknüpfen
• Zusammenbau zum vollständigen Programm mit Smoke Tests und automatisierten Regressionstest verknüpfen

So wird die geballte Testphase nach Erstellung und vor Auslieferung des Programms umgangen.^[56]

9.4 Zusammenarbeit mit Kunden

Softwarearchitekten stellen die Schnittstelle zwischen Analyse, Entwurf, Implementierung, Management und Betrieb von Software dar. Entsprechend dem agilen Qualitätsmanagement wird der Rolle des Softwarearchitekten eine immer größere Bedeutung beigemessen und hat eine zentrale Bedeutung für das Gelingen von Projekten. Allerdings wird die Position in Projektteams meist gar nicht oder nicht angemessen umgesetzt. Die Inhaber dieser Position sind für das Funktionieren des Gesamtsystems innerhalb eines Projektes zuständig. Weiter sind Softwarearchitekten die Vertreter der Kunden und für die Umsetzung der Anforderungen verantwortlich.

Eine zentrale Aufgabe des Softwarearchitekten ist der ständige Austausch mit dem entsprechenden Ansprechpartner auf Kundenseite während Projektlaufzeit. Mögliche Ansprechpartner sind dabei Fachgebietsexperten und zukünftige Anwender, die im agilen Qualitätsmanagement die fachlichen Tests mit durchführen und beobachten sollen.

Entsprechend der Rollen können die Aufgaben so verteilt werden, dass Entwickler für die Unit Tests, Architekt für Integrations- und Systemtests und Anwender (Kunden) für die Umsetzung fachlicher und bedienungstechnischer Tests verantwortlich sind.

Die Rollen:

• Entwickler = Jeder, der ein Teil- oder ganzes Projekt erstellt. Dazu gehören Programmierung, Analyse, Design und Dokumentation. Zu den Unit Tests gehören Einheiten-, Modul- oder Komponententests. Damit sind alle Tests gemeint, die eine Programmeinheit betreffen. Programmeinheiten können dabei einzelne Funktionen oder Klassenmethoden oder ganze Module sein.
• Softwarearchitekt = Ist für die Durchführung der Integrations- und Systemtests verantwortlich. Dabei muss der zuständige Softwarearchitekt die Tests nicht zwangsläufig selbst durchführen, sondern muss die Umsetzung betreuen und überwachen. Mögliche Hilfsmittel sind Risikoanalyse, Testpläne und Testdesign.
• Anwender = Überprüfung der Bedienbarkeit und der Umsetzung der fachlichen Zusammenhänge.^[57]
• Tester = Die Tester brauchen gute Kenntnisse der verfügbaren Tools und wie interne Abläufe aussehen.^[58]

10 Vergleiche

Die Entscheidung, wie der Informationsaustausch zwischen Testern, Endanwendern und Entwicklern organisiert werden soll ist sehr wichtig und sollte wohlbedacht sein. Bei der Fülle an Möglichkeiten ist es wichtig, die für den jeweiligen Zweck am Besten geeignete Option zu wählen.
Ein objektiver Vergleich zwischen den verschiedenen Möglichkeiten ist da eine helfende Entscheidungsgrundlage

10.1 Kommunikation mit und ohne Software-Test-Tools

Gerade bei der Kommunikation gibt es je nach Einsatzzweck verschiedene Schwerpunkte, die bei der Entscheidung berücksichtigt werden müssen. Die Entscheidung, ob mit oder ohne Software agiert werden soll muss wohlüberlegt sein. Am Besten wird eine solche Entscheidung mit einer Analyse der Kriterien, die erfüllt werden müssen, getroffen.

Mit Software	Ohne Software
geregelte Kommunikation	unbürokratisch
Bearbeitungsroutinen	Einzelfallbearbeitung
globaler Informationsaustausch	Kosteneinsparung gegenüber teurer Software
Bearbeitungshistorie	kein Schulungsbedarf
besseres Projekt- und Resourcenmanagement und bessere Kostenkalkulation durch Automatismen	schnellere Reaktionszeit durch offene Organisationsstruktur

Tabelle 3: Kommunikation mit und ohne Software-Test-Tools‘‘

10.2 Vergleich Bugtracking-Tools

Die Auswahl an nützlichen Bugtracking-Tools ist sehr gross. Dabei unterscheiden sich die einzelnen Tools nur noch wenig voneinander. Entsprechend der benötigten Funktionen muss das Tool in die vorhandene Infrastruktur passen, vorhandenen Unternehmensrichtlinien gerecht werden und von den potentiellen Anwendern gut zu nutzen sein. Entsprechend vordefinierter Mindestfunktionen lässt sich die Zahl der potentiellen Tools effektiv eingrenzen. Bei einem regional tätigen Unternehmen wäre ein englischsprachiges Tools vielleicht nicht die beste Wahl, wenn alle Mitarbeiter nur deutsch sprechen. Bei international tätigen Unternehmen wäre ein multilinguales Tool die beste Alternative. Die Anwender müssen die Möglichkeit haben Fehler zu ermitteln und zu beheben, Daten zu sichern und die Entwicklung der Programme schnell und unkompliziert durchzuführen.

	Bugzilla	Jira	Mantis
Betriebssystem	Windows 98, ME, 2000, XP, Linux, Mac OS, Mac OS X, Mac OS X/Intel	funktioniert auf allen Systemen auf denen auch Java läuft	Windows, Linux, Mac OS, OS / 2 und andere
Sprache	Deutsch	Deutsch	Englisch
Lizenz	Mozilla Public License	Atlassian	GNU General Public License
Preis	kostenlos	Useranzahl-abhängig, von 10€ für 10User bis 5440€ für eine unbeschränkte Useranzahl	kostenlos
Support	kostenlos, über Foren	12 Monate kostenlose Updates und Support von der Firma Atlassian	kostenpflichtig
Folgekosten	keine	jährlich neue Support- Kosten	keine
PlugIns / AddOns	verfügbar / Bugzilla Homepage	Atlassian Plugin Development Kit / JIRAs Development Hub	verfügbar / Mantis Homepage

Tabelle 4: Vergleich Bugtracking-Tools

10.3 Vergleich Issuetracking-Tools

Die Wahl eines Issuetracking-Tools ist stark von dem Einsatzbereich, der Unternehmensgröße oder dem Kundenstamm abhängig. Entsprechend der späteren Anwender und deren Qualifikationen sind zu komplexe Tools in einem Callcenter mit ständig wechselnden Agents eher hinderlich und unrentabel. So sollten die Anwender in manchen Bereichen einfach eingearbeitet werden können, um umfangreiche Schulungen und die damit verbundenen Kosten und Ausfallzeiten zu minimieren. In Bereichen mit Fachkräften ist dagegen ein Tool mit umfangreichen Einsatzmöglichkeiten und Zusatzfunktionen trotz Einarbeitung und den damit verbundenen Kosten besser angebracht. Mit Hilfe des Tools könnten interne Prozesse optimiert, Routinen entwickelt, Anleitungen zu Fehlerbehebungen erstellt und neue Ressourcen freigesetzt werden.

	JFire	Open Ticket Request System	Request Tracker
Betriebssystem	Windows und Unix	Windows und Unix	Linux, FreeBSD, Solaris, MacOS X u. a. Unixsysteme
Sprache	multilingual	Deutsch und Englisch	Englisch
Lizenz	LGPL (GNU Lesser General Public License)	GNU Affero General Public License (AGPL)	GPL (Freie Software)
Preis	kostenlos	kostenlos	kostenlos
Support	Foren / kostenpflichtiger Support (JFire)	Foren / kostenpflichtiger Support (OTRS)	Basis-Service ab 1.760€ pro Jahr, je nach Supportmodell teurer (Netways)
Folgekosten	keine / kostenpflichtiger Intensivsupport über Dienstleister	Individualisierung /professioneller Support	kostenpflichtige Support
PlugIns / AddOns	verfügbar / bereits implementiert / JFire Homepage	verfügbar / OTRS Homepage	verfügbar / Netways Homepage

Tabelle 5: Vergleich Issuetracking-Tools

11 Fazit

Am Beispiel der EC-Karten Problematik ist deutlich zu sehen wie wichtig das Testen von Anwendungen ist. Dabei ist das Testen ein Prozess, der in allen Phasen der Entwicklung stattfindet. Das Testen jeglicher Szenarien bei größeren Projekten ist schlichtweg nicht möglich. Darum ist es umso wichtiger, dass Entwickler, Tester und Anwender/Kunde miteinander kommunizieren. Nur der Kunde kann sagen, welche Funktionen besonders wichtig sind und entsprechend ausgiebiger getestet werden müssen. Andere Bereiche wie etwa ein ansprechendes Design von Kontoauszügen sind eventuell nicht so wichtig und müssen nur kurz überprüft werden. Im optimalen Fall gehört der Kunde zum Testteam. In dem Fall kann der Kunde die Test-Szenarien festlegen und ein Tester diese Tests umsetzen. Ein erfahrener Tester kennt die regulären Testverfahren und kann automatisierte Testverfahren schreiben und effektiv nutzen. Dieses Wissen fehlt dem Kunden im Normalfall. Der Entwickler selbst besitzt zwar das Wissen, hat aber die falsche Einstellung zum Testen. Wer sagt schon gerne anderen was für Fehler er alle gemacht hat.

Fehler, die erst beim Produkteinsatz auftreten, sorgen immer für zusätzliche Kosten und schaden dem Ansehen des Herstellers und der Firma, die eine fehlerhafte Software einsetzt. Auch wenn ausgiebig während der Entwicklung getestet wurde können im Produktiveinsatz weitere, noch unbekannte Fehler auftreten. Damit diese Fehler schnell und effizient entfernt und korrigiert werden können ist der Einsatz von Issue-Tracking- und/oder Bug-Tracking-Systemen unerlässlich. Sie helfen bei der Koordination der Zusammenarbeit zwischen den verschieden Entwicklern, Testern und Anwendern und sorgen für eine ordentliche Dokumentation der Fehlerbearbeitung.

Mit der zentralen Datensammlung und der Anpassung an das jeweilige Unternehmen können nicht nur Kommunikationswege vorgegeben werden. Unter Verwendung aller enthaltenen Funktionen können Meilensteine definiert und durch Terminplanung mit Fortschrittskontrolle Erfolge gekennzeichnet und gesichert werden. Entsprechend der Unternehmensorganisation können weitere Abteilungen oder Funktionen integriert werden. Ressourcen können zielgerecht eingeplant und eingesetzt werden. Kosten werden überschaubar, Informationen stehen allen Beteiligten zur Verfügung, Entscheidungen können schneller gefällt und überarbeitete Versionen global verteilt werden.

Im Verlauf unserer Bearbeitung sind wir zu der Erkenntnis gekommen, dass Test-Tools mächtige Werkzeuge darstellen. In der immer mehr vernetzten und informationslastigen Gesellschaft stellen Test-Tools wichtige Funktionen bereit, um sich den ständig verändernden Ansprüchen der heutigen Zeit zu wappnen und konkurrenzfähig aufzustellen. Im Bereich des Austauschs zwischen den Projektbeteiligten ist eine geregelte Kommunikation und Bearbeitung grundlegend. Gesetzliche und unternehmerische Vorgaben können einfach angewand und optimal genutzt werden. Die regulierte Datenerfassung und Fallbearbeitung optimiert Unternehmensabläufe und Prozesse. Gerade bei größeren Unternehmen und Projekten sind Test-Tools unerlässlich. Bei kleineren, regional agierenden Gruppen reichen noch die klassischen Kommunkations- und Datenerfassungs-Maßnahmen.

12 Fußnoten

1. ↑ Vgl.http://www.focus.de/finanzen/banken/ec-karten-panne-banken-warnen-vor-tesa-trick_aid_468664.html
2. ↑ Vgl. http://www.heise.de/security/meldung/Desaster-mit-EC-Karten-kann-teuer-werden-896988.html
3. ↑ Vgl. http://www.heise.de/security/meldung/EC-Karten-Problem-Sparkassen-wollen-Kosten-fuer-alternative-Bargeldbeschaffung-erstatten-899141.html
4. ↑ Vgl. Kiehl (2001), S. 39 ff.
5. ↑ Vgl. Dustin (2001), S.3 ff.
6. ↑ Vgl. Dustin (2001), S.4
7. ↑ Vgl. Spillner (2008), S.271
8. ↑ Vgl. Pol (2000), S. 66
9. ↑ Vgl. Pol (2000), S. 75
10. ↑ Vgl. Gilsa (2004), S. 28
11. ↑ Vgl. Bohinc (2006), S.115
12. ↑ Vgl. Gilsa (2004), S.6
13. ↑ Vgl. Beck (2000), S.143
14. ↑ Vgl. Helmke, Höppner, Isernhagen (2007), S. 182
15. ↑ Vgl. Helmke, Höppner, Isernhagen (2007), S. 182 Tabelle 7.1
16. ↑ Vgl. Abts (2004), S. 14
17. ↑ Vgl. Kilian (2008), S. 104
18. ↑ Vgl. Maier (2004), S. 49
19. ↑ Vgl. Schnidler (2002), S.39
20. ↑ Vgl. Wallmüller (2001) S.225 ff.
21. ↑ Vgl. Liggesmeyer (2002), S.35 ff
22. ↑ Vgl. Liggesmeyer (2002), S.36 ff
23. ↑ Vgl. Myers (2001), S. 7 f.
24. ↑ Vgl. Mayr (2005) S.258
25. ↑ Vgl. Myers (2001), S. 7 f
26. ↑ Vgl. Böhm, Jungkunz (2005), S. 79
27. ↑ Vgl. Wallmüller (2001), S. 232
28. ↑ Vgl. Mildenberger, Zöller-Greer (2002) S. 226
29. ↑ Vgl. Mayr (2005), S. 289
30. ↑ Vgl. Kannengiesser (2007), S.59
31. ↑ Vgl. Bernhart (2009), S.313 f
32. ↑ Vgl. Hoffmann, 2008
33. ↑ Vgl. Hoffmann, 2008
34. ↑ Vgl. Franz (2007), S.28
35. ↑ Vgl. Thaller (2002), S.69
36. ↑ Vgl. Liggesmeyer (2009), S.142
37. ↑ Vgl. Thaller (2002), S. 59 ff.
38. ↑ Vgl. Rätzmann (2004), S.56.
39. ↑ Vgl. Rätzmann (2004), S.60
40. ↑ Vgl. Rätzmann (2004), S.60
41. ↑ Vgl. Rätzmann (2004), S.51;62;273
42. ↑ Vgl. http://www.mozilla-europe.org/de/products/bugzilla/
43. ↑ Vgl. Uhr, Esswein, Schoop(1973), S. 886
44. ↑ Vgl. Müller(2007), S. 180
45. ↑ Vgl. www.jfire.org
46. ↑ Vgl. http://doc.otrs.org/2.4/en/html/, otrs_admin_book.pdf
47. ↑ Vgl. http://www.netways.de/de/produkte/rt/funktionsweise/
48. ↑ Vgl. http://www.focus.de/finanzen/banken/ec-karten-panne-banken-warnen-vor-tesa-trick_aid_468664.html
49. ↑ Vgl. http://www.heise.de/newsticker/meldung/EC-Karten-Problem-entspannt-sich-nur-langsam-896221.html
50. ↑ Vgl. http://www.ap-verlag.de/Online-Artikel/20090910/20090910a%20Sparkassen%20Finanz%20Informatik%20SOA%20funktioniert.htm
51. ↑ Vgl. Rätzmann (2004), S. 31ff
52. ↑ Vgl. Sommerville (2001), S.83
53. ↑ Vgl. http://www.teialehrbuch.de/Kostenlose-Kurse/Projektmanagement-und-MS-Project-2000/15513-Fallstricke-typische-Risiken-Probleme-und-Fehler.html
54. ↑ Vgl. Geister (2004), S.1
55. ↑ Vgl. http://agilemanifesto.org/
56. ↑ Vgl. Rätzmann (2004), S. 265f
57. ↑ Vgl. Rätzmann (2004), S. 268ff
58. ↑ Vgl. Sneed,Baumgartner,Seidl (2008), S. 158

13 Literatur- und Quellenverzeichnis

Abts (2004)	Abts, Dietmar, Mülder, Wilhelm, Grundkurs Wirtschaftsinformatik, 5. Auflage, Friedri. Vieweg & Sohn Verlag, Wiesbaden, 2004, S. 14
Beck (2000)	Beck, Kent: Extreme Programming – Die revolutionäre Methode für Softwareentwicklung in kleinen Teams, ADDISON-WESLEY, 2000, S. 143
Bernhart, Grechenig (2007)	Bernhart, Mario Grechenig, Thomas: Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten, Pearson Education Verlag, 2009, S.297
Böhm, Jungkunz (2005)	Böhm, Andreas M. Jungkunz, Bettina: Projekt Engineering: Grundkurs IT-berufe: Die technischen Grundlagen verstehen und anwenden können, Vieweg+Teubner Verlag, 2005, S.79
Bohnic (2006)	Bohinc, Tomas, Projektmanagement: Soft Skills für Projektleiter, 3. Auflage, GABAL-Verlag GmbH, 2006, S. 115
Dustin (2001)	Dustin,Elfriede, Rashka,Jeff, Paul, John: Software automatisch testen, Springer, Berlin 2001, S. 3ff., S. 4
Dustin (2003)	Dustin, Elfriede (Hrsg.): Effective Software Testing, Pearson Education, Inc., Boston 2003, S. 159f
Franz (2007)	Franz,Klaus, Handbuch zum Testen von Web-applikationen: Testverfahren, Werkzeuge, Praxistipps, Springer Verlag, Berlin Heidelberg 2007, S. 28
Geister (2004)	Geister, Susanne, Feedback in virtuellen Teams: Entwicklung und Evaluation eines Online-Feedback-Systems, DUV, 2004, S.1
Gilsa (2004)	von Gilsa, Maren, Huber, Rita, Russ, Thorsten, Virtuelle Projektarbeit: Leitfaden für die Praxis, Erich Schmidt Verlag GmbH & Co., Berlin 2004, S.6, S.28
Helmke, Höppner, Isernhagen (2000)	Helmke, Hartmut Höppner, Frank Isernhagen, Rolf: Einführung in die Software-entwicklung: Vom Programmieren zur erfolgreichen Software-projektarbeit, Hanser Verlag, 2007, S. 182
Hoffmann (2008)	Hoffmann, Dirk W.: Software-qualität, Springer Verlag, 2008, S.157ff
Kannengiesser (2007)	Kannengiesser, Matthias: Objektorientierte Programmierung mit PHP 5, Franzis Verlag, 2007
Kiehl (2001)	Kiehl, Peter, Breutmann, Norbert, Goethe, Wolfgang, Klein Einführung in die DIN-Normen, 13. Auflage, B.G. Teubner Verlag, 2001, S. 39f
Kilian (2008)	Kilian, Dietmar, Mirski, Peter, Hauser, Martin, Weigl Markus, Projektmanagement: Praxis, Theorie, Werkzeuge, Linde Verlag, Wien 2008, S. 104
Liggesmeyer (2002)	Liggesmeyer, Peter: Software-Qualität Testen, Analysieren und Verifizieren von Software, Akad. Verlag, 2002, S. 35ff
Liggesmeyer (2009)	Liggesmeyer, Peter, Software-Qualität: Testen, Analysieren und Veriifizieren von Software, 2. Auflage, Spektrum Akademischer Verlag, Heidelberg 2009, S. 142
Maier (2007)	Maier, Ronald, Knowledge Management Systems: Information and Communication Technologies for Knowledge Management, 3rd Auflage, Springer, Berlin 2007, S. 49
Mayr (2005)	Mayr, Herwig: Projekt Engineering: Ingenieurmäßige Softwareentwicklung in Projektgruppen (2. Ausgabe), Hanser Verlag, 2005, S.258
Mildenberger, Zöller-Greer (2005)	Mildenberger, Otto Zöller-Greer, Peter: Softwareengineering für Ingenieure und Informatiker: Planung, Entwurf und Implementierung, Vieweg+Teubner Verlag, 2002, S. 216ff
Müller (2007)	Müller, Klaus-Rainer: It-sicherheit mit System: Sicherheitspyramide- Sicherheits-, kontinuitäts- und Risikomanagement- Normen und Practices- SOA und Softwareentwicklung (3. Ausgabe), Springer Verlag, 2007, S. 180
Myers (2001)	Myers, Glenford J.: Methodisches Testen von Programme (7. Ausgabe), Oldenbourg Wissenschaftsverlag, 2001, S. 7 f
Pol (2008)	Pol, Martin, Koomen, Tim, Spillner, Andreas: Management und Optimierung des Testprozesses: ein praktischer Leitfaden für Testen von Software, mit TPI und TMap, dpunkt.verlag, 2000, S. 66, S. 75
Rätzmann (2004)	Rätzmann, Manfred (Hrsg.): Software- Testing & Internationalisierung (2. Auflage), Galileo Press GmbH, Bonn 2004, S.31ff
Sommerville (2001)	Sommerville, Ian (Hrsg.): Software Engineering (6. Auflage), Pearson Studium, München 2001, S. 83ff
Schindler (2000)	Schindler, Martin, Wissensmanagement in der Projektabwicklung, Josef Eul Verlag, Köln 2000, S. 39
Sneed, Baumgartner, Seidl (2008)	Sneed,Harry M. Baumgartner,Manfred Seidl, Richard, Der Systemtest: Von den Anforderungen zum Qualitätsnachweis(2. Ausgabe), Hanser Verlag, 2008, S. 158
Spillner (2008)	Spillner,Andreas, Roßner, Thomas, Winter, Mario, Linz, Tilo: Praxiswissen Softwaretest - Testmanagement: Aus- und Weiterbildung zum Certified Tester, punkt Verlag, Heidelberg 2008,S. 271
Starke (2009)	Starke, Gernot (Hrsg.): Effektive Software-architekturen: Ein praktischer Leitfaden, Hanser Verlag, S.6f
Thaller (2002)	Thaller,Georg Erwin, Software-Test: Verifikation und Validation, 2. aktualisierte und erweiterte Auflage, Heinz Heise GmbH & Co KG, Hannover, 2002, S. 59ff
Uhr, Esswein, Schoop (1973)	Uhr, Wolfgang Esswein, Werner Schoop, Eric: Wirtschaftsinformatik 2003: Medien - Märkte – Mobilität (1. Band), Birkhäuser Verlag, 1973, S. 886
Wallmüller (2001)	Wallmüller, Ernest: Software-qualitätsmanagement in der Praxis (2. Ausgabe),Hanser Verlag, 2001, S. 1, S.225 ff
Zuser/ Biffl/ Grechenig/ Köhle (2001)	Zuser,Wolfgang/ Biffl,Stefan/ Grechenig,Thomas/ Köhle, Monika (Hrsg.): Software Engineering: mit UML und dem Unified Process, Pearson Studium, München 2001, S. 283ff

14 Relevante Links

http://www.heise.de/software/download/bugzilla/37858

https://www.jfire.org/modules/content/id_9.html

http://www.mozilla-europe.org/de/products/bugzilla/

http://www.netways.de/de/produkte/nagios/pluginaddon_sammlung/netways_entwicklungen/

http://www.netways.de/de/produkte/rt/supportvertraege/

http://otrs.org/

http://www.pixsoftware.de/JIRA/10-gruende-fuer-jira.html

http://www.pixsoftware.de/JIRA/jira-preisliste.html

http://projektmanagement-definitionen.de/glossar/software/

http://www.verifysoft.com/Verifysoft-ppt-DE.pdf

http://www.wasistwas.de/technik/alle-artikel/artikel/link//90f7011645/article/wie-der-computer-die-motten-bekam/-7c05c71e06.html

http://www.focus.de/finanzen/banken/ec-karten-panne-banken-warnen-vor-tesa-trick_aid_468664.html

http://www.heise.de/security/meldung/Desaster-mit-EC-Karten-kann-teuer-werden-896988.html

http://www.heise.de/security/meldung/EC-Karten-Problem-Sparkassen-wollen-Kosten-fuer-alternative-Bargeldbeschaffung-erstatten-899141.html