Software Testen 2.0 VL



Ähnliche Dokumente
SPI-Seminar : Interview mit einem Softwaremanager

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

CMMI und SPICE im Automotive Umfeld

Einführung von Test-Prozessen laut TMMi. Egon Valentini 1. März 2010

1.1 Basiswissen komprimiert Praxiswissen Testmanagement Übersicht Testprozess und Testwerkzeuge 11

Quality Assurance Review der IT-Revision (QAR-IT) -Ein Leitfaden -

.. für Ihre Business-Lösung

Praxiswissen Softwaretest - Testmanagement

Basiswissen Softwaretest

1.1 Basiswissen komprimiert Praxiswissen Testmanagement Übersicht Fundamentaler Testprozess 11

Strategisches IT-Management mit dem COBIT Framework. Markus Gronerad, Scheer Management

Was beinhaltet ein Qualitätsmanagementsystem (QM- System)?

Mitarbeiter, Kunden und Partner im Fokus der Qualitätssicherung logistischer Kooperationen

Studie über Umfassendes Qualitätsmanagement ( TQM ) und Verbindung zum EFQM Excellence Modell

TMap NEXT Test Manager

Informationssicherheit als Outsourcing Kandidat

«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»

Softwaretechnik. Fomuso Ekellem WS 2011/12

Seminar- & Zertifizierungsprogramm 2010

ISO 9001 und CMM im Vergleich

GPP Projekte gemeinsam zum Erfolg führen

Erläuterungen zur Untervergabe von Instandhaltungsfunktionen

Medizintechnik und Informationstechnologie im Krankenhaus. Dr. Andreas Zimolong

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Leseprobe. Thomas Konert, Achim Schmidt. Design for Six Sigma umsetzen ISBN: Weitere Informationen oder Bestellungen unter

Qualitätsmanagement in kleinen und mittleren Unternehmen

The big picture: Prince2 featuring SCRUM. Bernd Lehmann, Prince2-Tag Köln, 12. Mai 2011

Lösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung

Erfolgreiche ITIL Assessments mit CMMI bei führender internationaler Bank

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante

Software Qualität: Übung 3

Änderung der ISO/IEC Anpassung an ISO 9001: 2000

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

360 Feedback. Gestaltung von Entwicklungsprozessen

Information zur Revision der ISO Sehr geehrte Damen und Herren,

Systemen - Einleitung

Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung des Projektstatus.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

SDD System Design Document

ISO 9001:2015 REVISION. Die neue Struktur mit veränderten Schwerpunkten wurde am 23. September 2015 veröffentlicht und ist seit

Beschreibung des MAP-Tools

OUTSOURCING ADVISOR. Analyse von SW-Anwendungen und IT-Dienstleistungen auf ihre Global Sourcing Eignung. Bewertung von Dienstleistern und Standorten

Anforderungen an die HIS

GRS SIGNUM Product-Lifecycle-Management

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Regulatorische Anforderungen an die Entwicklung von Medizinprodukten

Softwarequalität. TÜV SÜD Product Service GmbH. Damit Ihre Softwareprodukte sicher ins Ziel kommen.

9.6 Korrekturmaßnahmen, Qualitätsverbesserung

Sicherheitsbewertungsbericht

Tag des Datenschutzes

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting Seite 1

Kapitel 6: Projekterfolg

Software Projekt 2 / Gruppe Knauth Lernziele:

Software-Validierung im Testsystem

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES

J O L A N T H E D L U G O K E C K I C A R O L I N K A N J A

CMMI Der Weg zur erfolgreichen Softwareorganisation CMMI & SPA (Siemens Process Assessment)

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Modul 5: Service Transition Teil 1

Prozess-Modelle für die Softwareentwicklung

Geyer & Weinig: Service Level Management in neuer Qualität.

Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist

Prozessoptimierung. und. Prozessmanagement

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

RICHTLINIE ZUR FESTLEGUNG DER AUDITDAUER UND DER VERGÜTUNG (ISO ISO 22000)

Änderungen ISO 27001: 2013

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw,

WSO de. <work-system-organisation im Internet> Allgemeine Information

5.3.2 Projektstrukturplan

Was sind Jahres- und Zielvereinbarungsgespräche?

Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik

Wie kann man Kreativität und Innovation fördern? Psychologische Ansätze zum Ideenmanagement

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Dieter Brunner ISO in der betrieblichen Praxis

Managementsysteme und Arbeitssicherheit

Delta Audit - Fragenkatalog ISO 9001:2014 DIS


SWE12 Übungen Software-Engineering

Outsourcing und Offshoring. Comelio und Offshoring/Outsourcing

SERVICE SUCHE ZUR UNTERSTÜTZUNG

Qualitätsmanagement. Grundlagen

RISIMA Consulting: Beratung, Planung, Produkte und Services für kleine und mittelständische Unternehmen.

Beispielfragen L4(3) Systemauditor nach AS/EN9100 (1st,2nd party)

Mehr Transparenz für optimalen Durchblick. Mit dem TÜV Rheinland Prüfzeichen.

Standard Inhaltsverzeichnis für Testvorschrift

Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement

Qualitätsmanagement nach ISO/TS 16949

Checkliste zur qualitativen Nutzenbewertung

Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement

Benötigen wir einen Certified Maintainer?

Test zur Bereitschaft für die Cloud

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten

Übungsbeispiele für die mündliche Prüfung

Die Betriebssicherheitsverordnung (BetrSichV) TRBS 1111 TRBS 2121 TRBS 1203

Fallbeispiel. Auswahl und Evaluierung eines Software- Lokalisierungstools. Tekom Herbsttagung 2004 Angelika Zerfaß

Transkript:

Software Testen 2.0 VL Software Testen VO4 2009W http://www.inso.tuwien.ac.at/lectures/software_testen INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien

Folie: 2 Lernziele Testdokumentation Testaufwandsschätzung Testprozessverbesserung Testunterstützungswerkzeuge

Folie: 3 Testpolitik Definition: Die Testpolitik ist ein Dokument, welches auf einem hohen Abstraktionsniveau die Prinzipien, Vorgehensweisen und wichtigsten Ziele einer Organisation in Bezug auf das Testen zusammenfasst Darstellen des Testprozesses Evaluieren des Testens Zu erreichende Qualitätsniveaus Verfahrensansatz zur Testprozessverbesserung

Testhandbuch Basis zur Ableitung eines Testplanes in den Projekten Beschreibung der durchzuführenden Teststufen und auszuführenden Testaktivitäten Zwei Hauptbereiche werden unterschieden: die Beschreibung der Risiken, die durch das Testen abgedeckt werden sollen, die Beschreibung der Testaktivitäten, die durchgeführt werden sollen, um die identifizierten Risiken abzudecken 4

Testhandbuch II Für jede Teststufe werden folgende Aspekte beschrieben Eingangs- und Ausgangskriterien Testansatz Testendekriterien Grad der Unabhängigkeit des Testens Einzuhaltende Standards Umgebungen, in der Softwaretests durchgeführt werden Anzuwendende Testspezifikationstechniken (Testfallentwurfsmethoden) Ansatz zur Testautomation Grad der Testautomation 5

Testplan Das Dokument Testplan enthält die konkrete Umsetzung des Testhandbuches auf die Projektsituation Es ist erweitert um die generelle Zeit- und Ressourcenplanung des Projektes. Legt die Prozesse innerhalb des Testvorgehens fest Testfallerstellungsprozess Übergabe von Entwicklung an Test Behandlung von Abweichungen, Change Request Herstellen der Testumgebungen Grundlage für die Abstimmung mit anderen am Projekt Beteiligten. Konkretisiert die Projektrisiken und erforderliche Gegenmaßnahmen. 6

Teststufenplan Er beschreibt die Implementierung des Testplans für eine bestimmte Teststufe, ist also eine Verfeinerung des Testplans Der Teststufenplan enthält: eine Abfolge der Testaktivitäten einen taggenauen Plan der Aktivitäten verknüpfte Meilensteine 7

Folie: 8 Lernziele Testdokumentation Testaufwandsschätzung Testprozessverbesserung Testunterstützungswerkzeuge

Testplanung und Testkontrolle: Testaufwandschätzung Aktivitäten pro Testobjekt Testspezifikation Testfallermittlung Testdatendefinition und -erstellung Testprozedurerstellung Testausführung und -aufzeichnung Testendebewertung Aktivitäten pro Teststufe z.b. Aufbau der Testumgebung Teststufenübergreifende Aktivitäten z.b. Testmanagement / Testplanung 9

Schätzmethoden Intuition, Raten, Erfahrung, vergleichbare Testprojekte Voraussetzungen Befragte sind Experten. Es existiert eine Projektdefinition (Grobkonzept vorhanden). Erfahrungen / Analogiematerialien liegen vor Anwendung Schätzungen im Vorprojektstadium Cross-Checks der Größenordnung Risikoarme Projekte Probleme / Herausforderungen Subjektivität Keine definierte Genauigkeit 10

Schätzmethoden II Hochrechnung aus vorhergehenden Testdurchlaufen Detaillierte Aufschlüsselung für alle Testaktivitäten Formelbasiert Function Point Methode COCOMO (Constructive Cost Model) Metriken LOC (Lines of Code) Komponentenmethode Bewertung und Gewichtung der Qualitätsmerkmale, Risiko und Komplexität 11

Schätzmethoden III In der Praxis oft Verwendung mehrere verschiedener Verfahren Beispiel Erstschätzung: Testobjekte bestimmen Risikoklasse zuordnen Komplexität zuordnen Gemeinsame Bewertung von Risiko und Komplexität Beispiel Aufwandsschätzung der einzelnen Teststufen anhand von Qualitätskriterien 12

Festlegen der Risikoklassenkategorien 13

Risikoklassen zuordnen 14

Komplexitätskriterien festlegen 15

Komplexität zuordnen 16

Gemeinsame Bewertung von Risiko und Komplexität 17

Qualitatsmerkmale (ISO 9126, DIN 66272) 18

Schätzung Testaufwand: Gewichtung Beispiel: Robustheit: Für eine 7 Tage / 24-Stunden Anwendung muss die Verfugbarkeit stets gewährleistet sein, daher Gewichtung = hoch. Für eine laufend genutzte kommerzielle Anwendung, die wahrend der üblichen Geschäftszeiten verfugbar sein muss, ist die Gewichtung = mittel. Für eine Statistikauswertung anlässlich der Jahresabschlussarbeiten ist die Gewichtung = gering. 19

Festlegung der Teststufen 20

Festlegung der Teststufen 21

Folie: 22 Lernziele Testdokumentation Testaufwandsschätzung Testprozessverbesserung Testunterstützungswerkzeuge

Qualitätsmanagementstandards Qualitätsmanagement beinhaltet aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität Sollen die Entwicklung eines Unternehmens hin zu einem hohen Qualitätslevel und zu Kontinuität unterstützen Standards verbessern zudem das wechselseitige Verständnis und die Koordination unterschiedlicher Entwicklungsteams, speziell aber auch zwischen Entwicklung und Wartung Durch eine höhere Transparenz und Berechenbarkeit eines Qualitätssicherungssystems kann der Kunde von einem gewissen Qualitätsniveau ausgehen und bleibt so eher von unerwünschten Überraschungen verschont als bei intuitiver Vorgehensweise Grundsätzlich können Qualitätsmanagementstandards in Zertifizierungs- und Assessmentstandards (Bewertungsstandards) unterschieden werden

Überblick 24

CMM and CMMI CMM-Modell wurde in den 80er Jahren, auf Initiative des US- Verteidigungsministerium, vom SEI (Software Engineering Institute) entwickelt Ziel, die Vergleichbarkeit und Qualität von Softwareprozessen im Rahmen der Vergabe an externe Lieferanten zu verbessern Mit der Zeit jedoch verbreitete sich das Modell. 1993 wurden für diverse Entwicklungsdisziplinen weitere Modelle entwickelt, wie z.b. SE-CMM 2003 ein vereinheitlichter und modularer Nachfolger, das CMMI (Capability Maturity Model Integrated), entwickelt CMMI Liefert eine Analyse des Ist- Zustandes eines Unternehmens und ist kein international anerkanntes Zertifikat wie ISO 9000-3 Ein CMM-Assessment beurteilt die Fähigkeit einer Organisation, Software unter bestimmten Rahmenbedingungen erstellen zu können

CMMI Reifegradstufen

SPICE ISO/IEC 15504 SPICE (Software Process Improvement for Capability Determination) wurde Anfang der 90er Jahre als gemeinsame Initiative von ISO und IEC entwickelt Grundsätzlich sind SPICE und CMMI sehr ähnlich aufgebaut. Zielsetzungen und Forderungen dieser beiden Modelle überdecken sich zu ca. 80 90%. Somit kann SPICE als Konkurrent zum US-dominanten CMMI gesehen werden SPICE besteht, genauso wie CMMI, aus einem zweidimensionalen Referenzmodell. Zu diesem Referenzmodell gehören eine Prozessdimension und eine Fähigkeitsdimension zur Reifegradbestimmung der einzelnen Prozesse

SPICE ISO/IEC 15504 Prinzipien und Ziele Zusammenführung verschiedenster existierender Assessment- Methoden zu einem zusammenhängenden Systemmodell Universelle Einsetzbarkeit, um alle Kategorien von Softwareprojekten sowie deren Kunden und Zulieferer zu unterstützen Hohe Professionalität Erreichung hoher internationaler Akzeptanz als weltweiter Standard

SPICE ISO/IEC 15504 Reifegradstufen

SPICE ISO/IEC 15504 Erfüllungsgrade nicht erreicht (not achieved) 0 15 % teilweise erreicht (partially achieved) 16 50 % weitestgehend erreicht (largely achieved) 51 85 % vollständig erreicht (fully achieved) 86 100 %

Testprozessverbesserung Standardisierung bringt Sicherheit in der Bewertung und Vergleichbarkeit der Ergebnisse Aber der Testprozess spielt in den Modellen heute nur eine untergeordnete Rolle Die Modelle TMM (Testing Maturity Model) und TPI (Test Process Improvement) versuchen diese Lücke zu füllen. 31

Test Maturity Model - TMM Berücksichtigt die besonderen Aspekte des Testens. Inspiriert durch CMM und SPICE. Entwickelt und registriert durch das Illinois Institute of Technology (IIT) Basiert auf dem Modell von Gelperin und Hetzel. 4 historische Perioden des Testens identifiziert: Debugging (Fehlerbehebung). Destruction (Fehlerfindung). Evaluation (Integration in den Software-Lebenszyklus). Fehler in den Anforderungen. Fehler im Design. Fehler in der Implementierung. Prevention (Optimierung). 32

Test Maturity Model TMM II Reifegradstufen 1. Initial 2. Phasendefinition 3. Integration 4. Steuerung, Messung und Kontrolle 5. Optimierung, Fehlervermeidung und Qualitätskontrolle Jeder Reifegrad hat Ziele Unterziele Aktivitäten, Aufgaben und Verantwortlichkeiten Bewertungsmodell mittels Assessement Im Assessement wird das erreichen der Ziele überprüft. 33

Test Maturity Model Phase Initial 1. Initial Charakteristika: Keine Trennung von Debugging und Test Ad Hoc Test nach Codierung Produkt-Freigaben ohne Test Keine Ressourcen verfügbar für Test Testziel: Software funktioniert 34

Test Maturity Model Phase Definition 2. Definition Charakteristika: Test und Debugging sind in verschiedene Phasen getrennt Test ist geplant Basistechniken und Methoden kommen zur Anwendung aber: Test zu spät keine Reviews Testziel Software entspricht der Spezifikation 35

Test Maturity Model Phase Integration 3. Integration Charakteristika: Steuerung und Überwachung des Testprozesses Testen ist im Software-Lebenszyklus integriert Technisches Ausbildungsprogramm existiert Testorganisation existiert Testziel Software entspricht den Anforderungen 36

Test Maturity Model Steuerung, Messung und Kontrolle 4. Steuerung, Messung und Kontrolle Charakteristika: Der Test ist ein gemessener und quantifizierter Prozess. Reviews in allen Entwicklungsphasen. Qualitätsmerkmale werden geprüft. Testziel Messen der Qualität 37

Test Maturity Model -. Optimierung, Fehlervermeidung und Qualitätskontrolle 5. Optimierung, Fehlervermeidung und Qualitätskontrolle Charakteristika: Testprozess ist optimiert Qualitätskontrolle Fehlerprävention Testziel Kontrolle der Qualität 38

Test Process Improvement - TPI Bewertungsmodell zur Bestimmung von Stärken und Schwächen im Bereich des Software-Testens TPI ist eine Entwicklungsmatrix bestehend aus 20 Kerngebieten, 4 Level und Kontrollpunkten für die Levelerreichung Die Entwicklung der einzelnen Kerngebiete lässt sich aus der Matrixablesen Die Weiterentwicklung der Testorganisation erfolgt nicht für alle Kerngebiete gleichzeitig 39

TIP Levels Level stellen qualitative Verbesserungen dar Die Anforderungen eines höheren Levels umfassen auch die Anforderungen der untergeordneten Level 40

Entwicklungsmatrix Liefert Übersicht, auf welchem Niveau sich der Testprozess befindet Wird von links nach rechts abgearbeitet, damit gering entwickelte Kerngebiete als erstes verbessert werden Die Weiterentwicklung erfolgt schrittweise, d.h. nicht für alle Kerngebiete zugleich 41

Entwicklungsmatrix II 42

Folie: 43 Lernziele Testdokumentation Testaufwandsschätzung Testprozessverbesserung Testunterstützungswerkzeuge

Testunterstützungswerkzeuge 44

Werkzeugauswahl Die Wahl des richtigen Werkzeuges ist sehr wichtig: es muss seine Funktion erfüllen und leicht bedienbar sein es stellt eine große Investition dar finanziell und bezogen auf die benötigten Ressourcen Unterschiedliche Anwender haben unterschiedliche Anforderungen Wenn es das falsche Werkzeug ist folgen gegenseitige Schuldzuweisungen, wird das Werkzeug wird nicht genutzt (Schrankware), verliert das Management das Vertrauen Daher ist die Implementierung eines Prozesses zur Bewertung und Auswahl des Werkzeuges notwendig 45

Aktivitäten des Bewertungs- und Auswahlprozesses 1. Problemumfeld identifizieren und quantifizieren 2. Betrachtung möglicher Alternativlösungen 3. Kosten- / Nutzenanalyse 4. Identifikation von Lizensierungsmodellen und alternativen 5. Identifikation von Kosten, die mit dem Besitz des Werkzeugs verbunden sind 6. Identifikation von Einschränkungen 7. Identifikation der gewünschten Funktionalität und Eigenschaften des Werkzeugs 8. Identifikation von Werkzeugen für die detaillierte Evaluierung 9. Durchführung der detaillierten Evaluierung 10.Bei Bedarf Durchführung eines parallelen Probelaufes von konkurrierenden Testwerkzeugen 46