3 Manuelle Prüfmethoden 5 Produktqualität Komponenten: Testende Verfahren 1 6 Produktqualität Systeme: System- und Abnahmetest

Transkript

1 1 Software-Qualitätssicherung 3 Manuelle Prüfmethoden 5 Produktqualität Komponenten: Testende Verfahren 1 6 Produktqualität Systeme: System- und Abnahmetest

2 2 Inhalt 3.1 Manuelle Prüfmethoden Inspektion Review Walkthrough Weitere Prüfmethoden.

3 3 3.1 Manuelle Prüfmethoden Qualität Sicherstellung durch konstruktive und analytische Maßnahmen Automatisierte Prüfungen Syntax-, Konsistenz- und Vollständigkeitsprüfungen durch Software-Werkzeuge automatisiert durchführbar Manuelle Prüfungen Semantische Überprüfungen müssen manuell vorgenommen werden Breiter Einsatzbereich Wesentliche Prüfmethoden Inspektionen / Reviews / Walkthrough.

4 4 3.1 Manuelle Prüfmethoden Gemeinsame Eigenschaften manueller Prüfmethoden Produkte und Teilprodukte werden manuell analysiert, geprüft und begutachtet Ziel: Finden von Fehlern, Defekten, Inkonsistenzen und Unvollständigkeiten Überprüfung erfolgt in einer Gruppensitzung durch ein kleines Team mit definierten Rollen.

5 5 3.1 Manuelle Prüfmethoden Voraussetzungen Notwendiger Aufwand und benötigte Zeit müssen fest eingeplant sein Jedes Mitglied des Prüfteams muß in der Prüfmethode geschult sein Prüfergebnisse dürfen nicht zur Beurteilung von Mitarbeitern benutzt werden Die Prüfmethode muß schriftlich festgelegt und deren Einhaltung überprüft werden Prüfungen haben hohe Priorität Sie sind nach der Prüfbeantragung kurzfristig durchzuführen Vorgesetzte und Zuhörer sollen an den Prüfungen nicht teilnehmen.

6 6 3.1 Manuelle Prüfmethoden Bewertung + Oft einzige Möglichkeit, Semantik zu überprüfen + Funktionierende Überprüfungen sind ein effizientes Mittel zur Qualitätssicherung + Notwendige Ergänzung werkzeuggestützter Überprüfungen + Verantwortung für die Qualität der geprüften Produkte wird vom ganzen Team getragen + Verbreiterung der Wissensbasis der Telnehmer, da die Überprüfungen in einer Gruppensitzung durchgeführt werden + Jedes Mitglied des Prüfteams lernt die Arbeitsmethoden seiner Kollegen kennen.

7 7 III Software-QS - Manuelle Prüfmethoden 3.1 Manuelle Prüfmethoden + Autoren bemühen sich um eine verständliche Ausdrucksweise, da mehrere Personen das Produkt begutachten + Unterschiedliche Produkte desselben Autors werden von Prüfung zu Prüfung besser In der Regel aufwendig Bis zu 20% der Erstellungskosten des zu prüfenden Produkts Autoren geraten u. U. in eine psychologisch schwierige Situation»Sitzen auf der AnklagebankMüssen sich verteidigen«.

8 8 3.1 Manuelle Prüfmethoden Unterschiede: Ziele Inspektion Schwere Defekte im Prüfobjekt identifizieren Entwicklungsprozeß verbessern Inspektionsprozeß verbessern Metriken ermitteln Review Stärken/Schwächen im Prüfobjekts identifizieren Optional: Entwicklungsprozeß verbessern Walkthrough Defekte und Probleme des Prüfobjekts identifizieren Ausbildung von Benutzern und Mitarbeitern.

9 9 3.1 Manuelle Prüfmethoden Unterschiede: Teilnehmer Inspektion Moderator, Autor, Gutachter, Protokollführer, optional: Vorleser Review Moderator, Autor, Gutachter, Protokollführer Walkthrough Autor = optional: Moderator, Gutachter.

10 Manuelle Prüfmethoden Unterschiede: Durchführung Inspektion Eingangsprüfung, Planung, optional: Einführungssitzung, Individuelle Vorbereitung & Prüfung, Gruppensitzung, Überarbeitung, Nachprüfung, Freigabe Review optional: Eingangsprüfung, Planung, optional: Einführungssitzung, Individuelle Vorbereitung & Prüfung, Gruppensitzung, Überarbeitung, Nachprüfung Walkthrough optinal: individuelle Vorbereitung & Prüfung, Gruppensitzung.

11 Manuelle Prüfmethoden Unterschiede: Referenzunterlagen Inspektion Ursprungsprodukt Erstellungsregeln Checklisten Inspektionsregeln Inspektionsplan Review Ursprungsprodukt Erstellungsregeln Fragenkataloge Walkthrough Keine.

12 Manuelle Prüfmethoden Unterschiede: Charakteristika Inspektion Ausgebildeter Moderator Prüfobjekt wird vom Vorleser Absatz für Absatz vorgetragen Moderator gibt Freigabe Review Ausgebildeter Moderator Prüfteam gibt Empfehlung an Manager Walkthrough Prüfobjekt wird vom Autor ablauforientiert vorgetragen Autor entscheidet.

13 Inspektion Formular zur Erfassung von Inspektionsdaten III Software-QS - Manuelle Prüfmethoden Zusammenfassung der Inspektionsdaten Datum: Nummer der Inspektion: OOA15 Moderator: Schulz Prüfobjekt: OOA-Modell Seminarorganisation V1.1 Anzahl Seiten: 15 Datum der Inspektionsanforderung: Datum der Eingangsprüfung: (1) Planungszeit: 1,2 h (2) Aufwand für die Eingangsprüfung: 0,3 h (3) Aufwand für die Einführungssitzung: 1,0 h (10 min * 6 Teilnehmer) Individuelle Prüfergebnisse (berichtet am Anfang der Inspektionssitzung) Inspektor Prüfzeit Anzahl schwere leichte Verbesse- Fragen Prüfgeschw. (a) h gepr. Defekte Defekte rungen (b)(a) Seiten (b) 1 3, ,11 2 1, ,11 3 2,8 3, ,25 4 4, ,19 5 2,4 2, ,08 6 Summe 14,9(4) Durchschnittliche Prüfgeschwindigkeit: 1,35 Seitenh Inspektionssitzung (Prüfeinheit = 4 Seiten) Anzahl Teilnehmer: 6 Dauer: 1,72 h (5) Arbeitsstunden insgesamt: 10,3 h Schwere Defekte Leichte Defekte Verbesserungs- Fragen a.d. Neue Defekte protokolliert protokolliert vorschläge Autor i.d. Sitzung entdeckt Erfassungsgeschwindigkeit: 0,84 (ProtokolleinträgeMinute) (87103,2) (11) Bisheriger Gesamtzeitaufwand: 27,7 h (1)+(2)+(3)+(4)+(5) Anzahl geprüfter Seiten pro Stunde: 2,33 (SeitenDauer) Überarbeitung, Nachüberprüfung und Freigabe Anzahl schwerer Defekte: 29 Anzahl leichter Defekte: 54 Anzahl Änderungsanträge: 3 (6) Überarbeitungszeit: 16,6 h (7) Nachüberprüfungszeit: 1,5 h (8) Freigabezeit: 0,6 h Freigabedatum: (9) Überprüfungszeit: 4,6 h (1)+(2)+(3)+(7)+(8) (10) Defektentfernungszeit: 46,4 h (11)+(6)+(7)+(8) Geschätzte Restdefekte (schwere Defekte) Seite: 6,04 (Annahme: 60% Effektivität, 1 von 6 Defekten fehlerhaft korrigiert = 16,6 %) (29 schwere Defekte4 Seiten = 7,25 Defekte korrigiertseite) (60% Effektivität: 7,25 = 60%, 40% Restfehler = 4,83 FehlerSeite) (16,6% fehlerhaft korrigiert: 7,25 * 0,166 = 1,21 Defekte pro Seite) Geschätzte Effektivität (%gebundene schwere DefekteSeite): 60 % (Annahme oder Empirie) Effizienz (schwere DefekteArbeitszeit (9)+(10)) =0,57 schwere DefekteStunde (2951) Wahrscheinliche Einsparung von Entwicklungszeit durch die Inspektion: 139,2 h (basierend auf 8 oder 6,4 Stundenschwerem Defekt) (46,4 Stunden (10) für 29 Defekte = 1,6 Stunden pro schwerem Defekt Annahme: Wenn ein Defekt später gefunden wird, dann werden 6,4 Stunden pro schwerem Defekt benötigt, das ergibt 29 * 6,4 = 185,6 Stunden, Eingesparte Zeit = 185,6 Stunden 46,6 Stunden = 139,2 Stunden)

14 Inspektion Empirische Ergebnisse Faustregeln 50 bis 75% aller Entwurfsfehler können durch Inspektionen gefunden werden Code-Inspektionen sind ein sehr kosteneffektiver Weg, um Defekte aufzudecken.

15 Review Review Mehr oder weniger formalisierter Prozeß zur Überprüfung von schriftlichen Dokumenten durch Gutachter, um Stärken und Schwächen des Dokuments festzustellen Gegenüber einer Inspektion weniger formalisiert Gegenüber einem Walkthrough stärker formalisiert.

16 Walkthrough III Software-QS - Manuelle Prüfmethoden Vorteile + Geringer Aufwand + Auch für kleine Entwicklungsteams geeignet (bis zu 5 Mitarbeiter) + Sinnvoll für»unkritische«dokumente + Durch Einbeziehung von Endbenutzern als Gutachter können Unvollständigkeiten und Mißverständnisse aufgedeckt werden + Gut geeignet, um das Wissen über ein Dokument auf eine breite Basis zu stellen Nachteile Es werden wenig Defekte identifiziert Der Autor kann die Walkthrough-Sitzung dominieren und die Gutachter»blenden«Eine Überarbeitung des Prüfobjekts liegt in dem Ermessen des Autors Sie wird nicht nachgeprüft.

17 Weitere Prüfmethoden Stellungnahme Autor bittet ein oder mehrere Kollegen um Kommentare zu einem Prüfobjekt Autor gibt den Kollegen Kopien der Prüfobjekte Er erhält diese dann mit mehr oder weniger ausführlichen Kommentaren zurück Einfach Benötigt keine Ausbildung Keine Planung Kann kurzfristig durchgeführt werden.

18 Weitere Prüfmethoden Round Robin Review Ziel Nicht, Defekte zu finden Sondern, Argumente für die Güte des Prüflings zu sammeln Jeder Gutachter versucht, die anderen davon zu überzeugen, daß die Qualität des Prüfobjekts akzeptabel ist Kann ein Gutachter seine Kollegen nicht überzeugen, dann ist ein Problem identifiziert.

19 Weitere Prüfmethoden Peer Review Gutachter werden in einem Raum»eingeschlossen«Untersuchung eines oder mehrerer Prüfobjekte Das Review-Team bestimmt selbst die Aufgabenteilung und Vorgehensweise Ein Moderator leitet das Team und organisiert die Arbeit.

20 20 Inhalt 5 Produktqualität Komponenten 5.1 Einführung und Überblick 5.2 Klassifikation analytischer Verfahren Zur Auswahl geeigneter Testverfahren.

21 Einführung und Überblick Software-Produkt = Systemkomponenten + Beziehungen zwischen den Systemkomponenten Produktqualität eines Software-Produkts Produktqualität jeder Systemkomponente Produktqualität der Beziehungen zwischen den Systemkomponenten Aufgabe der Konstruktion Ausgehend von den gewünschten Qualitätsmerkmalen überlegen, welche konstruktiven Maßnahmen in der Entwicklung erforderlich sind.

22 Einführung und Überblick Q-Merkmale nach DIN ISO 9126 Analytische Maßnahmen beziehen sich auf die Qualität-Merkmale Funktionalität Zuverlässigkeit Änderbarkeit (einige wenige) Fehler Abweichung der tatsächlichen Ausprägung eines Qualitätsmerkmals von der Soll-Ausprägung Inkonsistenz zwischen Spezifikation und Implementierung Strukturelle Merkmale des Programmtextes, die ein fehlerhaftes Verhalten des Programms verursachen.

23 Einführung und Überblick Begriffe Prüfling, Testling, Testobjekt Die Software-Komponente bzw. das Programm, das getestet werden soll Prüfling ist dabei der allgemeine Begriff Testling impliziert die dynamische Ausführung eines Programms impliziert Testfall Besteht aus einem Satz von Testdaten, der die vollständige Ausführung eines zu testenden Programms bewirkt.

24 Einführung und Überblick Testdatum Ist ein Eingabewert, der einen Eingabeparameter oder eine Eingabevariable des Testobjekts mit einem Datum im Rahmen eines Testfalls versorgt Testtreiber Testrahmen, der ein interaktives Aufrufen von Prozeduren und Funktionen ermöglicht Können durch Testrahmengeneratoren auch automatisch erzeugt werden Ruft der Testling selbst andere Prozeduren oder Funktionen auf, dann müssen diese beim Testen zur Verfügung stehen.

25 Einführung und Überblick Instrumentierung Zum Mitprotokollieren, welche Teile des Prüflings bei der Ausführung eines Testfalls durchlaufen wurden In den Quellcode des Testlings werden Zähler eingefügt Nach dem Testlauf werden die Zählerstände ausgewertet Überdeckungsgrad Maß für den Grad der Vollständigkeit eines Tests bezogen auf ein bestimmtes Testverfahren.

26 Klassifikation analytischer Verfahren 3 Klassen in Abhängigkeit von Zielsetzung: Testende Verfahren Dynamische Testverfahren Statische Testverfahren Verifizierende Verfahren Verifikation Symbolische Ausführung Analysierende Verfahren Analyse der Bindungsart Metriken Grafiken und Tabellen Anomalienanalyse.

27 27 III Software-QS - Manuelle Prüfmethoden Testende Verfahren Dynamische Testverfahren Strukturtest (White Box Test, Glass Box Test) 5.2 Klassifikation analytischer Verfahren Kontrollflußorientierter Test Anweisungsüberdeckungstest Zweigüberdeckungstest Pfadüberdeckungstest (vollständig, strukturiert, boundary interior) Bedingungsüberdeckungstest (einfach, minimal mehrfach, mehrfach) Datenflußorientierter Test Defs-Uses Verfahren Required K Tupels Test Datenkontext Überdeckung Funktionaler Test (Black Box Test) funktionale Äquivalenzklassenbildung Grenzwertanalyse Test spezieller Werte Zufallstest Test von Zustandsautomaten Ursache Wirkungs Analyse Disversifizierender Test Mutationen Test Pertubationen Test Back to Back Test Statische Testverfahren Manuelle Prüfmethoden (Inspektion, Reviews, Walkthroughs, Schreibtischtest) (siehe Hauptkapitel 3) Statische Analysatoren Verifizierende Verfahren Verifikation Symbolische Ausführung Analysierende Verfahren Analyse der Bindungsart Metriken Grafiken und Tabellen Anomalieanalyse

28 Klassifikation analytischer Verfahren Ziele Testende Verfahren Fehler erkennen Verifizierende Verfahren Korrektheit einer Systemkomponente beweisen Analysierende Verfahren Vermessen und/oder stellen bestimmte Eigenschaften von Systemkomponenten dar.

29 Klassifikation analytischer Verfahren Merkmale dynamischer Tests Übersetztes, ausführbares Programm wird mit konkreten Eingabewerten versehen und ausgeführt Test in der realen Umgebung Stichprobenverfahren Korrektheit des getesteten Programms wird nicht bewiesen Herkunft der Testfälle Aus dem Kontroll- oder Datenfluß Dynamischer Strukturtest bzw. White Box-Test Spezifikation der Systemkomponenten Funktionstest, funktionaler Test bzw. Black-Box-Test Vergl. der Ergebnisse von Programmversionen Disversifizierende Tests.

30 Klassifikation analytischer Verfahren Statischer Test Systemkomponente wird nicht ausgeführt Quellcode wird analysiert, um Fehler zu finden Häufig verwendet: Manuelle Prüfmethoden Beispiele: Inspektionen, Reviews und Walkthroughs Verifikation Zeigt mit mathematischen Mitteln die Konsistenz zwischen der Spezifikation und der Implementation Symbolische Ausführung Quellprogramm wird mit allgemeinen symbolischen Eingabewerten durch einen Interpreter ausgeführt.

31 31 Inhalt 6.5 Der Systemtest 6.6 Der Abnahmetest 6.7 Das Produktzertifikat 6.8 Testprozeß und -dokumentation.

32 Der Systemtest Systemtest Abschließender Test der Software-Entwickler und Qualitätssicherer in der realen Umgebung Systemsoftware, Hardware, Bedienungsumfeld, technische Anlage Ohne den Auftraggeber Eventuell auf die Zielumgebung portieren Nur das»äußere«des Systems sichtbar D.h. die Benutzungsoberfläche und andere externe Schnittstellen des Systems z.b. hin zu technischen Prozessen.

33 Der Systemtest Basis für den Systemtest Produktdefinition Pflichtenheft, Produkt-Modell (z.b. OOA-Modell), Konzept der Benutzungsoberfläche und Benutzerhandbuch Im Pflichtenheft sollten sowohl die Qualitätsziele für das Produkt als auch Testszenarien und Testfälle festgelegt sein Auf der Grundlage dieser Vorgaben und Unterlagen werden Testfälle übernommen, ergänzt und/oder neu erstellt.

34 34 Prüfziele eines Systemtests Vollständigkeit Es ist zu überprüfen, ob das System alle funktionalen und nicht funktionalen Anforderungen aus dem Pflichtenheft erfüllt Die funktionalen Anforderungen werden durch einen Funktionstest überprüft Volumen Das System ist mit umfangreichen Datenmengen zu testen (Massentest) Die Größe von Dateien oder Datenbanken kann eine potentielle Schwachstelle sein.

35 35 Prüfziele eines Systemtests Zeit Bei starker Systembelastung ist zu prüfen, ob die geforderten Antwortzeiten und Durchsatzraten eingehalten werden (Zeittest) Zuverlässigkeit Das System ist über längere Zeit hinweg unter Spitzenbelastungen, die allerdings im geforderten Bereich liegen, zu testen (Lasttest) Der Betrieb erfolgt sozusagen im»grünen«bereich.

36 36 Prüfziele eines Systemtests Fehlertoleranz, Robustheit Das System wird unter Überlast, d.h. im»roten«bereich (Streßtest) getestet Beispielsweise wird ein Plattenausfall simuliert oder der Arbeitsspeicher wird reduziert Benutzbarkeit Es wird die Verständlichkeit, Erlernbarkeit und Bedienbarkeit aus der Sicht des Endbenutzers getestet (Benutzbarkeitstest, usability test) Zu prüfen ist, ob das System von der spezifizierten Benutzergruppe bedient werden kann, ob die richtige Fachterminologie verwendet wird, ob die gewählten Metaphern stimmen usw.

37 37 Prüfziele eines Systemtests Sicherheit Datenschutzmechanismen wie Paßwörter und Datensicherheitsüberprüfungen durch das System bzw. durch die umgebende Organisation sind zu überprüfen (Sicherheitstest) Interoperabilität Muß das System entsprechend den Anforderungen mit anderen Systemen zusammenarbeiten, dann muß die Zusammenarbeit einschließlich der Kompatibilität der Schnittstellen und der Daten geprüft werden (Interoperabilitätstest).

38 38 Prüfziele eines Systemtests Konfiguration Ist das System für unterschiedliche Hardware /Software Plattformen und Konfigurationen geeignet, dann sind die verschiedenen Möglichkeiten zu überprüfen (Konfigurationstest) Dokumentation Vorhandensein, Güte und Angemessenheit der Benutzer- und Wartungsdokumentation ist zu prüfen (Dokumentenprüfung).

39 Der Systemtest Der Funktionstest Sind alle in der Produktdefinition geforderten Funktionen vorhanden und korrekt? Aus dem Pflichtenheft werden die Testsequenzen übernommen und/oder mit funktionalen Testverfahren systematisch und vollständig hergeleitet Liegt ein Produktmodell (z.b. OOA-Modell) vor Dann können die externen Operationen, d.h. die Operationen, die aus Benutzersicht aufrufbar sind, entnommen werden Ist bereits das Konzept der Benutzungsoberfläche erstellt worden, dann können auch daraus die möglichen Funktionen für den Funktionstest ermittelt werden.

40 Der Systemtest Leistungstest Dient der Überprüfung des in der Produktdefinition festgelegten Leistungsverhaltens Massentest Zeittest Lasttest Streßtest Massentest Prüfung der verarbeitbaren Datenmengen Zeittest Einhaltung von Zeitrestriktionen.

41 Der Systemtest Lasttest Das System im erlaubten Grenzbereich auf Zuverlässigkeit testen Das Normalverhalten ist auch für folgende Situationen zu prüfen: Ausfall von Hardware- und Softwarekomponenten, mit denen das System kommuniziert Beispiel: ausgefallene Sensoren, Nichtverfügbarkeit eines benötigten anderen Softwaresystems Mehrbenutzerbetrieb mit der maximal geforderten, gleichzeitigen Benutzeranzahl Eintreffen ungewöhnlicher oder widersprüchlicher Daten, z.b. über Importschnittstellen.

42 Der Systemtest Streßtest Die definierten Grenzen des Systems werden bewußt überschritten Folgende Fragen sind zu prüfen: Wie ist das Leistungsverhalten bei Überlast? Geht das System nach Rückgang der Überlast wieder in den Normalbereich zurück? Beispiel Überlast bei der Seminarorganisation Volumen wird beträchtlich überschritten Beispiel: Teilnehmer, Seminare Wie ändert sich das Antwortzeitverhalten? Kann mit dem System überhaupt noch gearbeitet werden?

43 Der Systemtest Der Benutzbarkeitstest (usability test) Entscheidet heute oft über die Akzeptanz durch den Endbenutzer Wie aufwendig die Überprüfung der Benutzbarkeit ist, hängt von den Vorarbeiten in der Produktdefinition ab Sind im Pflichtenheft die Anforderungen an die Benutzungsschnittstelle aufgeführt, dann sind diese Anforderungen am fertigen System zu überprüfen Enthält die Produktdefinition bereits das Konzept der Benutzungsoberfläche, dann muß nur auf Übereinstimmung mit dem fertigen System geprüft werden.

44 Der Systemtest Der Sicherheitstest Geforderte Sicherheitsmaßnahmen sind zu überprüfen Beispiele Sind die Paßwörter verschlüsselt gespeichert? Werden die eingestellten Zugriffsrechte und -verbote überprüft und gemeldet? Werden die Paßwörter unsichtbar erfaßt? Ist eine Mindestlänge der Paßwörter vorgeschrieben? Kann der Benutzer sein Paßwort selbst ändern?

45 Der Systemtest Der Interoperabilitätstest Heutige Software-Systeme sind in der Regel keine»stand alone«-systeme Diese Zusammenarbeit muß beim Systemtest überprüft werden Alle benötigten Systeme werden ebenfalls in der realen Umgebung installiert Mit Testfällen wird der Datenaustausch und die Zusammenarbeit getestet Wird das Software-System in einer Standardumgebung eingesetzt, dann sind auch Standardmechanismen wie die Datenübergabe über die Zwischenablage zu überprüfen.

46 Der Systemtest Installationstest Kann das System mit den Installationsbeschreibungen, z.b. im Benutzerhandbuch, installiert und in Betrieb genommen werden? Wiederinbetriebnahmetest Kann nach einer Unterbrechung oder einem Zusammenbruch des Basissystems das System mit den vorliegenden Beschreibungen wieder in Betrieb genommen werden? Sind noch alle Daten verfügbar?

47 Der Systemtest Regressionstest Bei allen aufgeführten Testverfahren ist darauf zu achten, daß Regressionstests durchgeführt werden können Die ausgeführten Testfälle werden gespeichert und können nach Fehlerkorrekturen wiederholt werden.

48 Der Abnahmetest Abnahmetest (acceptance test) Eine besondere Ausprägung des Systemtests Unter Beobachtung, Mitwirkung oder Federführung des Auftraggebers In der realen Einsatzumgebung beim Auftraggeber Unter Umständen mit echten Daten des Auftraggebers Das System wird gegen die Produktdefinition geprüft Auftraggeber kann Testfälle des Systemtests übernehmen und/oder modifizieren und/oder eigene Testszenarien durchführen In der Regel Test unter normalen Betriebsbedingungen.

49 Der Abnahmetest Empfehlungen für den Auftraggeber Das zu prüfende System muß unter Konfigurationskontrolle stehen Der 1. Testschritt besteht aus dem Erzeugen des zu testenden Systems aus den Quellprogrammen unter Konfigurationsverwaltung War das System schon generiert, dann beginnt der Test mit dem Löschen aller Objektdateien Von dem neu generierten System wird die Prüfsumme berechnet und eine Kopie extern gesichert Am Schluß der Abnahme kann überprüft werden, ob immer noch das gleiche System getestet wird wie zu Beginn der Abnahme.

50 Der Abnahmetest Die Abnahme wird nach der vereinbarten Testvorschrift durchgeführt Das Benutzerhandbuch wird in die Tests einbezogen Zumindest alle dort enthaltenen Beispiele müssen ausgeführt werden Am Ende jedes Testabschnitts oder Tages: Die gefundenen Probleme in einem Protokoll festhalten Freies Testen durchführen Diese Testfälle sind zu dokumentieren, um im Fehlerfall die Testfälle reproduzieren zu können.

51 Der Abnahmetest Abnahme endet mit einer Schlußsitzung, in der die Fehler in den Protokollen gewichtet werden Sind die Fehler tolerierbar oder können sie nachgebessert werden, dann erfolgt die Abnahme des Systems durch den Auftraggeber Größere Systeme Werkabnahme Erfolgt in einer speziell für diesen Test bereitgestellten Testumgebung Alle Testfälle, die für die Abnahme vorgesehen sind, werden ausgeführt Aufwand für Testumgebung nur gerechtfertigt... wenn das System weit entfernt installiert werden muß wenn Fehler den Betriebsablauf stark stören.

52 Der Abnahmetest Abnahme Eine Abnahme in der realen Umgebung ist unverzichtbar Notfalls müssen geeignete Vorkehrungen getroffen werden, damit der laufende Betrieb möglichst wenig gestört wird Es werden auch die Tests durchgeführt, auf die bei der Werkabnahme wegen zu großer Kosten für die Simulation der realen Umgebung verzichtet wurde In der Regel wird die Dauer des Lasttests gegenüber der Werkabnahme wesentlich erhöht.

53 Der Abnahmetest Betriebsabnahme Nach der Abnahme geht man in den Versuchsbetrieb über und befindet sich damit in der Garantiephase Vor der endgültigen Inbetriebnahme wird auf die Wiederholung von Tests häufig verzichtet, wenn alle gemeldeten Fehler behoben sind.

54 Der Abnahmetest Systeme für den anonymen Markt Nur einen internen Auftraggeber z.b. die Marketingabteilung oder den Produktmanager In einem solchen Fall nimmt der interne Auftraggeber das Produkt ab Da die Prüfziele Fehlertoleranz, Benutzbarkeit, Konfiguration und Interoperabilität wegen der Einsatzbereiche eine größere Bedeutung besitzen, werden diese Systeme in der Regel einem Alpha- und/oder Beta-Test unterzogen.

55 Der Abnahmetest Alpha-Test Das System wird in der Zielumgebung des Herstellers durch Anwender erprobt Beta-Test Das System wird bei ausgewählten»pilot«-kunden in deren eigener Umgebung zur Probenutzung zur Verfügung gestellt Auftretende Probleme und Fehler werden protokolliert Sind größere Änderungen durchzuführen, dann kann nach den Regressionstests der Beta-Test bei Bedarf (Beta2-Test) wiederholt werden Die Pilotkunden erhalten beim späteren Kauf des Produkts in der Regel einen Preisnachlaß.

56 Der Abnahmetest Restfehler Auch nach erfolgreichem Abnahmetest befinden sich im System noch Fehler, sowohl bekannte als auch unbekannte Die Abnahme durch den Auftraggeber stellt immer einen Kompromiß zwischen... optimalen Ergebnis hier: fehlerfreies Produkt akzeptablen Ergebnis hier: Produkt mit tolerierbaren Fehlern.

57 Das Produktzertifikat Produktqualität Ergebnis der Prozeßqualität Prozeßqualität kann durch Prozeß- und Systemzertifikate nachgewiesen werden Beispiel: ISO 9000-Systemzertifikat Für den Endkunden ist ein Produktzertifikat, das bestimmte Qualitätseigenschaften garantiert, nützlicher und aussagekräftiger Für den Hersteller ist es ebenfalls wünschenswert, durch ein Produktzertifikat dem Kunden zu zeigen, daß bestimmte Q-Eigenschaften eingehalten sind DIN ISO/IEC RAL-Gütezeichen Software

58 Testprozeß und -dokumentation Testprozeß: Testplanung Dokumentation: Testplan und Testvorschrift Testdurchführung Dokumentation: Testbericht Testkontrolle Testplan Voraussetzungen für die Steuerung und Kontrolle der Testvorbereitung und Testdurchführung Teil des Projektplans und enthält die zeitliche und personelle Einplanung der Testaktivitäten.

59 Testprozeß und -dokumentation Testvorschrift Das Dokument, in dem die ausgewählten Testfälle festgehalten sind Legt fest, wie die Tests durchzuführen sind Die Arbeiten zur Vorbereitung der Testumgebung Die Ausführung der Testfälle in der gewählten Reihenfolge.

60 Testprozeß und -dokumentation Testbericht Der Testbericht besteht aus... der Testzusammenfassung dem Testprotokoll der Liste der Problemmeldungen der Liste der Software-Einheiten.