Softwarequalität und -test

Ähnliche Dokumente
6 Produktqualität Systeme: System- und Abnahmetest [stark gekürzt; 6.4, 6.7, 6.8 ganz entfernt]

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt

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

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Software- Qualitätsmanagement

Qualitätssicherung von Software

Standard Inhaltsverzeichnis für Testvorschrift

Abnahmeprotokoll Modul 123: Serverdienste in Betrieb nehmen IET-GIBB Jessica Dominguez Stevanovic, 2G

Phasenmodell. Problem stellung. Neue Anforderungen. Benutzerwünsche. Anforderungs analyse und - definition Systemmodell. Betrieb.

Skript zur Vorlesung. Softwaretechnik. IT Kompaktkurs. Folge 14: Einführung, Test und Betrieb. Sommersemester 2001

Software-Engineering und Optimierungsanwendungen in der Thermodynamik

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Softwaretechnikpraktikum SS Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Qualitätsmanagement. Grundlagen

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung

Testdokument (Universität Paderborn, Softwaretechnikpraktikum SS2006)

Vorlesung am Test und Abnahme von IT-Leistungen

Testmanagement. Full-Service

Drahtlosnetzwerk AGS-Basel. Android Geräte. Version 1.2. Mittelschulen und Berufsbildung. Erziehungsdepartement des Kantons Basel-Stadt

Software Engineering Projekt. Pflichtenheft

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung

Programmiermethodik Vorlesung und Praktikum SS 2001

Software- Engineering

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]

Software Engineering

Testskripten Beispiele für System- und Akzeptanztests

Softwaretechnik (Allgemeine Informatik) Überblick

Die Abnahme von IT-Leistungen. Gastvortrag bei der Alpen-Adria Universität Klagenfurt RA Dr. Ralf Blaha LL.M.

Lösung zu Entwickeln und Bereitstellen von Anwendungssystemen - IT-Buchreihe Band 3. Seite 312

Qualitätssicherung von Software

Software- und Systementwicklung

ZERTIFIZIERUNG SCHNITTSTELLE VEZ 5.1 INFORMATIONEN ZUR ZERTIFIZIERUNG DER KASSENSCHNITTSTELLE MIT PROTOKOLL VEZ, VERSION 5.1

Wartungs- und Inspektions-Protokoll App mit Admin Tool. Funktionsbeschreibung

Testmanagement in IT-Projekten

Qualitätssicherungskonzept

Anforderungsanalyse. Basis: Grundlage für Erfolg / Misserfolg. Gute Qualität, moderne Techniken... Reicht nicht!

Requirements Engineering I

CAE Grundlagen. Prof. Metzler 1

Autoupdate Installation. HIW GmbH Berblinger Str. 1 D Ditzingen Werner-von-Siemens-Str. 23 D Cham.

2. Der Software-Entwicklungszyklus

Test und Abnahme bei IT-Projekten

Testkonzept. Tipp-Star

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

AGB zum Werkvertrag Fristen für die Übergabe der Teil-/Arbeitsergebnisse ergeben sich aus den Unterlagen zum Grundvertrag.

Programmieren I. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

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

Telekom SIP-Trunk-Anbindung via LANCOM-Router

Das V-Modell XT. Ein Standard für die Entwicklung von Systemen.

swp12-6 Aufgabenblatt Qualita tssicherungskonzept

Kaufvertrag / Mietvertrag / Leasingvertrag über die Lieferung von Hardware und Systemsoftware

Beschaffung zentraler Komponenten zum Betrieb der MACH-Software für sächsische Hochschulen

4.3 Planung (Auszug ISO 14001:2004+Korr 2009) Die Organisation muss (ein) Verfahren einführen, verwirklichen und aufrechterhalten,

Neue Fachmeinungen zum Thema Dokumentation

Bewertungssystem Nachhaltiges Bauen (BNB) Außenanlagen von Bundesliegenschaften

Software Engineering. 11. Einführung und Wartung

Aufgabe 3 Erstellt am: Softwaretechnik Praktikum SS06 Verantwortliche: Irina Justus

Testen von Software. Erfahrungsbericht des INGTES Testcenters. von Ueli Tribelhorn

G DATA TechPaper. Update auf Version 14.1 der G DATA Unternehmenslösungen

Anleitung Ausfüllen der Statistikmeldung

Softwareentwicklungspraktikum Sommersemester Testdokumentation

1GATEWAY MANAGEMENT. Copyright 28. April 2005 Funkwerk Enterprise Communications GmbH Bintec Benutzerhandbuch - XGeneration Version 1.

Gnädinger & Jörder Consulting Assuring Project Success

Checkliste ISO/IEC 27001:2013 Dokumente und Aufzeichnungen

Silk Central Connect Versionshinweise

Inhaltsverzeichnis. Teil I Handwerkszeug. 3 Begriffe zum Testen Definitionen zum Testen Box-Tests

( 87% ",# (-,- < 21,= 0 ><1( 87% ",# 3 8'#' 9:, # 21, = 0? "! ( 7-8?( 8- :#? "# - ;! " # ! "#!$% &' ()*++,-.#/, 0)*+*, -.%1,, 0)*+5+ "%.

Software Release Notes

edoc invoice Automatisierte Verarbeitung von Eingangsrechnungen per

Ändern des Root-Passworts Ihres RoomWizard Geräts mittels der RoomWizard Administrative Console (RWAC) 1.3

Natalie Kurz Juristisches IT-Projektmanagement Wintersemester 2015/2016

ARAkoll 2013 Dokumentation. Datum:

Benutzerhandbuch. Bürgel ConsumerCheck für OXID eshop

Dokumentation zu IBM Lotus Mashups

Prozessbeschreibung Inventur

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Dokumentation IBIS Master Version 1.5.6

Warum ist Ariane 5 beim Erstflug explodiert?

Projektmanagement. Vorlesung von Thomas Patzelt 10. Vorlesung

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit.

Was versteht man unter Softwaredokumentation?

1. Enhanced Technical Support (ETS) for Linux Power

1.4! Einführung. Systemmodellierung. Methoden und Werkzeuge

Software Engineering

Beschreibung der Verfahrensabläufe bei Prüfung und Abschluss von Belegungsverträgen

Matrix42. Use Case - Bestellung von Software über Service Catalog. Version Dezember

Testen in Content Management Projekten

STANDARD Systematische Qualitätssicherung

Abnahmeprotokoll für ET 200S FC Failsafe

Leistungsbeschreibung

Erstellung eines Pflichtenhefts (I)

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Upgrade Szenario SMC 2.5 auf SMC 2.6

Testen mit Fit und Fitnesse. Ludger Solbach

Test und Abnahme im Rahmen des juristischen Projektmanagements

Software zur Online-Aktualisierung der Firmware/Gerätesoftware eines Garmin GPS-Empfängers

Zentrale Archivierung am Domino-Server

T3 Testen im Software- Lebenszyklus

Robustheit von Baugruppen und Systemen

Neutral geprüft: Das IKT Institut für Unterirdische Infrastruktur führt regelmäßig Warentests und Produkt- Prüfungen durch.

Transkript:

7. Vorlesung www.beuth-hochschule.de Dipl.-Inform. Thomas Ziemer

Softwareabnahme Was versteht man unter einer Softwareabnahme? Unter Softwareabnahme versteht man die Übergabe des Softwaresystems an den Auftraggeber. Auftraggeber und Auftragnehmer prüfen gemeinsam das entstandene Softwaresystem gemäß der im Pflichtenheft spezifizierten Abnahmekriterien, bewerten die dabei auftretenden Fehler und entscheiden über den Erfolg oder Misserfolg der Abnahme. 2

Systemtest

Systemtest Der Systemtest ist der abschließende Test des gesamten Softwareprodukts durch die Softwareentwickler und Qualitätssicherer in der realen Umgebung (Hardware, Systemsoftware, Bedienungsumfeld, technische Anlage) jedoch ohne den Auftraggeber. Unterscheidet sich die Entwicklungsumgebung von der Einsatz- oder Zielumgebung, dann muss das System vor Beginn des Systemtests auf die Zielumgebung portiert werden. 4

Prüfziele des Systemtests Im folgenden sind die wichtigsten Prüfziele eines Systemtests zusammengestellt. 1. Funktionstest (correctness) Durch den Funktionstest wird überprüft, ob alle in der Produktdefinition geforderten Funktionen vorhanden sind und wie vorgesehen realisiert wurden. Wie können Funktionstests hergeleitet werden? - Testsequenzen aus dem Pflichtenheft - funktionale Testverfahren - externe Operationen aus dem Produktmodell (z.b. OOA-Modell) - Konzept der Benutzungsoberfläche (Prototyp) 5

Prüfziele des Systemtests (Fortsetzung) 2. Leistungstests Unter dem Oberbegriff Leistungstests werden verschiedene Tests zusammengefasst, die der Überprüfung des in der Produktdefinition festgelegten Leistungsverhaltens dienen: Massentest Beim Massentest (Test auf Volumen) wird die spezifizierte maximale Menge der ordnungsgemäß und zuverlässig verarbeitbaren Datenmengen überprüft. 6

Prüfziele des Systemtests (Fortsetzung) Zeittest Beim Zeittest wird die Einhaltung der im Pflichtenheft spezifizierten Zeitrestriktionen überprüft. Solche Zeitanforderungen (efficiency) können sich auf das Antwortzeitverhalten der Benutzungsoberfläche aber auch auf die zeitkritischen Teile eines Echtzeitsystems beziehen. 7

Prüfziele des Systemtests (Fortsetzung) Lasttest Der Lasttest (Test auf Zuverlässigkeit) hat das Ziel, das System im erlaubten Grenzbereich auf Zuverlässigkeit (reliability) zu testen. Zu diesem Test gehören auch: - Ausfall von Hardware- und Softwarekomponenten - Mehrbenutzerbetrieb mit der maximal geforderten, gleichzeitigen Benutzeranzahl - Eintreffen ungewöhnlicher oder widersprüchlicher Daten 8

Prüfziele des Systemtests (Fortsetzung) Stresstest Beim Stresstest (Test auf Fehlertoleranz und Robustheit) werden die definierten Grenzen des Systems bewusst überschritten, um folgende Fragen zu prüfen: - Wie ist das Leistungsverhalten bei Überlast? - Geht das System nach Rückgang der Überlast wieder in den Normalbereich zurück? 9

Prüfziele des Systemtests (Fortsetzung) 3. Benutzbarkeitstest (usability) Die Benutzbarkeit eines Softwaresystems entscheidet über die Akzeptanz durch den Endbenutzer! Wie aufwendig die Überprüfung der Benutzbarkeit ist, hängt von den Vorgaben in der Produktdefinition ab. Sind im Pflichtenheft die Anforderungen an die Benutzungsschnittstelle aufgeführt, dann sind diese Anforderungen am fertigen System zu überprüfen. 10

Prüfziele des Systemtests (Fortsetzung) 4. Sicherheitstest (security) Die geforderten Sicherheitsmaßnahmen sind zu überprüfen, beispielsweise: - Werden Kennwörter unsichtbar erfasst? - Werden Kennwörter verschlüsselt gespeichert? - Werden die eingestellten Zugriffsrechte berücksichtigt? - Werden Zugriffsverbote überprüft und gemeldet? 11

Prüfziele des Systemtests (Fortsetzung) 5. Interoperabilitätstest (integrity) Heutige Softwaresysteme sind in der Regel keine Stand alone-systeme, sondern arbeiten mit anderen Systemen zusammen. Diese Zusammenarbeit muss beim Systemtest überprüft werden. Das bedeutet, dass alle benötigten Systeme ebenfalls in der realen Umgebung installiert sind und mit Testfällen der Datenaustausch und die Zusammenarbeit getestet werden. 12

Prüfziele des Systemtests (Fortsetzung) Häufig enthält der Systemtest noch einen Installations- und Wiederinbetriebnahmetest. 6. Installationstest (deploy) Beim Installationstest wird geprüft, ob das System mit den Installationsbeschreibungen, die beispielsweise im Benutzerhandbuch dokumentiert sind, installiert und in Betrieb genommen werden kann. 7. Wiederinbetriebnahmetest (restore) Der Wiederinbetriebnahmetest prüft, ob nach einer Unterbrechung oder einem Zusammenbruch des Basissystems das System mit den vorliegenden Beschreibungen wieder in Betrieb genommen werden kann, und ob dann noch alle Daten verfügbar sind. 13

Abnahmephase

Abnahmephase In der Abnahme- und Einführungsphase wird das fertig gestellte Softwaregesamtprodukt einschließlich der gesamten Dokumentation dem Auftraggeber übergeben, von ihm abgenommen (Abnahmetest) und beim Anwender eingeführt, d.h. in Betrieb genommen. Ab diesem Zeitpunkt unterliegt es dann der Wartung und Pflege. Führt der Auftraggeber die Wartung und Pflege selbst durch, dann benötigt er auch die gesamte Analyse-, Entwurfs- und Implementierungsdokumentation sowie eine sorgfältige Einführung in die Softwarearchitektur. 15

Methodischer Aufbau und Durchführung von Fach- und Abnahmetest Abnahmetest Abnahmetests sind eigentlich keine Tests, denn bei der Abnahme hat in der Regel niemand mehr die Absicht, Fehler zu finden. Vielmehr versucht der Kunde, tatsächlich festzustellen, ob das Programm das Nötigste leistet, damit die Bezahlung erfolgen kann. Die Entwickler wollen anhand der Abnahme sogar beweisen, dass das Programm die Anforderungen erfüllt. Der Verwendungszweck widerspricht also völlig dem eines normalen Tests. Abnahmetests sind nicht ergebnisoffen, und sie haben schon gar nicht das Ziel, Fehler zu finden. 16

Abnahmetest Aus der Sicht des Auftraggebers ist es beim Abnahmetest nicht möglich, das Softwareprodukt vollständig zu testen. Daher ist es umso wichtiger, dass bei der Auftragsvergabe geprüft wird, ob beim Auftragnehmer die Softwareentwicklung nach einem definierten und gelebten Softwareprozess erstellt wird. 17

Abnahmetest (Fortsetzung) Der Abnahmetest (acceptance test) ist eine besondere Ausprägung des Systemtests, bei dem das System getestet wird: - unter Beobachtung, Mitwirkung oder Federführung des Auftraggebers - in der realen Einsatzumgebung beim Auftraggeber und - unter Umständen mit den echten Daten des Auftraggebers 18

Abnahmetest (Fortsetzung) In der Regel konzentriert sich der Auftraggeber auf den Test des Systems unter normalen Betriebsbedingungen. Die Testfälle weisen meist folgende Charakteristika auf: - Abnahmekriterien aus der Produktdefinition - Teilmengen der Testfälle aus dem Systemtest - Testfälle für die Verarbeitung der Geschäftsvorgänge einer typischen Zeitperiode (z.b. Tag, Monat, Jahr) oder Abrechnungsperiode (z.b. Geschäftsjahr) - Testfälle für Dauertests mit dem Ziel, einen permanenten Betrieb über eine größere Zeitspanne zu prüfen - Freies Testen 19

Abnahmetest (Fortsetzung) Folgenden Punkten sollte aus Sicht des Auftraggebers besondere Aufmerksamkeit geschenkt werden: - Der erste Testschritt besteht aus dem Erzeugen des zu testenden Systems aus den Quellprogrammen. War das System zuvor schon generiert, dann beginnt der Test mit dem Löschen aller Objektdateien. - Von dem neu generierten System wird die Prüfsumme ermittelt und eine Kopie extern gesichert. Dadurch kann am Schluss der Abnahme überprüft werden, ob immer noch das gleiche System getestet wird wie zu Beginn der Abnahme. - Das Benutzerhandbuch wird in die Tests einbezogen. Zumindest alle dort enthaltenen Beispiele müssen (fehlerfrei) ausgeführt werden. 20

Abnahmetest (Fortsetzung) - Am Ende jedes Testabschnitts oder eines Tages wird freies Testen durchgeführt. Diese Testfälle sind zu dokumentieren, um im Fehlerfall die Testfälle reproduzieren zu können. - Am Ende jedes Testabschnitts oder eines Tages werden die gefundenen Probleme in einem Protokoll festgehalten. 21

Methodischer Aufbau und Durchführung von Fach- und Abnahmetest Testprotokoll und Befundbehandlung Ein möglichst lückenloses Testprotokoll ist das wichtigste Ergebnis jedes Tests. Bei vollautomatischen Tests kann dieses ebenfalls als automatisch erzeugtes Dokument entstehen. Im Falle der manuellen Abarbeitung entsteht das Testprotokoll aufgrund der Vorlage zu den einzelnen Testfällen. Im Protokoll sind Spalten für die ordnungsgemäße Abarbeitung, für evtl. auftretende Anomalien (Befunde), deren Bewertung (jedoch nicht durch den Tester auszufüllen!) sowie deren Wiederholbarkeit vorzusehen. Im Falle eines Befundes sollte in der Regel sofort eine Wiederholung des Testfalls durchgeführt werden, um dessen Reproduzierbarkeit sicherzustellen. 22

Methodischer Aufbau und Durchführung von Fach- und Abnahmetest Testprotokoll und Befundbehandlung (Fortsetzung) Wird ein Mangel oder Befund festgestellt, so ist dieser zu kategorisieren. Das Vorhandensein von Fehlern der Klasse 1 wird häufig im Projektauftrag als abnahmeverhindernder Umstand benannt. Es ist deshalb empfohlen, wenn sich zwischen Auftraggeber und Auftragnehmer bereits früh eine gemeinsame Auffassung dazu entwickelt, was als Klasse-1-Fehler anzusehen ist. 23

Methodischer Aufbau und Durchführung von Fach- und Abnahmetest Fehlerbearbeitung Die Fehlerbearbeitung erfolgt in der Regel nach erfolgter Prüfung (ist es überhaupt ein Fehler?) durch den Auftragnehmer. Als praktisch hat sich erwiesen, in das Fehlerprotokoll nachträglich eine Referenz auf den in die Fehlerliste eingetragenen Fehler vorzunehmen (oder eben die Aussage, dass die Aufnahme und Bearbeitung abgelehnt wurde). 24

Methodischer Aufbau und Durchführung von Fach- und Abnahmetest Fehlerbearbeitung (Fortsetzung) In einer Fehlerliste sollte der Stand der offenen festgestellten Fehler (und deren Status) festgehalten werden. Mögliche Kennzeichnungen der Weiterverarbeitungen könnten sein: - wird durch CRxxxx behandelt (CR heißt change request) - Fehler behoben am TT.MM.JJ, Ursache - Korrektur wird zur Verfügung gestellt mit Version X.Y - Erfolgreich nachgetestet am TT.MM.JJ, siehe Nach der Fehlerkorrektur ist in einer korrigierten Version mit möglichst den gleichen Testdaten ein Nachtest vorzusehen. Bei schweren Fehlern kann es zusätzlich angeraten sein, ein oder zwei weitere Testfälle für diesen Nachtest zu konstruieren. 25

Methodischer Aufbau und Durchführung von Fach- und Abnahmetest Fehlerfindungsrate Setzt man umfassende Tests über mehrere Tage an, so lassen sich schon mit den rein quantitativen Aussagen eines jeden Tages sehr realistische Rückschlüsse auf die tatsächliche Qualität der jeweils getesteten Systemteile und auch des Testkonzepts ziehen: Ist die Zahl der gefundenen Fehler hoch, auch bei schweren Fehlern, so ist das untersuchte Testobjekt vermutlich noch sehr unreif. Bei kritischen Systemteilen wäre dies ein deutliches Warnsignal! Gibt es viele leichte, aber wenige schwere Fehler, waren die Tester möglicherweise sehr fleißig. Vielleicht ist es aber auch ein Zeichen für ein gutes Testkonzept, das schnell abgearbeitet werden konnte. _ 26

Methodischer Aufbau und Durchführung von Fach- und Abnahmetest Fehlerfindungsrate (Fortsetzung) Ist eine Software recht neu und wenig getestet, wurden an einem Testtag aber nur wenige Fehler gefunden, so sollte das Testkonzept selber auch kritisch geprüft werden. Sind die Tests gut und umfassend konzipiert, und werden sie konsequent durchgeführt, kann es aber auch einfach zu einer Fehlersättigung kommen: ein neuer Testtag bringt nicht mehr viel, weil eben die meisten Fehler bereits gefunden wurden. 27

Abnahme des Gesamtprodukts Die gesamte Abnahmeprozedur endet mit einer Schlusssitzung, bei der Auftraggeber und Auftragnehmer teilnehmen, in der die Fehler in den einzelnen Protokollen gewichtet und in ein Abnahmeprotokoll übernommen werden. Def.: Die formale Abnahme ist die (schriftliche) Erklärung der Annahme (im juristischen Sinne) eines Produkts durch den Auftraggeber. 28

Produkte für den anonymen Markt

Produkte für den anonymen Markt Handelt es sich bei dem abzunehmenden System um ein Produkt für den anonymen Markt, dann gibt es nur einen internen Auftraggeber (Marketingabteilung, Produktmanager etc.). In einem solchen Fall nimmt der interne Auftraggeber bzw. eine freigabeberechtigte Instanz innerhalb der Firma das Produkt ab. Da bei Systemen für den anonymen Markt die Prüfziele Fehlertoleranz, Benutzbarkeit, Konfiguration und Interoperabilität wegen der vielfältigeren Einsatzbereiche eine größere Bedeutung besitzen, werden diese Systeme in der Regel einem Alpha- und/oder Betatest unterzogen. 30

Alpha- und Betatest

Alpha- und Betatest Was versteht man unter einem Alpha- und Betatest? Beim Alphatest wird das System in der Zielumgebung des Herstellers durch Anwender erprobt. Beim Betatest wird das System bei ausgewählten Pilot -Kunden in deren eigener Umgebung zur Probenutzung zur Verfügung gestellt. Auftretende Probleme und Fehler werden protokolliert. Die Pilotkunden erhalten beim späteren Kauf des Produkts in der Regel einen Preisnachlass. 32

Fazit Auch nach erfolgreichem Abnahmetest befinden sich noch Fehler im System sowohl bekannte als auch unbekannte. Die Abnahme durch den Auftraggeber stellt demnach immer einen Kompromiss zwischen dem optimalen Ergebnis (fehlerfreies Produkt) und dem akzeptablen Produkt (mit tolerierbaren Fehlern) dar. 33

Puh, fertig... 34