Inhaltsverzeichnis
1 Einleitung und Problemstellung 1
2 Softwarequalität. 3
2.1 Qualitätsmerkmale. 4
2.1.1 Statische Qualitätsmerkmale 5
2.1.2 Dynamische Qualitätsmerkmale. 5
2.1.2.1 Funktionalität. 6
2.1.2.2 Leistung 7
2.1.2.3 Kontinuität 8
2.1.2.4 Benutzungsfreundlichkeit 9
2.2 Kosten und Nutzen von Softwarequalität. 10
3 Qualitätssicherung 14
3.1 Organisatorische Maßnahmen und Management der
Qualit ätssicherung. 19
3.2 Konstruktive Maßnahmen der Qualitätssicherung 21
3.2.1 Das iterierte Phasenmodell 22
3.2.1.1 Die Phasen des Softwarelebenszyklus. 24
3.2.1.2 Bewertung des iterierten Phasenmodells 26
3.2.2 Prototyping und Rapid Application Development 28
3.3 Analytische Maßnahmen der Qualitätssicherung 31
3.3.1 Klassifikation der Maßnahmen der analytischen
Qualit ätssicherung 31
3.3.2 Das V-Modell 33
3.3.2.1 Modultest 35
3.3.2.2 Integrationstest. 36
3.3.2.3 Systemtest 37
3.3.2.4 Abnahmetest 40
4 Black-Box-Testverfahren 41
4.1 Testablaufplanung 41
4.2 Äquivalenzklassen 43
4.3 Grenzwertanalyse 44
4.4 Praxisbeispiel zur Ermittlung von Testfällen 44
I
5 Automatisiertes Testen 51
5.1 Capture/Replay-Tools. 53
5.1.1 Skripterstellung. 56
5.1.2 Skriptwiedergabe 61
5.2 Vorteile und Ziele der Testautomatisierung 63
5.3 Einsatzmöglichkeiten der Testautomatisierung. 67
5.4 Skriptprogrammierung. 71
5.4.1 Entwicklung automatisierter Tests 74
5.4.2 Functional Decomposition. 75
5.4.3 Die Aktionswort-Methode 80
5.5 Erfolgsfaktoren für die Testautomatisierung. 86
5.6 Schwierigkeiten der Testautomatisierung 89
5.7 Quantitativer Nutzen der Testautomatisierung. 94
6 Praktische Erfahrungen mit Testautomatisierung in der
AXA Krankenversicherung AG 100
6.1 Einsatzmöglichkeiten für die Makro-Funktionalität
der Emulations-Software 101
6.2 Einsatzmöglichkeiten für das Capture/Replay-Tool QA-Hiperstation. 101
6.3 Anreicherung von Testdaten für das Projekt Euro-Umstellung 105
6.4 Regressionstests im Rahmen des Projekts Beitragsanpassung 2002. 108
6.5 Ausblick. 111
7 Fazit 113
II
Abkürzungsverzeichnis
AG Aktiengesellschaft DB Database DGQ Deutsche Gesellschaft für Qualität DIN Deutsches Institut für Normung DV Datenverarbeitung EDV Elektronische Datenverarbeitung ESSI European Systems and Software Initiative GUI Graphical User Interface Hrsg. Herausgeber IEEE Institute of Electrical and Electronic Engineers IMS Information Management System ISO International Organization for Standardization IT Informationstechnologie ITG Informationstechnische Gesellschaft o.J. ohne Jahresangabe PIE Process Improvement Experiment PSA Problem Statement Analyzer PSL Problem Statement Language RAD Rapid Application Development TDK Testdatenkombination TF Testfall TMap Test Management approach TSL Test Script Language
III
Abbildungsverzeichnis
Abbildung 1: Umsetzungstabelle Qualitätsmerkmale TMap und ISO 9126,
Abbildung 2: Aufteilung der Softwarekosten,
Abbildung 3: Qualitätskosten,
Abbildung 4: Vorbeugen ist billiger als heilen ,
Abbildung 5: Maßnahmen der Software-Qualitätssicherung,
Abbildung 6: Das iterierte Phasenmodell,
Abbildung 7: Das V-Modell,
Abbildung 8: Fachvorgabe für die Prämienberechnung,
Abbildung 9: Testfallkandidaten für die Prämienberechnung,
Abbildung 10: Verdichtung der Testfallkandidaten für die Prämienberechnung,
Abbildung 11: Testfälle für die Prämienberechnung,
Abbildung 12: Testdatenkombinationen für die Prämienberechnung,
Abbildung 13: GUI-Tabelle,
Abbildung 14: GUI-Tabelle für neue Softwareversion,
Abbildung 15: Testbericht,
Abbildung 16: Testtabelle mit Eingabedaten,
Abbildung 17: Testfalldokumentation für die Aktionswort-Methode,
Abbildung 18: Testframe-Automatisierungs-Architektur,
Abbildung 19: Break-Even-Point der Automatisierung von GUI-Tests,
Abbildung 20: Vergleich von manueller und Makro-unterstützter Testdaten-
anreicherung ,
Abbildung 21: Nutzen der Testautomatisierung im Rahmen des Projekts
Beitragsanpassung 2002,
IV
1 Einleitung und Problemstellung
Diese Diplomarbeit beschäftigt sich mit der Automatisierung von Black-Box-Testverfahren für Computersoftware. Basierend auf der Erkenntnis, dass ein qualitativ hochwertiger Testprozess für eine hohe Softwarequalität unabdingbar ist, gilt es, diesen so effizient wie möglich zu gestalten. Ein Großteil der Zeit in einem Testprozess wird mit der manuellen Durchführung von zuvor definierten Testfällen verbracht. Unter bestimmten Voraussetzungen besteht die Möglichkeit, Teile dieser Implementierungsphase der Testfälle zu automatisieren. Eine solche Automatisierung setzt einen strukturierten und methodischen Testprozess voraus. Besonders an die Analyse der Testanforderungen sowie an das Design der Testfälle werden hohe Ansprüche gestellt. In den seltensten Fällen kann die Automatisierung realisiert werden, indem einfaches ‚Capture‘ (Aufzeichnen) und ‚Replay‘ (Wiedergabe) von Benutzereingaben erfolgt. Mit Hilfe mächtiger Skriptsprachen, die den eingesetzten Testtools zugrunde liegen, gilt es, wieder verwendbare Testskripts zu entwickeln. Diese Arbeit ordnet die Testautomatisierung in den Softwareentwicklungs- und Testprozess ein und zeigt die Einsatzmöglichkeiten und Vorteile, aber auch die Schwierigkeiten und Grenzen der Testautomatisierung auf. Dies alles muss unter Kosten-Nutzen-Aspekten betrachtet werden. Das bedeutet auch, dass nicht in jedem Fall die ausgefeilteste Testautomatisierung angebracht ist, sondern dass unterschiedliche Anforderungen auch unterschiedliche Lösungen bedingen. In Kapitel 2 wird zunächst ein allgemeiner Überblick zur Softwarequalität gegeben. Es wird beschrieben, wie die Qualität einer Systemanwendung anhand von Qualitätsmerkmalen gemessen wird, um eine objektive Beurteilung des entwickelten Produkts zu ermöglichen. Des Weiteren wird der wirtschaftliche Aspekt von Softwarequalität untersucht. Hierzu werden die unterschiedlichen Arten von Softwarekosten erläutert, und die Qualitätssicherung wird nach ökonomischen Gesichtspunkten betrachtet.
Mit den unterschiedlichen Ausprägungen der Qualitätssicherung beschäftigt sich Kapitel 3. Das Ziel dieses Abschnitts besteht vor allem darin, die
1
Zusammenhänge zwischen Softwareentwicklung und Qualitätssicherung herauszuarbeiten. Dies ist notwendig, um herauszustellen, in welchem Gesamtkontext das Testen von Software und insbesondere die Testautomatisierung stattfindet. Dabei wird auch auf die Verzahnung von konstruktiven und analytischen Maßnahmen der Qualitätssicherung eingegangen. In Kapitel 4 werden mit der Äquivalenzklassenmethode und der Grenzwertanalyse zwei Spezifikationstechniken vorgestellt, mit denen Black-Box-Testfälle definiert werden können. Anhand eines praktischen Beispiels wird die Vorgehensweise erläutert. Das Ziel dieses Abschnitts besteht in der Veranschaulichung der Ermittlung der Testfälle, die anschließend automatisiert werden sollen.
Kapitel 5 beschäftigt sich mit der Automatisierung für die Durchführung der vorher generierten Testfälle. Dabei wird zunächst die grundsätzliche Funktionsweise eines sogenannten Capture/Replay-Tools erläutert. Neben den Vorteilen und Zielen werden auch die Einsatzmöglichkeiten sowie Erfolgsfaktoren und Schwierigkeiten der Testautomatisierung beschrieben. Der Abschnitt über die Skriptprogrammierung enthält zwei Implementierungsansätze für wieder verwendbare Testskripts. Den Abschluss dieses Kapitels bildet die Ermittlung des quantitativen Nutzens der Testautomatisierung inklusive Berechnung des Break-Even-Points im Vergleich zu manuellem Testen. Über die Erkenntnisse der Literaturrecherche hinaus werden in Kapitel 6 vom Autor gesammelte Erfahrungen mit selbst entwickelten Testfällen und Testskripts eingebracht. Der gewonnene Nutzen der Automatisierung im Vergleich zu manueller Testausführung wird anhand einiger empirischer Vergleichszahlen verdeutlicht.
In Kapitel 7 werden die Ergebnisse der Arbeit zusammengefasst und ein Fazit gezogen.
2
2 Softwarequalität
In der heutigen Zeit agieren Unternehmen auf globalen und dynamischen Märkten, die in sehr kurzen Zeitabschnitten immer neue Entwicklungen hervorbringen. Eine schnelle Reaktion auf immer spezifischer werdende Kundenwünsche sowie individuelle und kostengünstige Lösungen für Produkte und Dienstleistungen in hoher Qualität sind der Schlüssel für die Zufriedenheit der Kunden.
In diesem Zusammenhang spielen Systeme der Informations- und Kommunikationstechnologie eine zunehmend größere Rolle. Diese Technologien dienen der Implementierung einer strategischen Marktposition sowie der Erschließung neuer Märkte, indem sie Möglichkeiten einer schnelleren Erweiterung und Verbesserung des Produkt- und Dienstleistungsangebotes offerieren. Die zunehmende Integration von Informationstechnologie und Betriebsführung sowie die immer wichtiger werdende Qualität der Informationsversorgung haben zur Folge, dass Störungen in den DV-Systemen und somit in den Betriebsprozessen der Unternehmungen unmittelbar negative Auswirkungen auf die Kostenstruktur hervorrufen.
Das Testen von Computerprogrammen im Rahmen der Softwareentwicklung stellt einen wesentlichen Prozess dar, um den hohen Anforderungen an die Funktionsfähigkeit der DV-Systeme gerecht zu werden. Die Folgen unzureichender Softwarequalität sind vielfältig. Überlastete Anwendungen, die keine Verarbeitung von Geschäftsvorfällen mehr zulassen, können rasch Verlustpositionen von mehreren Millionen Euro zur Folge haben. Systeme, die aufgrund zu schneller Einführung noch keine marktfähige Produktqualität aufweisen, können zu Imageschäden und zur Verunsicherung von Kunden führen. Im Extremfall wenden sich die Kunden der Konkurrenz zu (CMG, o.J. (a), S.7-13). Gleichzeitig steigt durch die Integration von Systemen der
Informationstechnologie deren Komplexität und somit auch das Fehlerrisiko. Die
3
Herstellung von absolut fehlerfreien und fachlich in jedem Fall korrekten Anwendungssystemen ist in der Regel nicht möglich, da es sich bei der Softwareentwicklung um einen Prozess mit vielen Schnittstellen handelt. Das Ziel aller Maßnahmen zur Qualitätssicherung ist daher die größtmögliche Annäherung an das Ideal einer fachlich und funktional perfekten Software und die Reduzierung möglicher Fehlerquellen auf ein absolutes Minimum. Die letztendliche Qualitätskontrolle der entwickelten Systeme muss über die Durchführung von Softwaretests sichergestellt werden (CMG, o.J. (b), S.1). Einen Leitfaden zur erfolgreichen Softwareherstellung und zur Erzielung der notwendigen Qualität beinhaltet die Normenreihe DIN ISO 9000. Diese beschreibt Anforderungen an die organisatorische Einordnung von Qualitätssicherungssystemen und legt von der Entwicklungsphase abhängige Qualitätsziele sowie Maßnahmen zu deren Erreichung fest. Zusätzlich werden qualitätsbezogene Aktivitäten phasenübergreifend in einem
Qualitätssicherungsplan definiert. Unternehmen, deren Entwicklungsprozesse normenkonform gestaltet sind, können eine Zertifizierung anstreben, um ihren Kunden gegenüber nachzuweisen, dass die mit der Norm verbundenen Qualitätsrichtlinien erfüllt werden (Bodendorf/König/Mertens/Picot/Schumann, 1998, S.169).
Die Beurteilung des entwickelten IT-Systems kann anhand von sogenannten Qualitätsmerkmalen erfolgen.
2.1 Qualitätsmerkmale
Nach der DIN-Norm 55350, Teil 11 (Mai 1987), wird Qualität als die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen, definiert. Der Begriff Beschaffenheit bezeichnet die Gesamtheit der Merkmale und Merkmalswerte einer Einheit (Trauboth, 1996, S.25-26). Die Qualitätsmerkmale, die im Rahmen von Softwareprüfungen relevant sind, können nach dynamischen und statischen Qualitätsmerkmalen differenziert werden.
4
2.1.1 Statische Qualitätsmerkmale
Als statische Qualitätsmerkmale werden die intrinsischen Eigenschaften einer Anwendung sowie der dazugehörigen Dokumentation bezeichnet. Die Betrachtung erfolgt aus der Sicht des Softwareentwicklers bzw. des zukünftigen Administrators. Beispiele für solche Merkmale sind die Verwaltungsfähigkeit oder die Aktualisierbarkeit eines Informationsverarbeitungssystems. Statische Qualitätsmerkmale werden mittels Inspektionen oder Reviews statisch analysiert.
2.1.2 Dynamische Qualitätsmerkmale
Dynamische Qualitätsmerkmale beziehen sich auf das Funktionieren des DV-Systems. Die Betrachtung jener Aspekte erfolgt aus der Sicht des zukünftigen Systemanwenders (Koomen/Pol/Spillner, 2000, S.279 und S.282-283). Die internationale Norm ISO 9126 bestimmt einerseits zwar
Softwarequalitätskriterien, beschreibt aber gleichzeitig, dass nur wenige allgemein anerkannte Methoden zur Bestimmung von Softwarequalität existieren. In der Norm wird daher empfohlen, eigene Modelle und Verfahren zur Messung der Softwarequalität zu entwickeln (Lindermeier/Siebert, 1995, S.11). Einige der wichtigsten dynamischen Qualitätsmerkmale werden im Folgenden näher betrachtet, da diese im Rahmen von Softwaretests eine bedeutende Rolle spielen. Die Beschreibung der dynamischen Qualitätsmerkmale erfolgt im Wesentlichen auf Basis des Testkonzepts TMap. Es handelt sich hierbei um ein strukturiertes Testkonzept für Systeme der Informationstechnologie, wobei TMap für ‚Test Management approach‘ steht (Koomen/Pol/Spillner, 2000, S.183).
5
Zwecks Referenzierung zur Norm ISO 9126 wurde für die dynamischen Qualitätsmerkmale Funktionalität, Leistung, Kontinuität und
Benutzungsfreundlichkeit die folgende Umsetzungstabelle entwickelt:
Abbildung 1: Umsetzungstabelle Qualitätsmerkmale TMap und ISO 9126 (in Anlehnung an Koomen/Pol/Spillner, 2000, S.535)
2.1.2.1 Funktionalität
Als Funktionalität bezeichnet man die Sicherheit, dass die durch die Software zu erfolgende Datenverarbeitung korrekt und vollständig sowie gemäß der Beschreibung in der Fachspezifikation erfolgt (Koomen/Pol/Spillner, 2000, S.281).
Solange es sich um arithmetische und logische Funktionen handelt, kann die Anforderungsdefinition eindeutig durch mathematische Formeln beschrieben werden. In der Praxis werden große Teile im Fachkonzept häufig in der Umgangssprache beschrieben. Dies kann zu Unvollständigkeit, Mehrdeutigkeit und Missverständlichkeit in der fachlichen Beschreibung führen. Bei der Prüfung eines Software-Produkts auf Funktionserfüllung ist zunächst sicherzustellen, dass die Fachspezifikation vollständig und korrekt ist. Der zu einem späteren Zeitpunkt stattfindende Softwaretest verifiziert schließlich, ob das entwickelte Programm der Anforderungsdefinition entspricht (Trauboth, 1996, S.32).
6
Das Qualitätsmerkmal Funktionalität ist somit nach den Merkmalen Vollständigkeit und Korrektheit zu unterscheiden:
• Vollständigkeit: Hierunter versteht man die Sicherheit, dass alle Eingaben und Änderungen vom DV-System verarbeitet werden.
• Korrektheit: Das Merkmal Korrektheit ist erfüllt, wenn die Software die angebotenen Eingaben und Änderungen korrekt gemäß den Vorgaben des Fachkonzepts zu konsistenten Datensammlungen verarbeitet (Koomen/Pol/Spillner, 2000, S.281).
Um festzustellen, ob eine Anwendung korrekt arbeitet, sind folgende fünf Aspekte zu beachten:
• Das Programm liefert auf eine gültige Eingabe die korrekte Ausgabe. • Das Programm weist eine ungültige Eingabe korrekt und angemessen zurück. • Das Programm stürzt sowohl bei ungültigen als auch bei gültigen Eingaben nicht ab.
• Das Programm wird so lange korrekt ausgeführt, wie es in der Fachspezifikation definiert ist.
• Das Programm verhält sich gemäß der fachlichen Beschreibung in der Anforderungsdefinition (Dustin/Paul/Rashka, 2000, S.135-136). Das dynamische Qualitätsmerkmal Funktionalität stellt häufig das wichtigste Kriterium dar, um beim Anwender die Akzeptanz des IT-Systems zu erreichen. Es ist daher sicherzustellen, dass die entwickelte Software der spezifizierten Funktionalität entspricht (Koomen/Pol/Spillner, 2000, S.281).
2.1.2.2 Leistung
Die Leistung eines Software-Produkts drückt sich zum einen im Zeitverhalten bzw. in der Geschwindigkeit, mit der interaktive und Batch-Verarbeitungen ausgeführt werden, und zum anderen in der Inanspruchnahme von Betriebsmitteln
7
aus. Leistungsmerkmale, die dem Zeitverhalten zugeordnet werden, sind beispielsweise der Zeitaufwand für die Ausführung einer Funktion, der Durchsatz von verarbeiteten Daten oder das Antwortzeitverhalten, also die verstrichene Zeit, bis auf ein auslösendes Ereignis reagiert wird. Leistungsmerkmale, die sich auf die Inanspruchnahme von Betriebsmitteln beziehen, sind zum einen die Menge, die Häufigkeit und die Zeitdauer des benutzten Speicherplatzes für Programme und Daten und zum anderen die Häufigkeit des Zugriffs und die Dauer der Belegung von externen Dienstleistungsfunktionen (Trauboth, 1996, S.33).
2.1.2.3 Kontinuität
Als Kontinuität bezeichnet man sowohl die Sicherheit, dass die Datenverarbeitung ungestört ablaufen kann, als auch die Eigenschaft eines Systems, dass diese auch nach ernsthaften Störungen innerhalb einer akzeptablen Zeitspanne wieder fortgeführt werden kann. Das Qualitätsmerkmal Kontinuität kann anhand mehrerer Kriterien differenziert werden, die bei einer sich ausbreitenden Störung des DV-Systems Anwendung finden:
• Als Betriebssicherheit bezeichnet man den Umfang, in dem die Informationsverarbeitung ungestört bleibt.
• Die Robustheit ist eine Angabe darüber, inwieweit mit den Daten auch nach einer Störung weiter gearbeitet werden kann.
• Die Wiederherstellbarkeit ist ein Indiz dafür, wie schnell und wie einfach die Informationen nach einer Störung reproduziert werden können. Schließlich zeichnen sich Programme, die das Qualitätsmerkmal Kontinuität erfüllen, dadurch aus, dass nach dem Ausfall von Teilen des Systems oder der Feststellung der Fehlerhaftigkeit mit geringem Aufwand die Kernfunktionalität der Anwendung weiterhin erhalten werden kann (Koomen/Pol/Spillner, 2000, S.280).
8
2.1.2.4 Benutzungsfreundlichkeit
Die Benutzungsfreundlichkeit drückt sich in der Mühelosigkeit aus, mit der ein Anwender mit der Software interagieren kann. Da sich der Grad der Benutzungsfreundlichkeit nur schwer messen lässt, sind bei der Bewertung dieses Qualitätskriteriums durchaus subjektive Meinungen gefragt. Die Einschätzung der zukünftigen Nutzer des Systems spielt bei der Feststellung der Benutzungsfreundlichkeit eine wichtige Rolle (Koomen/Pol/Spillner, 2000, S.281).
Man kann ferner zwischen dem zeitlichen Aufwand für den Benutzer und der sogenannten Handhabbarkeit der Anwendung unterscheiden. Dem zeitlichen Aufwand können beispielsweise die Zeit zum Erlernen der Bedienung der Software, die Zeit und die Anzahl der Schritte, um Fehlersituationen zu erkennen und zu beheben oder die Zeit für das Warten auf eine Systemreaktion nach einer Kommando-Eingabe zugeordnet werden. Der Grad der Handhabbarkeit eines Programms wird unter anderem durch die Anzahl und die Komplexität der Bedienungsschritte im Verhältnis zur auszuführenden Funktion, die Übersichtlichkeit der Informationsdarstellung, die Unterstützung beim Fehlerhandling und durch die Benutzerführung in der Anwendung determiniert (Trauboth, 1996, S.34).
Benutzungsfreundlichkeit kann in einem IT-System erreicht werden, indem die Entwicklung der Benutzungsoberfläche nach softwareergonomischen
Gesichtspunkten erfolgt (Pagel/Six, 1994, S.53). Die Software-Ergonomie befasst sich mit der menschengerechten Gestaltung von interaktiven Programmsystemen im Rahmen computergestützter Arbeit sowie mit der Benutzerfreundlichkeit von DV-Systemen (Carl von Ossietzky Universität Oldenburg, Abruf am 12.7.2001). Beispiele für die softwareergonomische Gestaltung von Benutzungsoberflächen sind die Implementierung von grafischen Oberflächen in Fenstertechnik sowie der adäquate und systematische Einsatz von Farben und Formen bei der Darstellung von einzelnen Elementen. Die Verfügbarkeit von Hilfefunktionalitäten in Abhängigkeit vom jeweiligen Systemzustand sowie die Möglichkeit, die Art der
9
Interaktion mit dem System in einem gewissen Umfang an den Kenntnisstand des Anwenders anzugleichen (z.B. durch Automatisierung von Routinevorgängen mittels eines Makros oder durch verkürzte Menüsteuerungen), erhöhen ebenfalls den Benutzerkomfort (Pagel/Six, 1994, S.53).
2.2 Kosten und Nutzen von Softwarequalität
Der Nutzen eines DV-Systems wird durch die Übereinstimmung zwischen dem Software-Produkt und den tatsächlichen Anforderungen bestimmt. Zusätzliche Leistungen und Eigenschaften der Anwendung, die in der Fachspezifikation nicht explizit gefordert waren, können darüber hinaus ebenfalls als nützlich und vorteilhaft empfunden werden. Mit Hilfe moderner Informationstechnologie sollen betriebliche Abläufe rationaler gestaltet und die Produktivität erhöht werden. Darüber hinaus verfolgen Unternehmen mit Hilfe der IT die Realisierung von Nutzenpotenzialen durch strategische Maßnahmen, um beispielsweise Innovationsvorsprünge gegenüber Marktkonkurrenten zu erzielen. Der Nutzen einer Softwareentwicklung, der in der Regel schwieriger zu quantifizieren ist als die Kosten, kann nur dann realisiert werden, wenn das Produkt den im Pflichtenheft spezifizierten Qualitätsmerkmalen entspricht
(Frühauf/Ludewig/Sandmayr, 2000, S.17).
Die wirtschaftlichen Auswirkungen von Qualitätsmängeln verdeutlicht das Beispiel des Flugbuchungssystems SABRE von American Airlines. Das Unternehmen konnte 1987 einen Umsatz von ca. 50 Millionen US-Dollar nicht realisieren, weil nach der Änderung einer Softwareeinheit im Reservierungssystem über Monate hinweg Flüge bereits als ausgebucht angezeigt wurden, obwohl noch Plätze vorhanden waren
(Bodendorf/König/Mertens/Picot/Schumann, 1998, S.169). Die Kosten eines Software-Produkts können in Herstellungskosten und Qualitätskosten differenziert werden. Während den Herstellungskosten alle Aufwendungen zugerechnet werden, die sich auf das Erbringen der gemäß Fachkonzept geforderten Leistung beziehen, werden den Qualitätskosten die
10
Aufwendungen für das Verhüten, Erkennen, Lokalisieren und Beheben von Fehlern sowie die Folgekosten der Fehler, die im Betrieb auftreten, zugeordnet. Je größer das Risiko von Folgekosten und Garantieleistungen ist, desto mehr Sinn macht die Investition in Prävention und Prüfung (Frühauf/Ludewig/Sandmayr, 2000, S.17).
Die folgende Abbildung veranschaulicht die unterschiedlichen Kostenarten eines Software-Produkts:
Abbildung 2: Aufteilung der Softwarekosten
(in Anlehnung an Frühauf/Ludewig/Sandmayr, 2000, S.18). Im Folgenden soll kurz erläutert werden, durch welche Maßnahmen zur Sicherstellung der Softwarequalität die genannten Kostenarten beeinflusst werden:
• Fehlerverhütungskosten entstehen durch Vorbeugemaßnahmen, die Qualitätsmängel verhindern sollen. Zu nennen sind in diesem Zusammenhang z.B. Dokumentationsrichtlinien oder Methoden und Techniken zur Softwareentwicklung.
• Prüfkosten werden durch sogenannte Prüf- und Beurteilungsmaßnahmen generiert, die Qualitätsmängel entdecken sollen. Beispiele hierfür sind
11
statische Analyseverfahren wie Inspektionen und Reviews sowie die Durchführung von Softwaretests.
• Zu den Fehlerkosten zählen Folgekosten, die beispielsweise für Kulanzzahlungen anfallen, Garantiekosten, die sich aus vertraglichen Verpflichtungen zur Garantieleistung ergeben und Fehlerbehebungskosten, die aus Korrekturmaßnahmen entstehen. Korrekturmaßnahmen haben die Aufgabe, den Mangel an Qualität zu beheben. Beispielhaft sei die Korrektur von Fehlern genannt, die durch Softwaretests entdeckt wurden (Koomen/Pol/Spillner, 2000, S.12).
Alle Maßnahmen zur Sicherstellung der Softwarequalität beinhalten das Ziel von möglichst wenigen Fehlern in dem erstellten Produkt. In der US-Industrie geht man von einer durchschnittlichen Rate von bis zu 10 Fehlern je 1.000 ausgelieferten Zeilen Quellcode aus (Trauboth, 1996, S.15). Die Folgen eines Fehlers, der erst während der Betriebsphase des IT-Sytems auftritt, können sehr unterschiedliche Ausmaße annehmen. Genannt seien in diesem Zusammenhang die Verschwendung von Material und Energie, Rückrufaktionen bereits ausgelieferter Produkte sowie extreme finanzielle Verluste aufgrund von Softwarefehlern in vernetzten Banksystemen oder in
Telefonvermittlungssystemen. Im schlimmsten Fall können Menschen zu Schaden kommen.
Das Ideal einer fehlerfreien Software ist jedoch üblicherweise wirtschaftlich nicht realisierbar. Daher ist eine Minimierung der Qualitätskosten anzustreben, indem die Aufwendungen für Fehlerverhütungs- und Prüfkosten mit den Einsparungen bei den Fehlerkosten in Einklang gebracht werden (Frühauf/Ludewig/Sandmayr, 2000, S.18).
12
In Abbildung 3 wird der Zusammenhang zwischen den verschiedenen Kostenarten dargestellt:
Abbildung 3: Qualitätskosten
(in Anlehnung an Koomen/Pol/Spillner, 2000, S.13)
Festzuhalten bleibt, dass das Streben nach perfekter Qualität aus wirtschaftlichen Gesichtspunkten nicht sinnvoll ist, da ab einem gewissen Zeitpunkt jeder kleine Gewinn an Qualität immer größere Investitionen bedingt. Das Testen von Software macht ökonomisch so lange Sinn, wie die Kosten für das Finden und die Beseitigung eines Fehlers niedriger sind als die Kosten, die ein Fehler während der Betriebsphase der Anwendung verursacht (Koomen/Pol/Spillner, 2000, S.14).
13
3 Qualitätssicherung
Die Qualitätssicherung ist die Summe aller geplanten und systematischen Aktionen, welche dazu dienen, die für das zugrundeliegende Software-Produkt festgelegten Qualitätsanforderungen zu erzeugen (Koomen/Pol/Spillner, 2000, S.12).
Die Qualität darf nicht als eine lästige Forderung angesehen werden, die nach der Erstellung eines DV-Systems durch Eliminierung von Fehlern nachträglich erzeugt wird. Vielmehr muss Qualität durch gezielte Maßnahmen in ein Software-Produkt eingebaut werden. Um dies zu erreichen, bedarf es einer strukturierten Planung der Qualitätssicherung, die mit den übrigen Aufgaben des Projektmanagements harmonisiert. Die Qualitätsanforderungen an die herzustellende Anwendung müssen zu Beginn der Entwicklung definiert werden, um die Qualität im Rahmen der vorgegebenen Kosten und Termine zu optimieren. Aus einer Vielzahl relevanter Qualitätsmerkmale müssen diejenigen ermittelt werden, die für das betreffende Produkt die höchste Bedeutung haben. Diese Kriterien müssen gewichtet und quantifiziert werden. Die Qualitätsanforderungen sind anschließend als verpflichtend in der Fachspezifikation bzw. im Pflichtenheft festzuhalten (Trauboth, 1996, S.87).
Wie bereits in Kapitel 2 kurz angesprochen, können sich Unternehmen aus der EDV-Branche beim Aufbau eines Qualitätssicherungssystems an den Forderungen der DIN ISO 9000 orientieren. Dabei ist zu beachten, dass die DIN ISO 9000 Teil 3 nicht die gültige Norm, sondern ein Leitfaden für die Herstellung von Software ist. Um die Zertifizierung zu erlangen, wird die DIN ISO 9001 für Qualitätsmanagementsysteme als verbindliche Norm benötigt. Es existieren eine Reihe von Gründen, eine Zertifizierung im Bereich der Qualitätssicherung anzustreben. Neben dem Druck des Wettbewerbs und des Marktes, sich mit der Zertifizierung auseinanderzusetzen, eröffnet die Beschäftigung mit der Norm auch die Möglichkeit, die Strukturen und Prozesse einer Organisationseinheit auf Richtigkeit und Effizienz hin zu untersuchen. Dabei ist allerdings zu beachten, dass erfolgreiche Qualitätssicherung nicht durch bloße Orientierung an Normen
14
entsteht. Vielmehr müssen Unternehmen auf die Bedürfnisse und Forderungen ihrer Kunden eingehen, branchenspezifische Bedingungen berücksichtigen und dabei die eigenen Mitarbeiter nicht außen vor lassen. Es ist daher neben dem Studium der Forderungen der Normen essenziell, sich zu fragen, wie diese in der eigenen Unternehmung sinnvoll realisiert werden können (Thaller, 1996 (a), S.32-35).
Je früher ein Fehler im Entwicklungsprozess eines DV-Systems gemacht und je später er gefunden wird, desto höher ist der Aufwand für die Korrektur. Wenn ein Fehler entdeckt wird, muss die Software korrigiert und erneut getestet werden. Die Kosten der Korrektur korrelieren dabei stark positiv mit dem Zeitpunkt, zu dem der Fehler bemerkt wurde (Pagel/Six, 1994, S.46-47). Ein Fehler, der in einem frühen Stadium des Softwareentwicklungsprozesses entdeckt wurde, lässt sich mit relativ wenigen Ressourcen beheben und wirkt sich nicht auf die Betriebsphase der Anwendung aus. Ein Fehler, der erst nach der Inbetriebnahme des IT-Systems festgestellt wird, kann mehrere Organisationen betreffen, umfangreiche erneute Tests zur Folge haben und schließlich Ausfallzeiten für den Betrieb der Software verursachen (Dustin/Paul/Rashka, 2000, S.8).
15
Die folgende Tabelle veranschaulicht, dass sich die Kosten für die Fehlerbeseitigung im Verlauf der Systementwicklung multiplizieren:
Abbildung 4: Vorbeugen ist billiger als heilen!
(in Anlehnung an Dustin/Paul/Rashka, 2000, S.9)
Es ist deutlich geworden, dass wirksame Maßnahmen der Kostensenkung das Ziel haben müssen, einen Fehler so früh wie möglich festzustellen und zu beheben bzw. diesen erst gar nicht entstehen zu lassen. Die schwerwiegendsten Fehler werden häufig in den frühen Phasen der Softwareentwicklung gemacht, demnach in den Phasen der Analyse bzw. Beschreibung der fachlichen Anforderungen sowie der Entwurfsphase des DV-Konzepts. Entwicklungen von DV-Systemen bedingen aufgrund ihrer Größe und Komplexität umfangreiche und komplizierte Fachspezifikationen, die das menschliche Beurteilungsvermögen oft überfordern. Die Anforderungsdefinitionen von Software-Produkten sind daher häufig nicht detailliert genug und enthalten Fehler oder widersprüchliche Aussagen. Die Konsequenzen einer unzulänglichen Systemspezifikation sind
schwerwiegend, da diese die Basis für die weiteren Phasen der Softwareentwicklung darstellt. Um solche fundamentalen Fehler in den frühen Phasen des Softwareentwicklungsprozesses zu verhindern, haben sich unterschiedliche Methoden der analytischen Qualitätssicherung bewährt. Das
16
Testen von Software hat als eine die Entwicklung begleitende Tätigkeit die Aufgabe, Fehler so früh wie möglich aufzudecken. In jeder Entwicklungsphase sollten Testfälle für nachfolgende Tests definiert werden. Im Gegensatz zu dieser dynamischen Methode der analytischen Qualitätssicherung dienen beispielsweise Inspektionen oder Reviews als statische Maßnahmen der Validierung von Produktdefinitionen. Während die analytische Qualitätssicherung der Fehlerfindung dient, hat die konstruktive Qualitätssicherung die Fehlervermeidung zum Ziel (Pagel/Six, 1994, S.47). Die konstruktive Qualitätssicherung befasst sich mit der Durchsetzung von Prinzipien im Rahmen des Software Engineering. Hierunter versteht man moderne Verfahren der Softwareentwicklung, die dem Softwareentstehungsprozess zugrunde gelegt werden. Unter Heranziehung von Standards, Hilfsmitteln und Werkzeugen, die beispielsweise im Rahmen von Konsistenz- und Vollständigkeitsprüfungen wertvolle Dienste leisten, lässt sich die Softwarequalität erhöhen, indem der Entwicklungsprozess und die Dokumentation vereinheitlicht werden (Carl von Ossietzky Universität Oldenburg, Abruf am 12.7.2001). Die Wiederverwendung korrekter Softwarekomponenten liefert ebenfalls einen Beitrag zur Fehlervermeidung, da die Wahrscheinlichkeit von Fehlern in bereits sorgfältig getesteten und qualitätsgesicherten Modulen im Vergleich zu neu entwickelten Komponenten wesentlich geringer ist. Große Probleme bereitet die Tatsache, wenn ein in Bezug auf die Fachspezifikation durchaus korrektes DV-System dennoch nicht den Erwartungen des Auftraggebers entspricht. Die Ursache hierfür kann beispielsweise in einer viel zu ungenauen Produktdefinition liegen (Pagel/Six, 1994, S.47-48). In diesem Zusammenhang sollen die beiden Begriffe Verifikation und Validation kurz erläutert werden, die innerhalb des Prüfprozesses zwei unterschiedliche Aspekte betrachten. Im Rahmen der Verifikation wird gegen Ende einer Phase überprüft, ob die spezifizierten Qualitätskriterien eines Produkts mit den tatsächlichen Merkmalen übereinstimmen. Als Prüfobjekte kommen alle Zwischenprodukte in Frage, die während des Entwicklungsprozesses erzeugt
17
werden. Die Verifikation des Softwareentwurfs überprüft beispielsweise, ob die Entwickler die Systemarchitektur sowie die Definition und Struktur der einzelnen Systemkomponenten korrekt erstellt haben. Die Validation prüft die Tauglichkeit eines Produkts für seine vorgesehene Aufgabe. Sie beantwortet letztlich auch die Frage, ob die entwickelte Systemanwendung den Anforderungen des Auftraggebers entspricht (Trauboth, 1996, S.153).
Die Änderung von Software, die nicht der Vorstellung des Kunden entspricht, gehört zu den kostenintensivsten Aufwendungen im Rahmen der Softwareentwicklung. Abhilfe schafft hier die rasche Erstellung von Prototypen für relevante Teile des Systems, die dem Auftraggeber frühzeitig zur Überprüfung der Anforderungsdefinition vorgeführt werden. Der Prototyp als Diskussionsbasis offeriert die Möglichkeit, den Entwicklern die Vorstellungen der Anwender transparent zu machen und das Risiko von Missverständnissen zu vermindern (Pagel/Six, 1994, S.47-48).
Eine weitere Kategorisierung der Qualitätssicherung erstreckt sich auf die organisatorischen Maßnahmen bzw. das Management der Qualitätssicherung. Hierunter versteht man organisatorische und ablauftechnische Regelungen, die Überwachung qualitätsrelevanter Maßnahmen, die Schulung von Mitarbeitern sowie Beratungsleistungen für die Planung von Prüfungen oder die Auswahl von Werkzeugen (Trauboth, 1996, S.91-95).
18
Den Zusammenhang der einzelnen Maßnahmen der Qualitätssicherung veranschaulicht die folgende Grafik:
Abbildung 5: Maßnahmen der Software-Qualitätssicherung (aus einer Vortragsunterlage anlässlich eines Workshops der AXA Krankenversicherung AG, Feldmann, 2001)
In den folgenden Abschnitten werden die organisatorischen, konstruktiven und analytischen Maßnahmen der Software-Qualitätssicherung näher erläutert.
3.1 Organisatorische Maßnahmen und Management der Qualitätssicherung
Qualitätsmanagement wird in der internationalen Norm ISO 8402 folgendermaßen definiert: Das Qualitätsmanagement umfasst alle Aktivitäten des Gesamtmanagements, die im Rahmen des Qualitätsmanagement-Systems die Qualitätspolitik, die Ziele und Verantwortungen benennen sowie diese mittels Qualitätsplanung, Qualitätslenkung, Qualitätsmanagement und
Qualiätsverbesserung realisieren.
19
Das ‚Institute of Electrical and Electronic Engineers‘ (IEEE) beschreibt in seinem ‚Standard for Software Quality Metric Methodology‘ (IEEE88) die folgenden wesentlichen Aufgaben des Qualitätsmanagements: • Festlegung von Qualitätsanforderungen in Form von Qualitätsmerkmalen bereits in frühen Phasen der Softwareentwicklung durch das Qualitätsmanagement. • Information der Softwareentwickler über die vereinbarten Qualitätsanforderungen.
• Vereinbarung von Messkriterien für die festgelegten Qualitätsmerkmale. • Bereitstellung von Messwerkzeugen, um das Qualitätsmaß zu bestimmen. • Bewertung von Software-Produkten und Software-Prozessen bezüglich der elementaren Qualitätsmaße.
• Analyse der Messergebnisse zwecks Einschätzung und Verbesserung von Produkt- und Prozessqualität.
Diese Aussagen verdeutlichen, dass sich das Management der Software-Qualitätssicherung sowohl mit dem herzustellenden Produkt, als auch mit dem Erstellungsprozess selbst beschäftigt. Die eigentliche Entwicklung der Software und das Management der Qualitätssicherungsmaßnahmen sind innerhalb des Erzeugungsprozesses kaum zu trennen. Das Qualitätsmanagement ist somit integraler Bestandteil des Managements der Softwareentwicklung und bezieht sich auf alle Phasen, alle (Zwischen-)Produkte, alle Mitarbeiter sowie auf alle Ebenen und Aktivitäten (Planung, Durchführung, Überprüfung und Lenkung) und somit auf das Qualitätsmanagement selbst (DGQ/ITG, 1995, S.11-12). Als eine wesentliche Aufgabe der organisatorischen Qualitätssicherung erachtet das ‚Institute of Electrical and Electronic Engineers‘ (IEEE) die Erstellung eines Handbuchs zur Software-Qualitätssicherung. Dieses Handbuch enthält für ein Unternehmen oder einen Bereich verbindliche Angaben bezüglich des geltenden Qualitätssicherungs-Systems. Es ist festzuhalten, wer welche Aufgaben
20
Arbeit zitieren:
Stefan Elfgen, 2002, Konzept zur Implementierung eines Testwerkzeugs für die Automatisierung von Black-Box-Testverfahren, München, GRIN Verlag GmbH
Dieser Text kann über folgende URL aufgerufen und zitiert werden:
Einbetten
DOI
Formatvorlage (Microsoft Word) für eine Diplomarbeit, Masterarbeit, Ha...
Für MS Word 2003 - Update 2010
Vorlagen, Muster, Formulare, Infobroschüren
Ausarbeitung, 25 Seiten
Formatvorlage (OpenOffice) für eine Diplomarbeit, Masterarbeit, Hausar...
Vorlagen, Muster, Formulare, Infobroschüren
Ausarbeitung, 35 Seiten
Formatvorlage / Vorlage zur Erstellung einer Diplomarbeit, Bachelorarb...
Vorlagen, Muster, Formulare, Infobroschüren
Ausarbeitung, 15 Seiten
Formatvorlage / Vorlage für eine Diplomarbeit / Hausarbeit
Für MS Word 2007 - dotx
Vorlagen, Muster, Formulare, Infobroschüren
Ausarbeitung, 25 Seiten
Anleitung zum Erstellen schriftlicher Arbeiten: Der Aufbau einer wisse...
Vorlagen, Muster, Formulare, Infobroschüren
Ausarbeitung, 20 Seiten
Erstellen einer schriftlichen Hausarbeit
Vorlagen, Muster, Formulare, Infobroschüren
Hausarbeit, 14 Seiten
Grundtechniken wissenschaftlichen Arbeitens
Bibliografieren - Reden - Schr...
Vorlagen, Muster, Formulare, Infobroschüren
Skript, 46 Seiten
Ratgeber zur Erstellung wissenschaftlicher Arbeiten. Diplomarbeiten - ...
Vorlagen, Muster, Formulare, Infobroschüren
Ausarbeitung, 39 Seiten
Stefan Elfgen's Text Konzept zur Implementierung eines Testwerkzeugs für die Automatisierung von Black-Box-Testverfahren ist nun auf dem Buchmarkt erhältlich
Stefan Elfgen hat den Text Konzept zur Implementierung eines Testwerkzeugs für die Automatisierung von Black-Box-Testverfahren veröffentlicht
Stefan Elfgen hat einen neuen Text hochgeladen
0 Kommentare