Basiswissen Softwaretest E-Book

Andreas Spillner

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: iSQI-Reihe
• Sprache: Deutsch
• Veröffentlichungsjahr: 2019

Seitenzahl: 521

Beschreibung

Professionelles Prüfen und Testen von Software ist eine unabdingbare und sehr wichtige Aufgabe zur Qualitätssicherung bei der Entwicklung und Wartung von Software – unabhängig davon, ob agil oder konventionell vorgegangen wird. Eine solch wichtige Aufgabe erfordert Fachwissen, erworben durch eine fundierte Ausbildung. Mit dem "Certified Tester"-Programm existiert ein international standardisiertes Aus- und Weiterbildungsschema für Softwaretester und Softwareentwickler.Dieses Buch umfasst den erforderlichen Stoff zum Ablegen der Prüfung "Certified Tester (Foundation Level)" nach ISTQB®-Standard. Es vermittelt das nötige Grundlagenwissen und verwendet dabei ein durchgängiges Beispiel. Das Buch eignet sich damit nicht nur bestens für die Prüfungsvorbereitung, sondern dient gleichzeitig als kompaktes Basiswerk zu diesen Themen.In vielen Unternehmen und Projekten hat sich das Buch als Standard(nachschlage)werk für das Prüfen und Testen von Software etabliert. Um diesem Anspruch auch weiterhin gerecht zu werden, wurden in der neuen Auflage praxiserprobte Testverfahren aus dem aktuellen ISO-Standard 29119 hinzugenommen. Damit werden alle wesentlichen Methoden zum Testen von Software und zum Prüfen der während der Softwareentwicklung verwendeten und erstellten Dokumente im Buch ausführlich behandelt.Die 6. Auflage wurde komplett überarbeitet und ist konform zum ISTQB®-Lehrplan Version 2018. Abgedeckt wird damit auch der entsprechende deutschsprachige Foundation-Level-Lehrplan des German Testing Board, des Austrian Testing Board und des Swiss Testing Board.

Leseprobe

Über die Autoren

Andreas Spillner war bis 2017 Professor für Informatik an der Hochschule Bremen. Ab 1991 war er für über 10 Jahre Sprecher der Fachgruppe TAV »Test, Analyse und Verifikation von Software« der Gesellschaft für Informatik e.V. (GI), die er mit gegründet hat. Im »German Testing Board« e.V. war er von Beginn an bis zum Jahr 2009 engagiert und wurde danach zum Ehrenmitglied berufen. 2007 ist er zum Fellow der GI ernannt worden. Seine Arbeitsschwerpunkte liegen im Bereich Softwaretechnik, Qualitätssicherung und Testen. Andreas Spillner ist neben Ulrich Breymann Autor des Buches »Lean Testing für C++-Programmierer – Angemessen statt aufwendig testen« (dpunkt.verlag), das die Testverfahren der ISO-Norm 29119 und deren konkrete Umsetzung in die Programmiersprache C++ erörtert.

Tilo Linz ist Vorstand und Mitgründer der imbus AG, eines führenden Lösungsanbieters für Softwaretest, und seit mehr als 25 Jahren im Themengebiet Softwarequalitätssicherung und Softwaretest tätig. Als Gründungsmitglied und Vorsitzender des »German Testing Board« e.V. und Gründungsmitglied im »International Software Testing Qualifications Board« hat er die Aus- und Weiterbildung in diesem Fachbereich auf nationaler und internationaler Ebene maßgeblich mitgestaltet und vorangebracht. Tilo Linz ist auch Autor des Buches »Testen in Scrum-Projekten« (dpunkt.verlag), das aufbauend auf dem vorliegenden »Basiswissen Softwaretest« das Testen in agilen Projekten behandelt.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Andreas Spillner · Tilo Linz

BasiswissenSoftwaretest

Aus- und Weiterbildung zum Certified Tester

Foundation Level nach ISTQB®-Standard

6., überarbeitete und aktualisierte Auflage

Andreas Spillner

[email protected]

Tilo Linz

[email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print     978-3-86490-583-4

PDF      978-3-96088-501-6

ePub    978-3-96088-502-3

mobi    978-3-96088-503-0

6., überarbeitete und aktualisierte Auflage 2019

Copyright © 2019 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort zur 6. Auflage

Bestseller

Bereits Ende 2002 erschien die erste Auflage dieses Buches. Seither entwickelte sich »Basiswissen Softwaretest« zum meistverkauften Buch zum Thema Softwaretest in deutscher Sprache. In der vorliegenden 6. Auflage haben wir den Inhalt weitreichend überarbeitet, aktualisiert und der aktuellen Version 2018 des Lehrplans zum »ISTQB® Certified Tester – Foundation Level« angepasst.

»Certified Tester«-Ausbildungsschema

Das anerkannte und sehr erfolgreiche »Certified Tester«-Ausbildungsschema gliedert sich in Säulen mit jeweils drei Ausbildungsstufen. Details dazu finden sich auf der Webseite des »International Software Testing Qualifications Board« [URL: ISTQB] und des »German Testing Board e.V.« [URL: GTB].

Der »Certified Tester« ist zu einer festen Marke in der IT-Industrie geworden und ist heute der De-facto-Standard für die Ausbildung im Bereich Softwarequalitätssicherung und Softwaretest sowohl in Deutschland als auch weltweit. Ende 2018 hat die Zahl der insgesamt ausgestellten Softwaretest-Zertifikate die 600.000 überschritten, davon in Deutschland knappe 67.000.

Wissen in der IT-Welt gefragt

In vielen Stellenanzeigen spiegelt sich dieser Umstand wider. Nicht nur bei Berufseinsteigern erwarten die Firmen Grundkenntnisse im Testbereich – am besten durch das Zertifikat nachgewiesen.

Certified Tester an Hochschulen

Der »Certified Tester« ist auch Teil der Informatikausbildung an vielen Hochschulen: Von A wie Aachen bis Z wie Zweibrücken wird der Lehrstoff im deutschsprachigen Bereich vermittelt. Welche Hochschulen aktuell entsprechende Lehrveranstaltungen anbieten bzw. planen, diese anzubieten, ist auf den Seiten des »German Testing Board« nachzulesen [URL: GTB Hochschulen]. 5 %–7 % aller Prüfungen zum »ISTQB® Certified Tester – Foundation Level« sind studentische Prüfungen.

Basiswissen

Trotz der stürmischen Entwicklung – auch in der Informatik gibt es Grundlagenwissen, das kaum Änderungen unterliegt. Von Anfang an haben wir den ersten Teil unseres Buchtitels »Basiswissen« ernst genommen und ganz bewusst keine Themen behandelt, die sich erst noch in der Praxis »beweisen müssen«. Auch »Spezialdisziplinen« im Testen, wie beispielsweise der Test von Webapplikationen oder der Test von eingebetteten Systemen, gehören für uns nicht zu den Grundlagen. Hier verweisen wir auf entsprechende aktuelle Literatur zu diesen Themen.

Ergänzende Literatur

Tilo und Andreas haben seit der letzten Ausgabe des vorliegenden Buches aktuelle Bücher veröffentlicht, auf die hier hingewiesen werden soll, da sie eine gute Ergänzung bzw. Vertiefung darstellen.

Buch: Testen in Scrum-Projekten – Leitfaden für Softwarequalität in der agilen Welt

Tilo hat mit seinem Buch »Testen in Scrum-Projekten – Leitfaden für Softwarequalität in der agilen Welt« (Erstauflage 2013) aufgezeigt, wie das Testen in agilen Projekten zu integrieren ist. Inzwischen gibt es einen Lehrplan (»ISTQB® Certified Agile Tester – Foundation Extension«) zu diesem Themenbereich und das Buch wurde entsprechend aktualisiert und liegt seit 2016 in der 2. Auflage vor.

Buch: Lean Testing für C++-Programmierer – Angemessen statt aufwendig testen

Andreas hat zusammen mit Ulrich Breymann1 das Buch »Lean Testing für C++-Programmierer – Angemessen statt aufwendig testen« geschrieben. Im Buch sind alle Testverfahren des aktuellen ISO-Standards 29119 ausführlich beschrieben, die für den Komponententest relevant sind. Die Vorgehensweisen zum Testfallentwurf werden konkret mit den entsprechenden C++-Programmtexten und den jeweiligen Testfällen dargelegt. Dabei sind die Programmbeispiele so einfach gehalten, dass sie auch ohne C++-Kenntnisse verständlich sind.

Auf beide Bücher wird in diesem Buch des Öfteren verwiesen ([Linz 16], [Spillner 16]), um dem Leser weiterführende Informationen anzubieten. Vielleicht sind wir mit den vielen Hinweisen etwas über das Ziel hinausgeschossen, dafür bitten wir um Nachsicht – aber etwas Werbung für die eigene Arbeit wird hoffentlich noch erlaubt sein, oder?

Was hat sich geändert?

In der vorliegenden 6. Auflage von »Basiswissen Softwaretest« wurde eine umfassende Überarbeitung, Ergänzung und Aktualisierung des Inhalts vorgenommen.

Exkurs-Teile sind nicht Teil des Lehrplans.

Bei der Überarbeitung des ISTQB®-Lehrplans wurden einige Testverfahren auf höhere Ausbildungsstufen verschoben und sind somit nicht mehr Teil des »Foundation Level«-Lehrplans. Wir haben diesen Schritt nicht rigoros umgesetzt, sondern diese Verfahren weiterhin im Buch belassen, aber als Exkurs hervorgehoben. Wer das Buch nur zur Prüfungsvorbereitung nutzt, der überschlägt einfach die Exkurs-Teile.

Weitere Testverfahren aufgenommen

Aus vielen Gesprächen mit Lesern wissen wir, dass unser Buch als Nachschlagewerk bei der täglichen (Test-)Arbeit genutzt wird. Deshalb haben wir versucht, neben den Inhalten des Lehrplans weitere grundlegende Testverfahren aufzunehmen. Im Vergleich zu den vorherigen Ausgaben sind neue Verfahren hinzugekommen (z.B. Kombinatorisches Testen, »Pairwise Testing«).

Das durchgehende Fallbeispiel und das Literaturverzeichnis wurden aktualisiert. Das Verzeichnis der Normen und Standards wurde ebenfalls überarbeitet und die Standards gestrichen, die durch den aktuellen Standard ISO 29119 abgelöst wurden. Die Angaben zu den Internetseiten (URLs) wurden kontrolliert und ggf. geändert bzw. ergänzt.

Webseite

Um die Leser über zukünftige Aktualisierungen am Lehrplan und am Glossar zu informieren, betreiben wir die Internetseite [URL: Softwaretest Knowledge]. Auf der Seite werden ggf. auch notwendige Korrekturen zum Buchtext aufgeführt. Dort finden sich ebenfalls Übungsaufgaben zu den einzelnen Buchkapiteln.

Danksagung

Erfolg hat meist viele Väter und Mütter – so auch hier. Wir möchten uns recht herzlich bei allen Kolleginnen und Kollegen des »German Testing Board« und des »International Software Testing Qualifications Board« bedanken. Ohne deren Engagement hätte das »Certified Tester«-Ausbildungsschema nicht den geschilderten Erfolg und weltweite Akzeptanz erhalten. Ebenso möchten wir uns für die vielen Anmerkungen und Rezensionen unserer Leser bedanken, die uns für unsere Arbeit am Buch sehr motiviert haben und zur Qualitätssteigerung beigetragen haben. Unserer Lektorin Frau Christa Preisendanz und dem gesamten dpunkt-Team möchten wir recht herzlich für die sehr gute langjährige Zusammenarbeit danken.

Wir wünschen allen Lesern gutes Gelingen bei der Umsetzung der im Buch beschriebenen Testansätze in der Praxis und – wenn das Buch die Grundlage für die Vorbereitung zur Prüfung zum »Certified Tester – Foundation Level« ist – viel Erfolg bei der Beantwortung der Prüfungsfragen.

Andreas Spillner und Tilo Linz

Bremen, Möhrendorf

Mai 2019

Inhaltsübersicht

1 Einleitung

2 Grundlagen des Softwaretestens

3 Testen im Softwareentwicklungslebenszyklus

4 Statischer Test

5 Dynamischer Test

6 Testmanagement

7 Testwerkzeuge

Anhang

A Wichtige Hinweise zum Lehrstoff und zur Prüfung zum Certified Tester

B Glossar

C Quellenverzeichnis

Index

Inhaltsverzeichnis

1 Einleitung

2 Grundlagen des Softwaretestens

2.1 Begriffe und Motivation

2.1.1 Fehlerbegriff

2.1.2 Testbegriff

2.1.3 Testartefakte und ihre Beziehungen

2.1.4 Aufwand für das Testen

2.1.5 Testwissen frühzeitig und damit erfolgreich nutzen

2.1.6 Grundsätze des Testens

2.2 Softwarequalität

2.2.1 Qualitätsmanagement und Qualitätssicherung

2.3 Der Testprozess

2.3.1 Testplanung

2.3.2 Testüberwachung und Teststeuerung

2.3.3 Testanalyse

2.3.4 Testentwurf

2.3.5 Testrealisierung

2.3.6 Testdurchführung

2.3.7 Testabschluss

2.3.8 Rückverfolgbarkeit

2.3.9 Einfluss des Kontextes auf den Testprozess

2.4 Die menschliche Psychologie und das Testen

2.4.1 Denkweisen von Testern und Entwicklern

2.5 Zusammenfassung

3 Testen im Softwareentwicklungslebenszyklus

3.1 Sequenzielle Entwicklungsmodelle

3.1.1 Das Wasserfallmodell

3.1.2 Das allgemeine V-Modell

3.2 Iterative und inkrementelle Entwicklungsmodelle

3.3 Softwareentwicklung im Projekt- und Produktkontext

3.4 Teststufen

3.4.1 Komponententest

3.4.2 Integrationstest

3.4.3 Systemtest

3.4.4 Abnahmetest

3.5 Testarten

3.5.1 Funktionale Tests

3.5.2 Nicht funktionale Tests

3.5.3 Anforderungsbezogener und strukturbezogener Test

3.6 Test nach Änderung und Weiterentwicklung

3.6.1 Testen nach Softwarewartung und -pflege

3.6.2 Testen nach Weiterentwicklung

3.6.3 Regressionstest

3.7 Zusammenfassung

4 Statischer Test

4.1 Was kann analysiert und geprüft werden?

4.2 Vorgehen beim statischen Test

4.3 Der Reviewprozess

4.3.1 Aktivitäten im Reviewprozess

4.3.2 Unterschiedliche Vorgehensweisen beim individuellen Review

4.3.3 Rollen und Verantwortlichkeiten im Reviewprozess

4.4 Reviewarten

4.5 Erfolgsfaktoren, Vorteile und Grenzen

4.6 Unterschiede zwischen statischen und dynamischen Tests

4.7 Zusammenfassung

5 Dynamischer Test

5.1 Blackbox-Testverfahren

5.1.1 Äquivalenzklassenbildung

5.1.2 Grenzwertanalyse

5.1.3 Zustandsbasierter Test

5.1.4 Entscheidungstabellentests

5.1.5 Kombinatorisches Testen

5.1.6 Anwendungsfallbasierter Test

5.1.7 Allgemeine Bewertung der Blackbox-Verfahren

5.2 Whitebox-Testverfahren

5.2.1 Anweisungstest und Anweisungsüberdeckung

5.2.2 Entscheidungstest und Entscheidungsüberdeckung

5.2.3 Test der Bedingungen

5.2.4 Allgemeine Bewertung der Whitebox-Verfahren

5.3 Erfahrungsbasierte Testfallermittlung

5.4 Auswahl von Testverfahren

5.5 Zusammenfassung

6 Testmanagement

6.1 Testorganisation

6.1.1 Unabhängiges Testen

6.1.2 Rollen, Aufgaben und Qualifikation

6.2 Teststrategie

6.2.1 Teststrategie und Testkonzept

6.2.2 Auswahl der Teststrategie

6.2.3 Verschiedene konkrete Strategien

6.2.4 Testen und Risiko

6.2.5 Testaufwand und Testkosten

6.2.6 Schätzverfahren zum Testaufwand

6.2.7 Testkosten vs. Fehlerkosten

6.3 Testplanung, Teststeuerung und Testüberwachung

6.3.1 Testausführungsplanung

6.3.2 Teststeuerung

6.3.3 Testzyklusüberwachung

6.3.4 Testberichte

6.4 Fehlermanagement

6.4.1 Testprotokoll auswerten

6.4.2 Fehlermeldung erstellen

6.4.3 Fehlerwirkungen klassifizieren

6.4.4 Fehlerstatus verfolgen

6.4.5 Auswertungen und Berichte

6.5 Konfigurationsmanagement

6.6 Relevante Normen und Standards

6.7 Zusammenfassung

7 Testwerkzeuge

7.1 Testwerkzeugtypen

7.1.1 Werkzeuge für Management und Steuerung von Tests

7.1.2 Werkzeuge zur Testspezifikation

7.1.3 Werkzeuge für statischen Test

7.1.4 Werkzeuge zur Automatisierung dynamischer Tests

7.1.5 Werkzeuge für Last- und Performanztest

7.1.6 Werkzeugunterstützung für spezielle Testbedürfnisse

7.2 Nutzen und Risiken der Testautomatisierung

7.3 Effektive Nutzung von Werkzeugen

7.3.1 Auswahl und Einführung von Testwerkzeugen

7.3.2 Werkzeugauswahl

7.3.3 Pilotprojekt zur Werkzeugeinführung

7.3.4 Faktoren für die erfolgreiche Einführung und Nutzung

7.4 Zusammenfassung

Anhang

A Wichtige Hinweise zum Lehrstoff und zur Prüfung zum Certified Tester

B Glossar

C Quellenverzeichnis

C.1 Literatur

C.2 Weitere empfohlene Literatur

C.3 Normen und Standards

C.4 WWW-Seiten

Index

Vorwort zur 1. Auflage

Motivation für ein weiteres Testbuch

Warum haben wir ein Buch zum Thema Softwaretest geschrieben, wo es doch eine ganze Reihe von Büchern in diesem Bereich bereits gibt?

Wir beide beschäftigen uns seit vielen Jahren mit Themen und Fragestellungen im Bereich Softwaretest. Der eine mit einer eher wissenschaftlichen Ausrichtung, der andere mit der täglichen Anwendung der Prüfverfahren in der Praxis. Beide sind wir der Auffassung, dass der systematische Einsatz von Prüfverfahren in der Praxis in vielen Firmen verbesserungsfähig ist und es einen großen Mangel an qualifiziertem Personal gibt.

Die Initiative des ISEB (Information Systems Examination Board), ein dreistufiges Qualifizierungsprogramm im Bereich Softwaretest zu definieren, Kursanbieter in diesem Bereich zu akkreditieren und den Teilnehmern die Möglichkeit zu bieten, sich einer unabhängigen Prüfinstanz zu stellen und ein Zertifikat zu erhalten, ist von uns von Beginn an mit starkem Interesse verfolgt worden. Die Initiative ist vom ASQF (Arbeitskreis Software-Qualität in Franken e.V.) und der Fachgruppe TAV (Test, Analyse und Verifikation von Software) der Gesellschaft für Informatik aufgegriffen worden. Eine ausführliche Beschreibung der Zusammenhänge findet sich in der Einleitung des Buches.

Die Lehrpläne für das Qualifizierungsprogramm sind in Gremien von mehreren europäischen Fachexperten erarbeitet worden und bündeln das derzeitige Wissen im Bereich Softwaretest. Die Inhalte sind in vielen Büchern zu finden, aber eben nicht in einem einzigen Buch. Die Lehrpläne listen die einzelnen Punkte auf, die zu behandeln sind, enthalten aber weder detaillierte Beschreibungen der einzelnen Verfahren und Vorgehensweisen beim Testen von Software noch erläuternde Beispiele. Die Idee, ein »passendes« Buch zu schreiben, fanden wir sehr nahe liegend.

Grundlage für unser Buch ist der Lehrplan »Grundlagen des Softwaretestens« ASQF Certified Tester, Foundation Level [URL: GTB Lehrpläne]. Die ersten Erfahrungen mit dem Lehrplan zum Foundation Level führten zu dem Wunsch einer leichten Überarbeitung, die derzeit von einem Gremium des ISTQB (International Software Testing Qualifications Board) in Angriff genommen wird. Wir beide haben durch die Arbeit am Buch kleinere Schwachstellen im Lehrplan erkannt und beteiligen uns aktiv an dessen Überarbeitung. Die nach Beendigung der Arbeit beschlossenen Änderungen, die sich auf den Inhalt des Buches auswirken, werden wir auf der WWW-Seite zum Buch [URL: dpunkt] aktuell dokumentieren.

Der Titel unseres Buches »Basiswissen Softwaretest« sagt eigentlich schon alles. Wir sind davon überzeugt, dass jeder im Bereich der Softwareentwicklung Tätige – sei es beispielsweise in der Programmierung, in der Qualitätssicherung, in der Projektleitung oder im Management – ein Grundwissen im Softwaretest besitzen sollte, um seine tägliche Arbeit besser verrichten und den oft vernachlässigten Bereich Testen besser einschätzen oder überhaupt verstehen zu können. Die Aussage trifft selbstverständlich auch für die zukünftig Tätigen, die Studierenden und Auszubildenden im IT-Bereich, zu. Auch so mancher Lehrende wird sein Wissen mithilfe des Buches vervollständigen können.

Wir haben uns bemüht, ein leicht verständliches und kompaktes Buch zu schreiben, um dem großen Kreis an möglichen Lesern gerecht zu werden. Vorwissen im Bereich Testen oder Qualitätssicherung ist nicht erforderlich, Grundkenntnisse der Softwareentwicklung sind sicherlich hilfreich. Unser Buch hat zwar den Lehrplan zum »Certified Tester, Foundation Level« als Grundlage, es besteht aber keine zwanghafte Kopplung, auch das entsprechende Zertifikat zu erwerben.

Drei Geleitworte

Warum gibt es drei Geleitworte in Englisch und Deutsch in unserem Buch?

Durch unsere langjährigen Aktivitäten im Bereich Softwaretest haben wir zahlreiche internationale Kontakte aufbauen können. Als unser Buchprojekt konkrete Formen annahm, haben wir drei Personen um Geleitworte gebeten. Da alle drei viel gefragte und beschäftigte Persönlichkeiten sind, haben wir eher mit zurückhaltenden Reaktionen gerechnet. Um so erfreuter waren wir, dass wir tatsächlich drei Geleitworte innerhalb der Termine erhalten haben. Unsere »Risiko«-Planung war somit völlig unnötig. Da jedes Geleitwort einen anderen Aspekt vertieft, haben wir uns entschlossen, alle drei aufzunehmen.

Prof. David Parnas Ph.d, Dr. h.c., Dr. h.c., FRSC, P.Eng.

David Parnas, der Begründer der Modularisierung und des Geheimnisprinzips (information hiding), engagiert sich seit langem in Fragen der Ausbildung im Bereich Informatik. Für ihn muss die Informatik-Ausbildung eine Professionalität erreichen wie bei den Medizinern oder in den Rechts- und Ingenieurwissenschaften. Die allgemein anerkannte Festlegung von Lehrinhalten und der Nachweis des erworbenen Fachwissens, beispielsweise im Bereich Softwaretest, sieht er als einen Schritt in die richtige Richtung an. Teile des Buches sind während des Forschungsaufenthalts von Andreas Spillner auf Einladung von David Parnas an der McMaster University in Hamilton, Ontario in Kanada entstanden. Ausführliche Informationen zu David Parnas sind zu finden unter [URL: Parnas].

Martin Pol

Martin Pol gehört wohl zu den bekanntesten Persönlichkeiten im Testbereich in Europa, wenn nicht gar weltweit. Er ist Mitautor von T-Map (Test Management Approach) und TPI (Test Process Improvement). 1998 erhielt er den »European Testing Excellence Award«. In seinem Geleitwort hebt er die Bedeutung des Testens im Softwareentwicklungsprozess hervor und wie wichtig Basiswissen im Softwaretest für alle im IT-Bereich arbeitenden Personen ist. Ausführliche Informationen zu Martin Pol sind abrufbar unter [URL: Pol].

Dorothy Graham A.B., M.Sc.

Dorothy Graham, seit vielen Jahren Beraterin und Trainerin im Softwarequalitäts- und Testbereich, hat das ISEB Software Testing Board mitgegründet und gehört ihm seitdem an. Ohne das große Engagement von Dorothy Graham wäre die ISEB-Initiative wohl nicht so weit vorangeschritten und die erfolgte Internationalisierung noch in weiter Ferne. Sie ist Mitautorin von Büchern zu den Themen »Software-Inspektionen« und »Softwaretest-Automatisierung«. Der »European Testing Excellence Award« wurde ihr 1999 zuerkannt. In ihrem Geleitwort macht Dorothy Graham die Vorteile einer Akkreditierung und Zertifizierung durch eine unabhängige Instanz deutlich. Ausführliche Informationen zu ihrer Person sind unter [URL: Graham] zu finden.

Wir möchten Dorothy Graham, Martin Pol und David Parnas für ihre Unterstützung und die aufgewendete Zeit recht herzlich danken.

Danksagung

Wie es sich für ein Projekt mit einem Qualitätsanspruch gehört, haben wir unsere Arbeit externen Reviewern vorgelegt. Wir haben viele Anregungen und Hinweise zur Verbesserung des Textes und der Beispiele erhalten. Wir möchten uns für die vielen geopferten Stunden Freizeit ganz herzlich bedanken bei Uwe Hehn, Ruth Keys, Karin Vosseberg und Mario Winter. Darüber hinaus gilt unser Dank den Kolleginnen und Kollegen der imbus AG, die ebenfalls durch zahlreiche Anmerkungen und konstruktive Diskussionen zum Gelingen des Buches beigetragen haben. Besonders erwähnen möchten wir Matthias Daigl und Thomas Roßner.

Bedanken möchten wir uns auch bei den Mitarbeiterinnen und Mitarbeitern des dpunkt.verlags. Zu Beginn unseres Projekts hatten wir uns eine Deadline gesetzt, was bei jedem Projekt erfolgen sollte. Auch Dank der großen Unterstützung des Verlags ist es gelungen, den von uns geplanten Fertigstellungstermin zu halten.

Wir wünschen allen Lesern des Buches erfolgreiche Stunden in dem Sinne, dass Testen nicht mehr als notwendiges Übel der Softwareentwicklung am Projektende betrachtet wird, sondern als herausfordernde, kreative Tätigkeit, die projektbegleitend erfolgt und neben der Aufdeckung von Fehlern auch zum Nachweis der Qualität der erstellten oder geänderten Software dient. Testen kann und soll auch Spaß machen.

Andreas Spillner und Tilo Linz

Bremen, Möhrendorf

September 2002

Geleitwort von David Parnas1

One of the biggest problems in the computer software field is the ability of inadequately qualified people to enter the profession and practice software development without limits. Software has become critical to our society; it is embedded in many devices that we count on, devices such as telephones and banking machines. Nonetheless, many of the people who write that software have not been educated for the job and have never demonstrated their qualifications to any objective professional body. There is no other field in the world where people without approved education can decide to identify themselves as »Engineers« and produce products that are essential to the safety and well-being of the public.

Software is well known for low reliability and lack of trustworthiness. In part this is attributable to the difficulty of dealing with the complexity of today’s software systems, but the inadequate knowledge, skills, and professionalism of many of the practitioners also contributes to this problem. Moreover, we can thank the inadequately qualified people who produced today’s software for the unreliability and complexity of the products that serve as support software for new products.

Our educational institutions have failed the public in this field. They have not recognized that those who study Computer Science require a professional education, one similar in style to the education provided to those who study medicine, law, or engineering. In those fields, the curriculum is designed around a set of professional requirements. Students are told what they must learn, rather than allowed to learn what they feel like learning. In the software field, universities have allowed the contents of courses to depend on the whim of the instructor, and the choice of courses to be largely up to the student. As a result, when an employer or client meets a graduate of a Computer Science programme, only experienced software developers are able to judge whether or not a graduate has the knowledge and skills needed for the job. Often, we cannot even find a graduate who has the appropriate body of knowledge and experience.

This problem is quite clear in the area of software testing. Many new employees are assigned testing duties without any knowledge how to design tests, how to evaluate test results, and how to draw valid conclusions can be drawn from the test results. Fortunately, there is now a useful international initiative to establish national Testing Boards, which will approve courses of instruction and issue certificates to those who are able to demonstrate their understanding of basic terms and procedures in testing.

Unfortunately, this is still a shortage of appropriate study material for people who would like to become better software testers and pass the national tests. This book, »Basiswissen Softwaretest« by Spillner and Linz, fills this gap by providing a well organized and complete view of what is known about how to test software. It provides an essential component of the international effort to establish standards for software professionals and then help people to become fully qualified software developers.

David Lorge Parnas,

Ph.d, Dr.h.c., Dr.h.c., FRSC, P.Eng.

McMaster University, Hamilton,

Ontario, Canada

June 2002

Geleitwort von Martin Pol

Für viele Organisationen spielt die Qualität von Softwaresystemen eine immer größere Rolle. Es werden zunehmend Maßnahmen ergriffen, um eine höhere Qualität zu erreichen. Trotz ermutigender Resultate mit verschiedenen Ansätzen zur Qualitätssicherung ist die ITBranche weit davon entfernt, fehlerfreie Software entwickeln zu können. Ein solches Ziel wird leider noch für geraume Zeit eine Utopie bleiben. Die Entwicklung von Softwaresystemen ist nach wie vor ein schwieriges »Handwerk« und auf absehbare Zeit kaum ohne Fehler zu meistern. Die Ursachen für Fehler sind vielfältig und schwer vorhersehbar. Man wird weiterhin nicht umhin kommen, viel Energie darauf zu verwenden, die Fehler ausfindig zu machen. Das Testen wird ein wichtiger Bestandteil der Entwicklung und Wartung bleiben und oft mehr als 30 – 40 % des Gesamtbudgets aufzehren.

Das Testen ist nicht mehr nur eine Phase, die nach der Implementierung kommt, sondern ist ebenso ernst zu nehmen wie andere Aktivitäten der Entwicklung von Systemen. Testen ist zu einer eigenständigen Aufgabe und Tätigkeit geworden. Die Informatik hat sukzessive die Grundideen des Testens akzeptiert: Testen von Software ist ein Prozess, bestehend aus Planung und Vorbereitung einerseits und Messen und Prüfen andererseits. Testen dient dazu, die Charakteristika eines Systems festzustellen und die Unterschiede zwischen dem Ist- und dem Sollverhalten aufzuzeigen. Gute Qualität kann als Erfüllung der Anforderungen gesehen werden. Somit ist das Ergebnis des Testens, die vorhandene Qualität aufzuzeigen und Verbesserungen zu ermöglichen. Es gibt einen Einblick darin, welche Risiken bestehen, wenn eine geringere Qualität akzeptiert wird. Dies ist ebenfalls ein wesentliches Ziel des Testens.

Da Time-to-Market, Wettbewerb, Globalisierung und Quality of Service, einschließlich der Qualität von Softwaresystemen, für viele Firmen zu einem wichtigen Überlebensfaktor geworden sind, steigt der Bedarf für einen angemessenen Testprozess immer weiter an. Sowohl die immer größer werdende Bedeutung von Software in unserer Gesellschaft als auch das Budget, das für das Testen ausgegeben wird, bestätigen den Bedarf an einem gut strukturierten und verlässlichen Testprozess innerhalb der Softwareentwicklung. Hierbei sind ein strukturiertes Vorgehen, eine angemessene Organisationsstruktur und die entsprechende Infrastruktur notwendig.

Dieses Buch schafft die Grundlage für einen gut strukturierten Testprozess. Es beschreibt die Grundsätze des Testens, alle Aktivitäten zum Testen innerhalb des Entwicklungsprozesses, Techniken des Testens, Testmanagement und Testwerkzeuge. Daher ist das Buch für jeden von Interesse, der im IT-Bereich arbeitet: Entwickler, Tester, Anwender, Projekt- und Abteilungsleiter etc. Darüber hinaus ist es ein idealer Begleiter, um sich auf das ISEB-Zertifizierungsprogramm vorzubereiten. Egal für welchen Einsatz – ich bin mir sicher, dass dieses umfassende Buch von sehr großem Nutzen sein wird.

Martin Pol

Polteq IT Services B.V.

Amersfoort, The Netherlands

June 2002

Geleitwort von Dorothy Graham

Was macht ein gutes Zertifizierungsprogramm für Fachleute aus? Ein erfolgreiches Programm muss vor allem drei Hauptkriterien erfüllen:

Es muss ein Grundkonsens über das Thema vorhanden sein

Es muss denen, die das Zertifikat erhalten (und ihren Arbeitgebern), einen Mehrwert bieten

Es muss allen Beteiligten gegenüber fair sein und darf niemanden bevorzugen

Im vorliegenden Buch geht es um ein Programm, das diese Kriterien erfüllt. Beim Thema Softwaretesten ist ein ausreichender Konsens vorhanden, der als Basis für ein Zertifikat dienen kann. Das neue deutsche ASQF-Programm und das erfolgreiche ISEB-Programm aus Großbritannien werden sich bald international durchsetzen. Der Hauptgrund für den Erfolg des britischen Programms ist meiner Meinung nach die Unabhängigkeit des akkreditierenden und prüfenden Gremiums. Ich glaube auch, dass diese Philosophie den Erfolg des internationalen Programms für zertifizierte Tester sicherstellen wird, bei dem Deutschland momentan eine Vorreiterrolle spielt.

Bei dieser Unabhängigkeit spielen zwei Aspekte eine Rolle: zum einen die Akkreditierung von Ausbildungseinrichtungen und zum anderen die Prüfung der einzelnen Kandidaten.

Worin liegt der Unterschied zwischen Zertifizierung und Akkreditierung? Bei der Zertifizierung geht es um den einzelnen Teilnehmer, während die Akkreditierung Ausbildungseinrichtungen betrifft. Der Teilnehmer erhält ein Zertifikat, wenn er sein Wissen unter Beweis stellt. Das Wissen wird durch gewonnene Arbeitserfahrung und durch Fortbildungsveranstaltungen erworben. Wenn ein Grundkonsens über das Thema vorhanden ist (und damit eine Art »Lehrplan«) kann ein unabhängiges Gremium Kurse von Ausbildungseinrichtungen prüfen – dabei handelt es sich um die Akkreditierung. Die Akkreditierung bescheinigt, dass die Ausbildung einen bestimmten Standard im Hinblick auf Inhalt und Organisation erfüllt. Wenn sich Ausbildungseinrichtungen selbst akkreditieren, ist dies nur wenig aussagekräftig; die Akkreditierung durch ein unabhängiges Gremium ist sehr viel glaubwürdiger.

Um ein Zertifikat zu erhalten, muss der Kandidat eine Prüfung bestehen, die auf einem anerkannten Lehrplan beruht. Wenn die Prüfung durch ein unabhängiges Gremium gestellt, überwacht und benotet wird, bestehen gleiche Chancen für alle Kandidaten (und Ausbildungseinrichtungen). Durch die Unabhängigkeit des überwachenden Gremiums steigt der Wert des vergebenen Zertifikats.

Es gibt Programme, bei denen sich die Ausbildungseinrichtungen selbst akkreditieren und ihre eigenen Prüfungen stellen. Obwohl diese Programme durchaus einen gewissen Wert haben, bieten unabhängige Programme mehr. Diejenigen, die Zertifizierungsprogramme generell ablehnen, betonen, dass es bei allen Programmen Probleme geben kann. Dies ist durchaus richtig – das perfekte Programm gibt es nicht. Dennoch bin ich der Überzeugung, dass unabhängige Programme wie ISEB, ASQF oder der geplante internationale Standard für die Teilnehmer und ihre Arbeitgeber von erheblichem Wert sein werden.

Woher wissen wir, dass ein unabhängiges Programm funktionieren wird? Weil ISEB bereits in vielen Ländern funktioniert. ISEB steht für Information Systems Examination Board. Das ISEB wurde ursprünglich als unabhängiges Gremium für Qualifizierungen im Bereich Systemanalyse und -design gegründet. Es gehört nun zu der British Computer Society und bietet Qualifikationen in zehn Fachgebieten an, darunter Projektmanagement, IT-Service-Management, Geschäftssystementwicklung, Datenschutz und -Sicherheit – und seit 1998 auch Softwaretesten. An der Spitze jedes Fachgebiets bilden Vertreter aus Industrie und Hochschule einen Ausschuss. Arbeitsgruppen kümmern sich um Einzelfragen. So gibt es im Bereich Softwaretesten eine Arbeitsgruppe für die Akkreditierung und eine für die Prüfung. ISEB- Mitarbeiter sorgen für die Verwaltung der Ausschüsse und der Arbeitsgruppen, bei den Prüfungen stellen sie das Aufsichtspersonal, verteilen die von der Prüfungs-AG erarbeiteten Prüfungsfragen und werten die Antworten der Kandidaten aus.

Der Ausschuss Softwaretesten des ISEB wurde 1997 gegründet. Der Lehrplan für den Foundation Level wurde von Ausschussmitgliedern aufgestellt und der erste Kurs im Oktober 1998 abgehalten. Seither läuft das Programm mit großem Erfolg und übertrifft alle Erwartungen. Es ist inzwischen – nach IT-Service-Management – das erfolgreichste Programm des ISEB. Bis Mitte 2002 waren bereits 23 Ausbildungseinrichtungen für den Kurs Softwaretesten (Foundation Level) akkreditiert, darunter Organisationen aus Deutschland, den Niederlanden, Schweden, Irland und Australien sowie Großbritannien. Über 8000 Kandidaten haben in weniger als vier Jahren an der Prüfung zum Softwaretester teilgenommen. Das Programm hat den Status des Softwaretestens und die Anerkennung, die man Softwaretestern entgegenbringt, deutlich gehoben. Auf dem britischen Arbeitsmarkt wird man inzwischen ohne das Zertifikat in der Regel gar nicht erst zu einem Vorstellungsgespräch als Softwaretester eingeladen.

Wie sieht die zukünftige Entwicklung aus? Das International Software Testing Qualification Board (ISTQB) wurde 2002 gegründet, so dass Akkreditierung und Prüfung auf Foundation Level bald in allen angeschlossenen Ländern durchweg von unabhängigen Gremien vorgenommen werden. Softwaretester auf der ganzen Welt werden sich besser verständigen können und anerkannter sein. Dieses Buch wird für deutschsprachige Länder einen wichtigen Beitrag dazu leisten. Das internationale Zertifikat wird weltweit Grundkenntnisse im Bereich Softwaretesten sichern. Dies ist eine spannende Zeit für das Softwaretesten!

Dorothy Graham

Macclesfield, UK

June 2002

1 Einleitung

Software ist allgegenwärtig! Es gibt kaum noch Geräte, Maschinen oder Anlagen, in denen die Steuerung nicht über Software bzw. Softwareanteile realisiert wird. So sind im Automobil wesentliche Funktionen wie die Motor- oder Getriebesteuerung seit Langem durch Software realisiert. Hinzu kommen immer intelligentere softwarebasierte Fahrerassistenzsysteme, vom Bremsassistenten über die automatische Einparkhilfe oder Spurassistenten bis zum vollständig autonom fahrenden Fahrzeug. Die Software – und besonders deren Qualität – trägt somit ganz entscheidend nicht nur zum Funktionieren unserer Welt bei, sondern definiert zunehmend auch unsere Sicherheit.

Ebenso ist der reibungslose Geschäftsablauf in Firmen und Organisationen heute weitgehend von der Zuverlässigkeit der Softwaresysteme abhängig, die zur Abwicklung der Geschäftsprozesse oder einzelner Aufgaben eingesetzt werden. Software entscheidet damit auch über die künftige Wettbewerbsfähigkeit der Unternehmen. Wie schnell beispielsweise ein Versicherungskonzern ein neues Produkt oder auch nur einen neuen Tarif am Markt einführen kann, ist heutzutage davon abhängig, wie schnell die konzerneigenen IT-Systeme entsprechend angepasst oder ausgebaut werden können.

Hohe Abhängigkeit vom reibungslosen Funktionieren der Software

In beiden Bereichen (technische und kommerzielle Softwaresysteme) ist die Qualität der Software damit zum entscheidenden Faktor für den Erfolg von Produkten und Unternehmen geworden.

Die meisten Unternehmen haben diese hohe Abhängigkeit von Software – sowohl vom Funktionieren der vorhandenen als auch von der schnellen Verfügbarkeit neuer oder besserer Software – erkannt. Sie investieren daher in ihre Softwareentwicklungskompetenz und in eine verbesserte Qualität ihrer Softwaresysteme. Ein wichtiges Mittel, dies zu erreichen, ist das systematische Prüfen und Testen der entwickelten Software. Teilweise haben sehr umfassende und rigide Verfahren Einzug in die Praxis der Softwareentwicklung gefunden. In vielen Projekten ist aber weiterhin ein erheblicher Bedarf an Wissensvermittlung zu Prüf- und Testverfahren und deren Leistungsfähigkeit und Nutzen erforderlich.

Grundlagenwissen zum strukturierten Prüfen und Testen

Mit diesem Buch stellen wir Grundlagenwissen bereit, das bei entsprechender Umsetzung zu einem strukturierten, systematischen Vorgehen beim Prüfen und Testen führt und somit zur Qualitätsverbesserung der Software beiträgt. Der Inhalt des Buches ist so abgefasst, dass kein Vorwissen im Bereich der Softwarequalitätssicherung vorausgesetzt wird. Das Buch ist als Lehrbuch konzipiert und auch zum Selbststudium geeignet. Ein durchgängiges Fallbeispiel hilft, jedes dargestellte Thema und seine praktische Umsetzung schnell zu verstehen.

Ansprechen möchten wir Softwaretester1 in allen Unternehmen und Organisationen, die ihre Softwaretestkenntnisse auf eine fundierte Grundlage stellen wollen, Programmierer und Entwickler, die Testaufgaben übernommen haben bzw. übernehmen werden, aber auch Softwaremanager, die in den Projekten über Verbesserungsmaßnahmen und Budgets entscheiden. Auch Quereinsteiger in entwicklungsnahen IT-Berufen und Mitarbeiter in Fachabteilungen, die an der Abnahme, Einführung oder Weiterentwicklung von IT-Anwendungen beteiligt sind, werden Hilfestellung für ihre tägliche Arbeit finden.

Das lebenslange Lernen ist besonders im IT-Bereich unverzichtbar. Auch zum Thema Softwaretest werden Weiterbildungsmaßnahmen von vielen Firmen und Trainern angeboten. Ebenso werden an immer mehr Hochschulen Lehrveranstaltungen zu diesem Thema durchgeführt. Das Buch soll Lernende und Lehrende im gleichen Maße ansprechen.

Zertifizierungsprogramm für Softwaretester

Der weltweite Standard für die Aus- und Weiterbildung im Bereich Software-Qualitätssicherung und Softwaretest ist heute das »ISTQB® Certified Tester «-Schema des International Software Testing Qualifications Board (ISTQB®). Das ISTQB® [URL: ISTQB] koordiniert die nationalen Initiativen und sorgt für die Einheitlichkeit und Vergleichbarkeit der Lehr- und Prüfungsinhalte unter den beteiligten Ländern. Die nationalen Testing Boards sind zuständig für die Herausgabe und Pflege landessprachlicher Lehrpläne und für die Definition und Durchführung von Prüfungen in ihren jeweiligen Ländern. Sie überprüfen die im jeweiligen Land angebotenen Kurse nach definierten Qualitätskriterien und sprechen Akkreditierungen der Trainingsanbieter aus. Die Testing Boards gewährleisten damit einen hohen Qualitätsstandard der Kurse, und die Kursteilnehmer erhalten mit bestandener Prüfung einen international anerkannten Qualifikationsnachweis. Die entsprechenden Gremien im deutschsprachigen Raum sind das Austrian Testing Board [URL: ATB], das German Testing Board [URL: GTB] und das Swiss Testing Board [URL: CHTB]. In diesen Gremien sind Trainingsanbieter, Testexperten aus Industrie- und Beratungsunternehmen sowie Hochschullehrende organisiert. Wichtige Kompetenz bringen weiterhin Vertreter verschiedener Fachverbände ein. So arbeiten im GTB u.a. Mitglieder der Fachgruppe TAV (Test, Analyse und Verifikation von Software) [URL: GI TAV] der Gesellschaft für Informatik e.V. (GI e.V.) mit.

Dreistufiges Qualifizierungsschema

Das »Certified Tester «-Ausbildungsschema gliedert sich in Säulen mit jeweils drei Ausbildungsstufen. Details dazu finden sich auf der Webseite des ISTQB® [URL: ISTQB] und des GTB [URL: GTB]. Die Grundlagen zum Softwaretest sind im Lehrplan zum »Foundation Level« beschrieben. Darauf aufbauend kann das Zertifikat zum »Advanced Level« [URL: GTB Lehrpläne] erworben werden, um vertiefte Kenntnisse im Prüfen und Testen nachzuweisen. Die dritte Stufe, das »Expert Level «-Zertifikat, richtet sich an erfahrene, professionelle Softwaretester und besteht aus einer Reihe von Modulen zu unterschiedlichen Spezialthemen (s.a. Abschnitt 6.1.2).

Der Inhalt des Buches deckt den Stoff des Zertifikats »Foundation Level« ab. Das prüfungsrelevante Fachwissen kann im Selbststudium erworben oder nach bzw. parallel zu einer Teilnahme an einem Kurs vertieft werden.

Kapitelübersicht

Die Themen des Buches und somit auch die grobe Struktur der Inhalte der Kurse zum Erwerb des »Foundation Certificate« sind im Folgenden beschrieben.

Grundlagen des Softwaretestens

In Kapitel 2 werden die Grundlagen des Softwaretestens erörtert. Neben der Motivation, wann, mit welchen Zielen und wie intensiv getestet werden soll, wird das Konzept eines grundlegenden Testprozesses beschrieben. Es wird auf die psychologischen Schwierigkeiten eingegangen, die entstehen, wenn beim Test der eigenen Software die selbst verursachten Fehler nachgewiesen werden sollen.

Testen im Softwarelebenszyklus

Kapitel 3 stellt in der Softwareentwicklung gebräuchliche Lebenszyklusmodelle (sequenziell, iterativ, inkrementell, agil) knapp vor und erläutert, welche Rolle das Testen im jeweiligen Modell spielt. Die verschiedenen Teststufen und Testarten werden erklärt und auf die Unterschiede beim funktionalen und nicht funktionalen Test eingegangen. Das Thema Regressionstest wird ebenfalls angesprochen.

Statischer Test

Statische Verfahren, d.h. Verfahren, bei denen das Testobjekt nicht zur Ausführung kommt, werden in Kapitel 4 vorgestellt. Reviews und statische Tests werden bereits in vielen Unternehmen mit gutem Erfolg angewendet. Die unterschiedlichen Vorgehensweisen werden ausführlich beschrieben.

Dynamischer Test

Das Kapitel 5 behandelt den Test im engeren Sinne. Die Klassifizierung der dynamischen Testverfahren in »Blackbox«- und » White- box «-Verfahren wird erörtert. Zu jeder Klasse werden unterschiedliche Testverfahren bzw. -methoden an Beispielen ausführlich erklärt. Auf die sinnvolle Verwendung des erfahrungsbasierten bzw. intuitiven Tests, nämlich in Ergänzung zu den anderen Verfahren, wird am Ende des Kapitels eingegangen.

Testmanagement

Welche Organisationsformen und Aufgaben beim Testmanagement zu berücksichtigen sind, wird in Kapitel 6 diskutiert. Behandelt werden auch Anforderungen an Fehlerverfolgung und Konfigurationsmanagement sowie das Thema Wirtschaftlichkeit des Testens.

Testwerkzeuge

Testen von Software ist ohne Werkzeugunterstützung sehr arbeits- und zeitintensiv. Im letzten Kapitel des Buches (Kap. 7) werden unterschiedliche Klassen von Werkzeugen zur Testunterstützung vorgestellt und Hinweise zur Werkzeugauswahl und Werkzeugeinführung gegeben.

Fallbeispiel »VirtualShowRoom – VSR-II«

Die in diesem Buch vorgestellten Vorgehensweisen beim Testen von Software werden größtenteils anhand eines durchgängigen Fallbeispiels veranschaulicht. Das folgende Szenario liegt diesem Beispiel zugrunde:

Ein Automobilkonzern betreibt seit mehr als zehn Jahren ein elektronisches Verkaufssystem, genannt VirtualShowRoom (VSR). Dieses Softwaresystem ist weltweit bei allen Autohändlern der Marke installiert und in Betrieb:

Ein Kunde, der ein Fahrzeug erwerben möchte, kann unterstützt durch einen Verkäufer oder selbstständig sein Wunschfahrzeug am Bildschirm konfigurieren (Modellauswahl, Farbe, Ausstattung usw.). Das System zeigt mögliche Modelle und Ausstattungsvarianten an und ermittelt zu jeder Auswahl sofort den jeweiligen Listenpreis. Diese Funktionalität wird vom Teilsystem

DreamCar

realisiert.

Hat sich der Kunde für ein Fahrzeug entschieden, kann er am Bildschirm mit

EasyFinance

die für ihn optimale Finanzierung kalkulieren, mit

JustInTime

das Fahrzeug online bestellen und mittels

NoRisk

auch die passende Versicherung abschließen. Das Teilsystem

FactBook

schließlich verwaltet sämtliche Kundeninformationen und Vertragsdaten.

Der Konzernbereich Marketing und Vertrieb hat entschieden, dass das System modernisiert werden soll und die folgenden Projektziele definiert:

VSR ist ein klassisches Client-Server-System. Das neue System VSR-II soll ein webbasiertes System sein, das auf beliebigen Geräten (Desktop, Tablet, Smartphone) über Browser genutzt werden kann.

Jedes der bisherigen Teilsysteme

DreamCar, EasyFinance, FactBook, JustInTime, NoRisk

wird auf die neue Technologie portiert und in diesem Zuge auch (in unterschiedlichem Umfang) funktional erweitert.

Als neues System ist das Teilsystem

ConnectedCar

anzubinden. Dieses System ermittelt und verwaltet Statusinformationen aller verkauften Fahrzeuge und gibt dem Fahrer aber auch dem Händler oder Servicepartner Informationen über anstehende Wartungs- und Reparaturarbeiten. Außerdem bietet es dem Fahrer verschiedene buchbare Services (wie Helpdesk, Notruf etc.). Auch Softwareupdates für das Fahrzeug können »Over the air« eingespielt und freigeschaltet werden.

Jedes der fünf alten Teilsysteme wird von einem eigenen Entwicklungsteam separat portiert und weiterentwickelt. Ein weiteres Team kümmert sich um die Neuentwicklung von

ConnectedCar.

Insgesamt sind rund 60 Entwickler und weitere Mitarbeiter aus den jeweils betroffenen konzerninternen Fachabteilungen an dem Projekt beteiligt sowie externe Softwarefirmen.

Die Teams arbeiten agil nach Scrum. Im Rahmen der agilen Entwicklung soll jedes Teilsystem während der Iterationen getestet werden. Die Auslieferung des Systems erfolgt in Inkrementen.

Um einen komplizierten mehrfachen Abgleich von Daten zwischen Altsystem und Neusystem zu vermeiden, ist vorgesehen, dass VSR-II erst dann erstmalig produktiv in Betrieb geht, wenn die Funktionalität des alten VSR erreicht ist.

Im Rahmen des Projekts und des agilen Vorgehens werden die meisten Projektmitarbeiter in unterschiedlichem Umfang mit Testarbeiten konfrontiert oder betraut werden. Das Grundlagenwissen über Testtechniken und Vorgehensweisen, das sie dazu benötigen, wird in diesem Buch vermittelt. Abbildung 1–1 zeigt das neue System VSR-II in der Übersicht.

Abb. 1–1VSR-II in der Übersicht

Hinweise zu Lehrstoff und Prüfung

Im Anhang werden wichtige Hinweise zum Lehrstoff und zur Prüfung zum Certified Tester gegeben. Weitere Anhänge des Buches beinhalten ein Glossar und das Quellenverzeichnis. Textpassagen, die über den Stoff des Lehrplans hinausgehen, sind als »Exkurs« gekennzeichnet.

WWW-Seite zum Buch

Unter [URL: Softwaretest Knowledge] finden sich neben Übungsaufgaben zu den einzelnen Buchkapiteln weitere und aktuelle Informationen zum Buch wie auch zu anderen Büchern der Autoren, die das Certified-Tester-Ausbildungsschema ergänzen.

2 Grundlagen des Softwaretestens

Dieses einleitende Kapitel erklärt die Grundbegriffe des Softwaretestens, die in den weiteren Kapiteln vorausgesetzt werden. Wichtige Begriffe werden zusätzlich an dem praxisnahen Fallbeispiel VSR-II-System veranschaulicht, das im gesamten Buch immer wieder zur Illustration und Motivation des Lehrstoffs verwendet wird. Die sieben Grundsätze des Testens werden vorgestellt. Hauptteil des Kapitels ist der Testprozess, der mit seinen einzelnen Aktivitäten detailliert erläutert wird. Am Ende des Kapitels wird auf psychologische Probleme beim Testen eingegangen und wie diese umgangen bzw. verringert werden können.

2.1 Begriffe und Motivation

Anforderungen an die Qualität

Bei der Herstellung eines Industrieprodukts werden die entstehenden Produkte üblicherweise daraufhin kontrolliert, ob sie den gestellten Anforderungen entsprechen. Es wird meist durch Stichproben geprüft, ob das Produkt die geforderte Aufgabe löst. Je nach Produkt gibt es auch unterschiedliche Anforderungen an die Qualität der Lösung. Erweist sich ein Produkt als fehlerhaft, so müssen ggf. Korrekturen im Produktionsprozess oder in der Konstruktion erfolgen.

Software ist immateriell.

Was allgemein für die Herstellung eines Industrieprodukts gilt, trifft entsprechend für die Produktion bzw. Entwicklung von Software zu. Die Prüfung der Teilprodukte bzw. des Endprodukts gestaltet sich allerdings schwieriger, da die erstellte Software immateriell ist und daher nicht »greifbar« und eine Prüfung deshalb nicht »handfest« durchgeführt werden kann. Eine optische Prüfung ist nur sehr eingeschränkt durch intensives Lesen der Entwicklungsdokumente möglich.

Fehlerhafte Software führt zu Problemen.

Software, die unzuverlässig oder inkorrekt arbeitet, kann zu erheblichen Problemen führen. Hierzu gehören der Verlust von Geld und Zeit, die Schädigung des Geschäftsrufs bis hin zu Verletzungen von Personen oder sogar deren Tod. Beispiele für gravierende Softwarefehler finden sich oft in der aktuellen Tagespresse, wenn etwa die »Autopilot«-Software eines teilautonom fahrenden Autos fehlerhaft ist und zu spät oder falsch reagiert.

Testen liefert eine Einschätzung der Qualität.

Es ist daher wichtig, die Qualität der Software zu prüfen, um das Risiko eines Softwareausfalls oder eines Softwarefehlers zu minimieren. Das Testen von Software liefert eine Einschätzung der Qualität und verringert die Risiken beim Einsatz der Software, da mögliche Fehler während des Testens aufgedeckt werden können. Dem Testen von Software kommt somit eine sehr wichtige, aber auch sehr schwierige Aufgabe zu.

Beispiel: Risiko durch Softwarefehler

Jedes Release des VSR-II-Systems unseres Fallbeispiels muss vor Auslieferung und Einsatz angemessen geprüft werden, um mögliche Fehler vorab zu erkennen und beheben zu können. Führt das System beispielsweise Bestellvorgänge falsch aus, könnte dies für Kunden und Händler, aber auch für den Autokonzern unter Umständen einen großen finanziellen Schaden und/oder Imageverlust zur Folge haben. Jedenfalls birgt die Nichterkennung eines solchen Fehlers ein hohes Risiko beim Einsatz der Software.

Testen ist eine stichprobenhafte Prüfung.

Oft wird unter Testen die (im Allgemeinen stichprobenartige) Ausführung1 der zu prüfenden Software (Testobjekt) auf einem Rechner verstanden. Dazu werden einzelne Testfälle ausgeführt, d.h., das Testobjekt wird mit Testdaten versehen und ausgeführt. Die anschließende Bewertung prüft, ob das Testobjekt die geforderten Eigenschaften erfüllt und sich konform zu den Anforderungen verhält.2

Testen ist mehr als die Ausführung von Testfällen auf dem Rechner.

Zum Testen gehört aber weit mehr als die Ausführung von Testfällen. Software zu testen ist ein Prozess – der Testprozess, der unterschiedliche Aktivitäten umfasst. Die Testdurchführung, inklusive der Prüfung der Ergebnisse, ist nur eine der Aktivitäten. Weitere Aktivitäten im Testprozess sind die Testplanung, die Analyse, das Design und die Realisierung von Tests. Die Anfertigung von Berichten über den Testfortschritt und über die Testergebnisse sowie die Beurteilung der Qualität eines Testobjekts und die Risikobewertung sind zusätzliche Aufgaben. Die Testaktivitäten werden je nach Lebenszyklus der Software unterschiedlich organisiert und durchgeführt. Testaktivitäten und Testdokumentation werden häufig vertraglich zwischen Auftraggeber und Auftragnehmer oder durch gesetzliche oder Firmenstandards festgelegt. Eine detaillierte Beschreibung der einzelnen Aktivitäten im Testprozess folgt in Abschnitt 2.3 und in Abschnitt 6.3.

Statisches und dynamisches Testen

Neben den Tests, die auf dem Rechner ausgeführt werden (dynamische Test, s. Kap. 5), können und sollen auch Dokumente wie Anforderungsspezifikation, User Stories und Quellcode so früh wie möglich einer Prüfung unterzogen werden. Derartige Tests werden statische Tests (s. Kap. 4) genannt. Je früher Fehler in den Dokumenten gefunden und behoben werden, je besser ist es für die weitere Entwicklung der Software, da nicht mit fehlerbehafteten Dokumenten weitergearbeitet wird.

Verifizierung und Validierung

Testen umfasst aber nicht nur die Prüfung, ob sich das System entsprechend den Anforderungen, User Stories oder anderen Spezifikationen verhält, sondern auch die Prüfung, ob sich das System entsprechend den Vorstellungen und Wünschen der Nutzer bzw. Anwender in der Betriebsumgebung verhält, ob die beabsichtigte Nutzung möglich ist bzw. das System seinen Zweck erfüllt. Testen beinhaltet somit auch die Validierung (s.a. 7. Grundsatz: Trugschluss: Keine Fehler bedeutet ein brauchbares System in Abschnitt 2.1.6).

Kein umfangreiches System ist fehlerfrei.

Ein fehlerfreies Softwaresystem gibt es derzeit nicht und wird es in naher Zukunft wahrscheinlich auch nicht geben, sobald das System einen gewissen Grad an Komplexität und Umfang an Programmzeilen umfasst. Häufig liegt ein Fehler darin begründet, dass sowohl während der Entwicklung als auch beim Testen der Software gewisse Ausnahmesituationen nicht bedacht bzw. nicht überprüft wurden. Sei es das Schaltjahr, das nicht richtig berechnet wird, oder die nicht berücksichtigten Randbedingungen, wenn es um Zeitverhalten oder Ressourcenbedarf geht. Es ist daher durchaus üblich – oder oft auch unumgänglich – dass Software und Systeme in Betrieb genommen werden, obwohl Fehler bei bestimmten Eingabekonstellationen auftreten. Auf der anderen Seite arbeiten aber sehr viele Softwaresysteme in ganz unterschiedlichen Bereichen zuverlässig tagein, tagaus.

Fehlerfreiheit nicht durch Testen erreichbar

Selbst wenn alle ausgeführten Tests keinen einzigen Fehler mehr aufdecken, kann (außer bei sehr sehr kleinen Programmen) nicht ausgeschlossen werden, dass es zusätzliche Tests gibt, die weitere Fehler aufzeigen würden. Fehlerfreiheit kann mit Testen nicht nachgewiesen werden.

2.1.1 Fehlerbegriff

Testbasis als Grundlage

Eine Situation kann nur dann als fehlerhaft eingestuft werden, wenn vorab festgelegt wurde, wie die erwartete bzw. als korrekt spezifizierte Situation aussehen soll. Zur Bestimmung der korrekten Situation werden die Anforderungen an das zu testende System(teil), aber auch weitere Informationen herangezogen. In diesem Zusammenhang wird von der Testbasis gesprochen, gegen die getestet wird und die als Grundlage der Entscheidung dient, ob ein korrektes oder fehlerhaftes Verhalten vorliegt.

Was gilt als Fehler?

Ein Fehler ist somit die Nichterfüllung einer festgelegten Anforderung, eine Abweichung zwischen dem Istverhalten (während der Ausführung der Tests oder des Betriebs festgestellt) und dem Sollverhalten (in der Spezifikation, den Anforderungen oder den User Stories festgelegt). Wann liegt aber ein nicht anforderungskonformes Verhalten des Systems vor?

Im Gegensatz zu physischen Systemen entstehen Fehler in einem Softwaresystem nicht durch Alterung oder Verschleiß. Jeder Fehler ist seit dem Zeitpunkt der Entwicklung in der Software vorhanden. Er kommt jedoch erst bei der Ausführung der Software zum Tragen.

Fehlerwirkung

Für diesen Sachverhalt wird der Begriff Fehlerwirkung verwendet. Der englische Fachbegriff hierfür lautet »Failure«. Weitere Bezeichnungen sind Fehlfunktion, äußerer Fehler oder Ausfall. Beim Test der Software oder auch erst bei deren Betrieb wird eine Fehlerwirkung für den Tester oder Anwender nach außen sichtbar. Zum Beispiel ist ein Ausgabewert falsch oder das Programm stürzt ab.

Fehlerzustand

Zwischen dem Auftreten einer Fehlerwirkung und deren Ursache muss unterschieden werden. Eine Fehlerwirkung hat ihren Ursprung in einem Fehlerzustand (»Fault«) der Software. Dieser Fehlerzustand wird auch als Defekt oder innerer Fehler bezeichnet. Auch das englische Wort »Bug« ist gebräuchlich. Dies ist beispielsweise eine falsch programmierte oder vergessene Anweisung im Programm.

Fehlermaskierung

Es ist durchaus möglich, dass ein Fehlerzustand durch einen oder mehrere andere Fehlerzustände in anderen Teilen des Programms kompensiert wird (Fehlermaskierung). Eine Fehlerwirkung tritt in diesem Fall erst dann zutage, nachdem der oder die maskierenden Fehlerzustände korrigiert worden sind. Korrekturen können somit zu Seiteneffekten führen.

Ein Problem ist, dass ein Fehlerzustand nicht zu einer Fehlerwirkung führen muss. Eine Fehlerwirkung kann gar nicht, einmal oder immer und somit für alle Benutzer des Systems auftreten. Eine Fehlerwirkung kann weit entfernt vom Fehlerzustand zum Tragen kommen. Ein Beispiel ist eine kleine Verfälschung von gespeicherten Daten, die bei der Programmausführung erst zu einem späteren Zeitpunkt aufgedeckt wird.

Fehlhandlung

Ursache für das Vorliegen eines Fehlerzustands ist wiederum die vorausgegangene Fehlhandlung einer Person, wie z.B. eine fehlerhafte Programmierung durch den Entwickler. Der englische Begriff hierfür ist »Error«.

Fehlhandlungen können aus vielfältigen Gründen entstehen. Einige typische Fehlhandlungen bzw. Gründe (bzw. Grundursache) für Fehlhandlungen sind:

Menschen machen Fehler – wir alle!

Ein hoher Zeitdruck ist vorhanden – was in Softwareprojekten sehr häufig vorkommt.

Die Komplexität der umzusetzenden Aufgabe, der Architektur, des Designs sowie des Programmtextes ist sehr hoch.

Es gibt Missverständnisse zwischen den Projektbeteiligten – oft ein unterschiedliches Verständnis bzw. eine Auslegung der Anforderungen und weiterer Dokumente.

Es gibt Missverständnisse über die Systeminteraktionen (systeminterne und systemübergreifende Schnittstellen), da deren Anzahl bei größeren Systemen oft sehr hoch ist.

Die Komplexität der genutzten Technologien ist hoch oder es werden neue, bei den Projektbeteiligten (noch) unbekannte Technologien verwendet, die noch nicht richtig verstanden und daher falsch angewendet werden.

Es liegt Unerfahrenheit oder unzureichende Ausbildung bei den Projektbeteiligten vor.

Eine Fehlhandlung einer Person führt zu einem Fehlerzustand in einem Programmstück, was zu einer Fehlerwirkung führt, die außen sichtbar ist und durch Testen aufgezeigt werden soll (s. Abb. 2–1, Debugging s.u.). Statische Tests (s. Kap. 4) können im Programmtext direkt Fehlerzustände aufdecken.

Fehlerwirkungen können aber auch durch Umweltbedingungen ausgelöst werden, wie Strahlung, Magnetismus etc., oder auch durch Umweltverschmutzung mit den entsprechenden Auswirkungen auf die Firmware und Hardware. Diese Art Fehler wird hier nicht behandelt.

Abb. 2–1Zusammenhang zwischen Fehlhandlung, Fehlerzustand und Fehlerwirkung

Falsch positives Ergebnis und falsch negatives Ergebnis

Nicht jedes unerwartete Ergebnis der Tests ist auch immer eine Fehlerwirkung. Es kann vorkommen, dass ein Testergebnis eine Fehlerwirkung anzeigt, obwohl der Fehlerzustand bzw. die Ursache für die Fehlerwirkung nicht im Testobjekt liegt. Dies wird als »falsch positives Ergebnis« (»false-positive Result«) bezeichnet. Die umgekehrte Situation kann ebenfalls vorkommen, dass Fehlerwirkungen nicht auftreten, obwohl die Tests diese hätten aufdecken sollen. Dies wird als »falsch negatives Ergebnis« (»false-negative Result«) bezeichnet. Bei jeder Auswertung von Testergebnissen ist somit zu beachten, ob eine der beiden Möglichkeiten vorliegt. Es gibt noch zwei weitere Ergebnisse: »richtig positiv« (Fehlerwirkung durch den Testfall aufgedeckt) und »richtig negativ« (erwartetes Verhalten bzw. Ergebnis des Testobjekts mit dem Testfall nachgewiesen). Nähere Ausführungen hierzu finden sich in Abschnitt 6.4.1.

Aus Fehlern lernen

Konnten Fehlerzustände aufgedeckt und die Fehlhandlungen ermittelt werden, die zu den Fehlerzuständen führten, dann lohnt es sich, mögliche Ursachen zu analysieren, um daraus zu lernen und in Zukunft gleiche oder ähnliche Fehlhandlungen zu vermeiden. Die so gewonnenen Erkenntnisse können zur Prozessverbesserung genutzt werden, um das Auftreten von zukünftigen Fehlhandlungen und damit Fehlerzuständen zu verringern oder zu verhindern.

Beispiel: Unklare Anforderung als Ursache von Softwarefehlern

Über das Teilsystem VSR-II-EasyFinance kann sich der Kunde verschiedene Optionen zur Finanzierung seines neuen Fahrzeugs berechnen und vorschlagen lassen. Der bei einer Kreditfinanzierung vom System verwendete Zinssatz wird aus einer im System hinterlegten Zinssatztabelle entnommen. Für Fahrzeuge, die im Rahmen von werblichen Sonderaktionen angeboten und verkauft werden, können davon abweichend andere Zinssätze gelten.

Im neuen VSR-II soll zusätzlich folgende Anforderung realisiert werden: REQ: Wenn der Kunde der »Online-Bonitätsprüfung« zugestimmt und diese absolviert hat, dann reduziert VSR-II-EasyFinance den Kreditzinssatz gemäß der im System hinterlegten Zinssatz-Bonus-Tabelle.

Der Autor der Anforderung hat allerdings vergessen klarzustellen, dass diese Reduktion nicht erlaubt ist, wenn es um ein Fahrzeug geht, das in einer Sonderaktion verkauft wird. Entsprechend wurde dieser Fall in den Tests des ersten Release nicht überprüft. Kunden aus Sonderaktionen erhielten daher online Kreditangebote mit zu niedrigem Zinssatz angeboten und beschwerten sich, als die erste Kreditabrechnung einen höheren Zinssatz auswies.

2.1.2 Testbegriff

Testen ist nicht Debugging.

Um einen Fehlerzustand korrigieren zu können, muss der Fehlerzustand im Softwareprodukt lokalisiert werden. Bekannt ist zunächst nur seine Wirkung, aber nicht die genaue Stelle in der Software, die den Fehlerzustand beinhaltet. Das Lokalisieren und Beheben des Fehlerzustands ist Aufgabe des Softwareentwicklers und wird auch als »Debugging« (Fehlerbereinigung, Fehlerkorrektur) bezeichnet. Debugging und Testen werden oft gleichgesetzt, sind aber zwei völlig unterschiedliche und getrennte Aufgaben. Während Debugging das Ziel hat, Defekte bzw. Fehlerzustände zu lokalisieren, ist es Aufgabe des Tests, Fehlerwirkungen-gezielt aufzudecken (s.a. Abb. 2–1).

Fehlernachtest

Die Behebung des Fehlerzustands führt zur Qualitätsverbesserung des Produkts, da in den meisten Fällen keine neuen Fehlerzustände durch die Änderung hinzugefügt werden. Tests, die prüfen, ob die Korrekturmaßnahmen erfolgreich waren, werden als Fehlernachtests bezeichnet. Oft sind Tester für diese Fehlernachtests verantwortlich, während Softwareentwickler neben dem Debugging auch die zugehörigen Komponententests durchführen. In der agilen Entwicklung und in einigen anderen Lebenszyklen kann diese Aufgabentrennung aufgehoben sein.

In der Praxis kommt es aber leider vor, dass durch die Korrektur eines Fehlerzustands ein oder sogar mehrere neue Fehlerzustände »hineinprogrammiert« werden. Der neue Fehlerzustand kann dann bei einer ganz anderen Eingabekonstellation zur Wirkung kommen. Solche unbeabsichtigten Seiteneffekte erschweren den Test und bedingen, dass nach Änderungen nicht nur die Tests zu wiederholen sind, die den Fehlerzustand zur Wirkung gebracht haben, sondern auch weitere Tests, die mögliche Seiteneffekte aufdecken könnten.

Testziele

Testen – und hier sind sowohl statisches als auch dynamisches Testen gemeint – verfolgt mehrere Ziele:

Die qualitative Bewertung von Arbeitsergebnissen wie Anforderungsspezifikation, User Stories, Design und Programmtext

Der Nachweis, dass alle spezifischen Anforderungen vollständig umgesetzt sind und dass das Testobjekt so funktioniert, wie es die Nutzer und andere Interessenvertreter (Stakeholder) erwarten

Informationen zur Verfügung stellen, damit die Stakeholder die Qualität des Testobjekts fundiert einschätzen können und somit Vertrauen in die Qualität des Testobjekts schaffen

3

Die Höhe des Risikos bei mangelnder Qualität der Software kann durch Aufdeckung (und Behebung) von Fehlerwirkungen verringert werden. Die eingesetzte Software enthält dann weniger unentdeckte Fehlerzustände.

Analysieren des Programms und der Dokumente, um Fehlerzustände zu vermeiden und vorhandene zu erkennen (und dann zu beheben)

Analysieren und Ausführen des Programms mit dem Ziel, Fehlerwirkungen nachzuweisen

Informationen über das Testobjekt zu erhalten, um zu entscheiden, ob das Systemteil für die Integration mit weiteren Systemteilen freigegeben (einchecken, »commit«) werden kann

Aufzeigen, dass das Testobjekt konform zu vertraglichen, rechtlichen oder regulatorischen Anforderungen oder Standards ist und/oder Überprüfung der Einhaltung der Anforderungen oder Standards durch das Testobjekt

Ziele abhängig vom Kontext

Abhängig vom Kontext können die Ziele des Testens variieren. Je nach Softwareentwicklungsmodell (z.B. agil oder konventionell) und Teststufe (Komponententest, Integrationstest, Systemtest, Abnahmetest, s. Abschnitt 3.4) können unterschiedliche Ziele verfolgt werden.

So steht beim Test einer Komponente im Vordergrund, möglichst viele Fehlerwirkungen aufzudecken, um die zugrunde liegenden Fehlerzustände frühzeitig zu identifizieren (»Debugging«) und zu beheben. Ein weiteres Ziel kann es sein, die Tests so zu wählen, dass die erreichte Überdeckung des Programmtexts (s. Abschnitt 2.3.1) möglichst hoch ist.

Ein Ziel des Abnahmetests ist der Nachweis, dass das System sowohl wie erwartet benutzt werden kann als auch wie erwartet arbeitet und somit die nicht funktionalen und funktionalen Anforderungen erfüllt. Ein weiteres Ziel ist die Bereitstellung von Informationen über das Risiko einer Systemfreigabe für die Stakeholder, damit sie eine fundierte Entscheidung über die Freigabe (ja oder nein) treffen können.

Exkurs: Benennung von Tests

Es gibt verwirrend viele Bezeichnungen für verschiedene Arten von Softwaretests. Einige werden im Rahmen der Darstellung der verschiedenen Teststufen (s. Abschnitt 3.4) genauer erklärt. Dieser Exkurs soll etwas Systematik in die Begriffsvielfalt bringen. Dazu ist es hilfreich, folgende Kategorien, nach denen Tests bezeichnet werden können, zu unterscheiden:

Testziel

Die Benennung einer Testart erfolgt aufgrund des Testzwecks (z.B. Lasttest).

Testmethode/Testverfahren

Der Test wird nach der Methode/dem Verfahren benannt, die zur Spezifikation oder Durchführung der Tests eingesetzt wird (z.B. zustandsbasierter Test, s. Abschnitt 5.1.3).

Testobjekt

Der Test wird nach der Art des Testobjekts, das getestet wird, benannt (z.B. GUI-Test – Test der grafischen Bedienoberfläche oder DB-Test – Test der Datenbank).

Teststufe

Der Test wird nach der Stufe des zugrunde liegenden Softwareentwicklungsmodells benannt (z.B. Systemtest).

Testperson

Der Test wird nach dem Personenkreis bezeichnet, der die Tests durchführt (z.B. Entwicklertest, Anwendertest).

Testumfang

Tests werden nach dem Umfang unterschieden (z.B. partieller Regressionstest).

Nicht hinter jedem Begriff verbirgt sich also eine neue oder andere Art von Test. Vielmehr wird, je nachdem unter welchem Blickwinkel die Testarbeiten betrachtet werden, einer der aufgeführten Aspekte in den Vordergrund gerückt.

2.1.3 Testartefakte und ihre Beziehungen

In den vorherigen Abschnitten wurden bereits einzelne Artefakte beim Testen genannt und kurz erklärt. Im Folgenden wird ein Überblick über die beim dynamischen Testen erforderlichen bzw. zu erstellenden Artefakte gegeben.

Testbasis

Grundlage für alle Überlegungen zum Testen ist die Testbasis. Wie oben bereits erwähnt, werden alle Dokumente als Testbasis bezeichnet, die herangezogen werden können, um eine Entscheidung treffen zu können, ob beim Testen eine Fehlerwirkung aufgetreten ist oder nicht. Die Testbasis legt somit das Sollverhalten des Testobjekts fest. Aber auch der gesunde Menschenverstand oder Fachwissen können als »Teile« der Testbasis angesehen und für die Entscheidung herangezogen werden. In den meisten Fällen liegt ein Anforderungsdokument, eine Spezifikation oder eine User Story vor, die als Testbasis dient.

Testfall und Testlauf

Auf Grundlage der Testbasis werden die Testfälle erstellt. Ein Testfall wird auf dem Rechner ausgeführt, d.h., das Testobjekt wird mit entsprechenden Testdaten versehen und zur Ausführung gebracht – ein Testlauf wird durchgeführt. Die Ergebnisse des Testlaufs werden geprüft und es wird entschieden, ob eine Fehlerwirkung vorliegt, also eine Abweichung zwischen erwartetem Sollergebnis bzw. Sollverhalten und dem sich nach dem Testlauf ergebenen Istergebnis bzw. Istverhalten. Um Testfälle ausführen zu können, sind meist Vorbedingungen einzuhalten, z.B. muss die zu verwendende Datenbank nutzbar und mit entsprechenden Daten gefüllt sein.

Testbedingung

Da jeder Testfall die Testbasis nicht als Ganzes prüfen kann, muss eine Fokussierung auf bestimmte Aspekte erfolgen. Aus der Testbasis sind sogenannte Testbedingungen4 abzuleiten, die für das Erreichen bestimmter Testziele (s.o.) relevant sind. Eine Testbedingung (»Test Condition«) ist durch ein oder mehrere Testfälle zu prüfen. Eine Testbedingung kann eine Funktion, eine Transaktion, ein Qualitätsmerkmal oder ein strukturelles Element einer Komponente oder eines Systems sein. Konkrete Beispiele für eine Testbedingung sind die Preisberechnung beim VSR-II-System, die Kombination der Fahrzeugmodelle (s. Abschnitt 5.1.5), das »Look and feel« der Benutzungsoberfläche oder das Antwortzeitverhalten des zu testenden Systems.

Testelement

Ebenso kann »auf der anderen Seite« ein Testobjekt in der Regel nicht als Ganzes getestet werden. Es werden sogenannte Testelemente ermittelt, die durch die einzelnen Testfälle getestet werden. Zur Testbedingung Preisberechnung beim VSR-II-System ist das entsprechende Testelement die Methode calculate_price() (s. Abschnitt 5.1.1), die mit den entsprechenden Testfällen getestet wird. Die Testfälle werden unter der Verwendung von Testverfahren (s. Kap. 5) spezifiziert.

Testsuite und Testausführungsplan

Testfälle einzeln auszuführen ist wenig sinnvoll. Testfälle werden in Testsuiten zusammengefasst, die in einem Testzyklus ausgeführt werden. Im Testausführungsplan ist der zeitliche Ablauf der Ausführung der Testsuiten festgelegt.

Testskript

Ein Testskript wird implementiert, das die Testsuite automatisiert ausführt. In den Testskripten ist die Reihenfolge der Testfälle mit allen erforderlichen Aktionen zur Herstellung der Vorbedingungen und zum Aufräumen nach der Durchführung realisiert. Werden Testsuiten nicht automatisiert durchgeführt, sind diese Informationen für den manuellen Test ebenfalls bereitzustellen (Testablauf, »Test Procedure«).

Protokoll

Die Ergebnisse der Testläufe sind zu protokollieren und zusammenfassend in einem Testbericht zu dokumentieren.

Testkonzept

Zu Beginn aller Überlegungen zum Testen eines Testobjekts ist ein Testkonzept zu erstellen, in dem alles festlegt wird, was für die Testdurchführung erforderlich ist (s. Abschnitt 6.2.1). Hierzu gehören u.a. die Auswahl der Testobjekte und Testverfahren, die Festlegung der Testziele und der Testberichterstattung ebenso wie die Koordination der einzelnen Testaktivitäten untereinander.

In der Abbildung 2–2 sind die Zusammenhänge zwischen den Artefakten dargestellt. Durch die Angabe der Aktivitäten des Testprozesses (s. Abschnitt 2.3) wird verdeutlicht, wann die Artefakte erstellt werden.

Abb. 2–2Testartefakte und ihre Beziehungen

2.1.4 Aufwand für das Testen

Testaufwand abhängig vom Projekt(umfeld)

Das Testen nimmt einen großen Teil des Entwicklungsaufwands in Anspruch, auch wenn immer nur ein Teil aller denkbaren Tests – genauer aller denkbaren Testfälle – berücksichtigt werden kann. Eine allgemein gültige Aussage oder Empfehlung über die Höhe des zu investierenden Testaufwands ist jedoch schwierig, da dies stark vom Charakter des Projekts abhängt.5

Der Stellenwert des Testens – und damit der mögliche Aufwand für das Testen – wird oft auch durch das Zahlenverhältnis von Testern zu Entwicklern deutlich. In der Praxis sind folgende Verhältnisse anzutreffen: von einem Tester, der auf zehn Entwickler kommt, bis hin zu drei Testern pro Entwickler. Der Testaufwand bzw. das für das Testen investierte Budget divergiert in der Praxis sehr stark.

Exkurs: Wann ist ein hoher Testaufwand vertretbar?

Ist ein hoher Testaufwand bezahlbar und gerechtfertigt? Die Gegenfrage von Jerry Weinberg lautet: »Im Vergleich zu was?« [DeMarco 93]. Er weist damit auf die zu bedenkenden Risiken bei fehlerhaften Softwaresystemen hin. Das Risiko wird aus der Eintrittswahrscheinlichkeit und der zu erwartenden Höhe des Schadens ermittelt. Im Test nicht gefundene Fehlerzustände können beim Einsatz der Software hohe Kosten verursachen.

Beispiel: Fehlerkosten

»Das mehrere hundert Millionen Euro teure Weltraumteleskop Hitomi geriet Ende März 2016 nach einer Verkettung von Softwarefehlern in zu schnelle Rotation und ging verloren. Die Software war fälschlicherweise von einer unerwünschten langsamen Rotation des Satelliten ausgegangen und versuchte, die scheinbare Drehung durch Gegenmaßnahmen zu kompensieren. Die Signale der redundanten Kontrollsysteme wurden falsch gedeutet, und schließlich wurde der Satellit immer stärker in Rotation versetzt, bis er wegen der zu groß werdenden Fliehkräfte schließlich zerbrach« (aus [URL: Fehlerkosten]).

Der Testaufwand muss in einem vernünftigen Verhältnis zum erzielbaren Ergebnis stehen.

»Testen ist ökonomisch sinnvoll, solange die Kosten für das Finden und Beseitigen eines Fehlers6 im Test niedriger sind als die Kosten, die mit dem Auftreten eines Fehlers bei der Nutzung verbunden sind« [Pol 00]. Der Testaufwand muss daher immer in Abhängigkeit mit dem im Fehlerfall verbundenen Risiko und der Gefährdungsbewertung stehen. Für den entstandenen Schaden (Totalverlust) des Weltraumteleskops Hitomi hätten sehr viele Tests durchgeführt werden können.