11. Test, Einführung, Qualitätsmanagement Softwaretechnik (CNAM)

Transkript

1 11. Test, Einführung, Qualitätsmanagement Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

2 Einordnung in den gesamten Kurs 1. Einführung 2. Vorgehensmodelle 3. Analyse: Anwendungsfälle 4. Analyse: Datenmodell 5. Analyse: Dialoge 6. Design: Architektur-Grundlagen 7. Design: Referenzarchitektur betriebliche Informationssysteme 8. Design: Querschnittsthemen und Muster 9. Programmierung, Konfigurationsmanagement 10.Test, Einführung, Qualitätsmanagement 11. Projektmanagement 2 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

3 Agenda Motivation Test Einführung Qualitätsmanagement Kontrollfragen

4 What happened to Ariane 5? The Ariane 5 launch vehicle failed on its maiden flight in June About 40 seconds after liftoff, a software bug in the flight controller made the rocket veer off course, leading to its destruction via ground command. Ariane 5 reused software from Ariane 4 without proper testing. Contributing to the mishap, run-time range checking had been turned off because of processor limitations. Also, the backup channel had failed milliseconds earlier because of the same coding defect. (Photo courtesy of European Space Agency; Ada code from 4 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

5 Fehlerbehebungskosten Quelle: van Megen: Dagstuhl-Seminar 02361(Sept. 2002) Supporting Customer-Supplier Relationships. Requirements Engineering and Quality Assurance SQS-Zahlen aus IT-Projekten > Req. Spec. Impl. Accept. Roll out Feldeinsatz 5 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

6 Agenda Motivation Test Test Einführung Qualitätsmanagement Kontrollfragen

7 Warum wird so wenig getestet? Den Wert des Testens begreift man erst mit Erfahrung (aus Schaden wird man klug) Gründe nicht zu testen: Kann auch später gemacht werden Das bezahlt keiner Keine Zeit Keine Leute Testen ist kein Selbstzweck, sondern muss sorgfältig abgewogen werden: Testkosten versus Risiko Kosten für das Testen Risiko = Wahrscheinlichkeit * Schaden 7 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

8 Edsger W. Dijkstra ( )»Program testing can be used to show the presence of bugs but never to show their absence!«dijkstra (1972) Die Korrektheit eines Programms kann i. A. nicht bewiesen werden. Das Vertrauen in ein Programm hängt ab von der Auswahl repräsentativer Testfälle, von der Überprüfung von Grenzwerten, von Testfällen mit guter Überdeckung und vielen anderen Randbedingungen ab, aber es gibt keine Gewissheit. 8 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

9 Anzahl Fehler als Qualitätsmaß? Die Anzahl der gefundenen Fehler ist kein Maß für die Qualität der Software Low Many Faults Software Quality High Few Faults You think you are here High Few Faults Test Quality Few Faults You may be here Low Quelle: D. Graham, M. Fewster: Testing Essentials - Testing Principles. TEST Congress, London, Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

10 Testprozess: Bewusste Trennung der Testphasen Testanalyse: Testbasis prüfen Testobjekte identifizieren Teststrategie festlegen Beginn Planung und Analyse Testdesign Testideen skizzieren Testideen priorisieren Review der Testideen auf Vollständigkeit Testrealisierung Zuordnung der Testideen zu Teststufen Testfälle beschreiben und ggf. automatisieren Testdaten erstellen Testumgebungen aufbauen abgeleitet aus Spillner, A., Linz, T.: Basiswissen Softwaretest - Aus- und Weiterbildung zum Certified Tester dpunkt, 3. Auflage, 2005 (Kapitel 2.2) 10 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/ Design Realisierung Durchführung Auswertung und Bericht Abschluss Ende Steuerung

11 Testspezifikationen sind Voraussetzung Anforderungsanalyse Design / Implementierung Integration/ / Abnahmetest Präsentation Nachbar- Batch system- schnittstellen Dialog Quer- Anwendungskern schnitts- funktionen DB-Zugriff IT-Konzept/Code Installiertes System Spezifikation Testspezifikation und Abnahmekritierien Vergleich 11 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

12 Testfälle erstellen: Aus Anwendungsfällen (Use Cases) ableiten; Destruktiv testen! sd Anmelden uc Kundenverwaltung Fitnesscenter anmelden Sachbearbeiter legekundenan gibkundendatenan Fitness Center::Kunde Kunde abmelden Kundenbetreuer legevertragan gibvertragsdetailsan Fitness Center::Vertrag schliessevertragab einchecken druckevertrag auschecken erstellerechnung Fitness Center::Rechnung Testfälle Vertragsdetails Vertrag zu Neukunden, Vertrag zu Bestandskunden, Vertrag mit nicht existierendem Kunden ( Fehler) Alle Vertragsarten, falsche Vertragsart ( Fehler) Unmögliches Datum ( Fehler) 12 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

13 Was muss getestet werden? gemäß FURPS-Modell (nach ISO/IEC 9126): Functonality (Funktionalität) Usability (Benutzbarkeit) Reliability (Zuverlässigkeit) Performance (Leistung) Supportability (Wartbarkeit) 13 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

14 Zustandsmodell für Fehler Initial gemeldet (offen) melden (Tester) klassifizieren (Test Manager) klassifiziert Entwickler zuweisen (Projektleiter) zugewiesen beheben (Entwickler) behoben nachtesten (Tester) [nicht behoben] [behoben] nachtestet (geschlossen) 14 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

15 Kriterien für Fehlerklassifikation kritisch kompletter Ausfall der Produktion bzw. Aufgabe nicht erfüllbar hoch deutliche Beeinträchtigung der Produktion, Leistung herabgesetzt mittel Verhinderung der vollen Ausnutzung von Programmfähigkeit, aber mit Kompensationsmöglichkeiten niedrig geringe oder "kosmetische" Probleme, Leistung bleibt erhalten unproblematisch nicht notwenige Softwareverbesserung 15 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

16 Aktives Testmanagement: Verfolgung der Fehlersuche und -behebung #Fehler (1) Gemeldet und klassifiziert Einführungsentscheidung (2) behoben (3) nachgetestet 16 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/ t

17 Teststufen: Wer testet was wann? Teststufen Systembestandteile Tester Modultest Modul-1 Modul-2 Modul-3 Entwickler Integrationstest Systemtest Abnahmetest Subsystem Subsystem Subsystem Subsystem Subsystem Subsystem Gesamtsystem Gesamtsystem + Nachbarn: test Gesamtsystem + Nachbarn: live IT-Team und Fachbereich Auftraggeber 17 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

19 Einführung: Woran ist alles zu denken? Sind die wichtigsten Tests fehlerfrei gelaufen (keine einführungsverhindernden Fehler mehr)? Ist die Produktionsumgebung technisch bereit? Sind alle notwendigen Daten vom alten in das neue System migriert? Sind die Anwender geschult? Sind weitere organisatorische Maßnahmen im Fachbereich getroffen, zum Beispiel temporäre Aushilfen? Ist die Betriebsmannschaft mit dem neuen System vertraut? Gibt das Management das OK zur Einführung? Dann kann s losgehen! 19 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

21 Die Aufgaben des Qualitätsbeauftragten Qualitäts/ ziele Ziele erfragen, festlegen und abstimmen QM-Maßnahmen planen, und kontrollieren Qualitätsanalyse Qualitätsmanagement Qualitätsplanung Durch Prozesse, Ausbildung, Werkzeuge, Checklisten, Vorlagen etc. Qualität konstruktiv sicherstellen Durch Dokument- / Codereviews, Tests Qualität analytisch prüfen Qualitätslenkung Qualitätsprüfung Kommunizieren 21 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

22 Qualitätsmanagement ist ein permanenter Prozess (nach ISO 9000:2000) Ständige Verbesserung des Qualitätsmanagementsystems Kunden (und andere interessierte Parteien) Management von Ressourcen Verantwortung der Leitung Messung, Analyse und Verbesserung Kunden (und andere interessierte Parteien) Zufriedenheit Anforderungen Eingabe Produktrealisierung Produkt Ergebnis Wertschöpfung Information 22 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

23 Effektives QM erfordert eine Qualitätskultur Von der Qualitätskontrolle (Spezialisten) Separate QM- Abteilung Qualitätseinhaltung Produktorientiertes QM Endkontrolle Erweiterter Qualitätsbegriff Qualitätskontrolleure Fehlerentdeckungsstrategie QM-Bürokratie Eingeplante Qualitätsspezifikation Nacharbeit Prozessorientierung Kundenorientierung Mitarbeiterorientierung Integrierte QM-Sicherung Prozess- Orientiertes QM Kontinuierliche Qualitätsverbesserung Prozessbegleitende Führungen Selbstcontrolling Fehler- Verhütungsstrategie Null- Fehler- Produktion Jeder Mitarbeiter ist ein Qualitätsmitarbeiter Bis zum umfassenden Qualitätsmanagement 23 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/

25 Kontrollfragen Warum ist Testen wichtig? Wie viel Testaufwand ist sinnvoll? Wie findet man Testfälle? Welche Teststufen werden unterschieden? Wer testet dabei was? Auf welcher Basis wird die Entscheidung zur Einführung gefällt? Worauf ist bei der Einführung zu achten? Qualitätsmanagement: Wie erreicht man eine permanente Qualitätsverbesserung im Unternehmen? 25 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 09/