Basiswissen Softwaretest E-Book

Andreas Spillner

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 584

Beschreibung

Das bewährte Standardwerk zum Softwaretest – gut erklärt und praxisnah - Komplett aktualisiert auf den neuen Lehrplan »Certified Tester – Foundation Level« Version 4.0, der nun auch agile Ansätze beinhaltet - Mit vielen Beispielen, einem durchgehenden Fallbeispiel, Tipps und Exkursen - Eine reichhaltige Fundgrube für Lehre und Selbststudium Das ISTQB®-»Certified-Tester«-Programm ist das international standardisierte und weltweit anerkannte Aus- und Weiterbildungsschema für das Testen von Software. Das Buch behandelt den Lehrstoff zur Prüfung zum »Certified Tester« Foundation Level, Version 4.0 (CTFL) nach dem ISTQB®-Standard.  Aus dem Inhalt: - Grundlagen des Softwaretestens - Testen im Softwareentwicklungslebenszyklus - Statischer Test - Dynamischer Test - Testmanagement - Testwerkzeuge Der Anhang enthält wichtige Hinweise zum Lehrstoff und zur Prüfung zum »Certified Tester – Foundation Level« (CTFL), ein Glossar und ein ausführliches Literaturverzeichnis. Die 7. Auflage wurde komplett überarbeitet und beinhaltet alle praxisrelevanten Themen zum Testen von Software sowie agile Ansätze und Praktiken mit Bezug zum Softwaretest. Das Buch vermittelt damit das notwendige Wissen zur Vorbereitung auf die CTFL-Prüfung und eignet sich gleichermaßen als kompaktes Grundlagenwerk zu diesen Themen in der Praxis und an Hochschulen.

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. Von 2019 bis 2023 war er Mitglied im Präsidium des Arbeitskreises Softwarequalität & -Fortbildung (ASQF e.V.). 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 30 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. Im Jahr 2023 wurde er zum Ehrenmitglied des GTB ernannt. Tilo Linz ist auch Autor des Buches »Testen in agilen Projekten« (dpunkt.verlag), das aufbauend auf dem vorliegenden »Basiswissen Softwaretest« das Testen in agilen Projekten behandelt.

2022 erhielten Tilo Linz und Andreas Spillner gemeinsam den Deutschen Preis für Software-Qualität.

Auszug aus der Begründung:

»Beide haben über viele Jahre wesentlich dazu beigetragen, dass Software-Qualitätssicherung als Fachdisziplin wahrgenommen wird und sich etabliert hat. Heute existiert das anerkannte und wertgeschätzte Berufsbild des qualifizierten Software-Quality Engineers. Dafür brauchte es nicht nur die Grundlagen – Inhalte, Ausbildung, Zertifizierung –, sondern auch ein ständiges ›Dranbleiben‹ und die Weiterentwicklung der Themen. Tilo Linz und Andreas Spillner stehen bis heute für diese Kontinuität.

Warum beide zusammen? ›Spillner-Linz‹ ist in der Test-Community fast zu einem geflügelten Wort geworden. Beide haben mit ihren unterschiedlichen Perspektiven das Berufsbild Software-Quality Engineer geprägt und nicht zuletzt mit ihrem Buch ›Basiswissen Softwaretest‹ das ISTQB-Curriculum in der Aus- und Weiterbildung methodisch untermauert.«

(https://dpsq.de/)

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Andreas Spillner · Tilo Linz

Basiswissen Softwaretest

Aus- und Weiterbildung zum Certified Tester

Foundation Level nach ISTQB®-Standard

7., überarbeitete und aktualisierte Auflage

Andreas Spillner

[email protected]

Tilo Linz

[email protected]

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Eva Hepper, Silke Braun

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:

Print978-3-98889-005-4

PDF978-3-98890-139-2

ePub978-3-98890-140-8

7., überarbeitete und aktualisierte Auflage 2024

Copyright © 2024 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

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 Autoren noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

Vorwort zur 7. Auflage

Testen & Agilität

Im Jahr 2002 erschien die erste Auflage dieses Buches. Ein Jahr zuvor wurde das »Agile Manifest« publiziert. Sowohl das Buch als auch das agile Vorgehen in der Softwareentwicklung haben in den beiden zurückliegenden Jahrzehnten eine bemerkenswerte Entwicklung zu verzeichnen gehabt: »Basiswissen Softwaretest« hat sich als meistverkauftes Buch zum Thema Softwaretest in deutscher Sprache als Standardwerk etabliert und die agile Vorgehensweise ist zu »der« Praktik in der IT-Industrie avanciert. Da war es naheliegend, dass in der Neuauflage des Buches – und des Lehrplans – viele der agilen Praktiken, die das Testen betreffen, aufgenommen wurden.

Testkompetenz ist weiterhin erforderlich.

Softwareentwicklung ist zur Teamarbeit geworden. Während früher einzelne Aufgaben von Fachleuten (Designer, Entwickler, Tester, …) umgesetzt wurden und jeder nur für seinen Bereich verantwortlich war, ist heute die Zusammenarbeit im Team gefragt. »Den« Tester und »den« Entwickler im engeren Sinne gibt es nicht mehr. Das Fachwissen und die Kompetenzen werden aber weiterhin benötigt, sind jedoch nicht mehr direkt an einzelne Personen gebunden. Im Buch wird an einigen Stellen noch von »Tester« und »Entwickler« gesprochen, gemeint ist aber eine Person mit Test- bzw. Entwicklungskompetenz, was sich etwas sperrig liest.

In der vorliegenden 7. Auflage des Buches haben wir den Inhalt umfassend überarbeitet, aktualisiert und an die aktuelle Version 4.0 des Lehrplans zum »ISTQB® Certified Tester – Foundation Level« aus dem Jahr 2023 angepasst.

»Certified Tester«-Ausbildungsschema

Das anerkannte und sehr erfolgreiche »Certified Tester«-Ausbildungsschema besteht aus den Ausbildungsstufen »Foundation«, »Advanced« und »Expert«. Ergänzt wird es durch Module für die Arbeit in agilen Teams sowie durch Spezialisierungsmodule. Details dazu finden sich auf den Webseiten des »International Software Testing Qualifications Board« [URL: ISTQB] und des »German Testing Board e.V.« ([URL: GTB], [URL: GTB Schema]). Der »Certified Tester« hat sich zu einem Gütesiegel in der IT-Industrie entwickelt und ist heute der De-facto-Standard für die Ausbildung im Bereich Softwarequalitätssicherung und Softwaretest – in Deutschland und weltweit.

Beeindruckende Zahlen

»Die Weiterbildung zum Certified-Tester ist international erfolgreich. Über 118.000 absolvierte Softwaretester-Prüfungen in Deutschland (Stand 09/2023) sind gute Gründe, stolz zu sein. Weltweit sind es mehr als 1.200.000 (Stand 06/2023)« (aus [URL: GTB Schema]).

Damit hat sich die Anzahl der Prüfungen in den letzten fünf Jahren nahezu verdoppelt: 2018 waren es weltweit über 600.000, davon knapp 67.000 in Deutschland.

Wissen in der IT-Welt und an den Hochschulen gefragt

»Studierenden und Auszubildenden wird durch das Angebot des GTB aktuelles, von der Industrie gefordertes Wissen vermittelt: Der wachsende Anteil an Stellenausschreibungen, in denen ein ISTQB® Certified Tester Zertifikat explizit gefordert wird, beweist eine bereits jetzt vorhandene hohe Durchdringung des Marktes. Zudem haben in den letzten Jahren knapp 600 Studierende in Deutschland erfolgreich das Certified Tester Zertifikat abgelegt« (aus [URL: GTB Hochschulen]).

Der »Certified Tester« hat sich im Laufe der Jahre zu einem festen Bestandteil der Informatikausbildung an vielen Hochschulen entwickelt: Von A wie Aachen bis Z wie Zittau wird der Lehrstoff im deutschsprachigen Raum vermittelt. Welche Hochschulen aktuell entsprechende Lehrveranstaltungen anbieten oder planen, kann auf den Seiten des GTB nachgelesen werden [URL: GTB Hochschulen].

Ergänzende Literatur

Tilo und Andreas haben zwei weitere Bücher veröffentlicht, auf die hier hingewiesen werden soll, da sie eine gute Ergänzung bzw. Vertiefung darstellen. Andreas – als Norddeutscher – würde sagen: »Butter bei die Fische«, denn beide Bücher vertiefen die im Basiswissen-Buch vorhandenen Beschreibungen zur Agilität bzw. zu Testverfahren.

Buch: Testen in agilen Projekten

In seinem aktuellen Buch »Testen in agilen Projekten – Methoden und Techniken für Softwarequalität in der agilen Welt« (3. Auflage, 2024) zeigt Tilo, wie das Testen in agile Projekte integriert werden kann. Das Buch deckt damit die ISTQB®-Lehrpläne zum agilen Testen ab.

Buch: Lean Testing für C++-Programmierer

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

Auf beide Bücher wird in diesem Buch immer wieder verwiesen ([Linz 24], [Spillner 16]), um den Leserinnen und Lesern weiterführende Informationen zu bieten. Vielleicht sind wir mit den vielen Verweisen etwas über das Ziel hinausgeschossen, dafür bitten wir um Nachsicht – aber ein wenig Werbung für die eigene Arbeit wird hoffentlich noch erlaubt sein, oder?

Basiswissen

Von Anfang an haben wir den ersten Teil unseres Buchtitels »Basiswissen« ernst genommen und bewusst keine Themen behandelt, die sich in der Praxis erst noch »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 die entsprechende aktuelle Literatur zu diesen und anderen Themen.

Was hat sich geändert?

Aber auch Grundlagen unterliegen dem Wandel und sind aktuell zu halten. Ebenso haben die etablierten agilen Praktiken mit Bezug zum Softwaretest ihren Weg in das Buch gefunden. In der vorliegenden 7. Auflage wurden die Inhalte umfassend überarbeitet, ergänzt und aktualisiert.

Folgende Themen wurden neu aufgenommen oder ausführlicher behandelt:

Whole-Team-Ansatz

Test-First-Ansatz

Shift-Left

Retrospektive

Testen im Kontext von DevOps

Abnahmetestgetriebene Entwicklung (ATDD)

User Stories

Akzeptanzkriterien

Iterations- und Releaseplanung bei agilen Projekten

Testpyramide und Testquadrant

Exkurse sind nicht Teil des Lehrplans.

Bei der Überarbeitung des ISTQB®-Lehrplans wurden einige Themen auf höhere Ausbildungsstufen verschoben oder ganz weggelassen und sind somit nicht mehr Bestandteil des »Foundation Level«-Lehrplans. Wir haben diesen Schritt nicht strikt umgesetzt, sondern uns entschieden, die für die Praxis wichtigen Teile im Buch zu belassen. Diese sind als Exkurse farblich hervorgehoben (blaue Schrift). Wer das Buch nur zur Prüfungsvorbereitung nutzt, kann die Exkurse einfach überspringen.

Standard-Nachschlagewerk

Aus vielen Gesprächen mit Leserinnen und Lesern wissen wir, dass unser Buch als Nachschlagewerk für die tägliche (Test-)Arbeit genutzt wird. Deshalb haben wir neben den Inhalten des Lehrplans weitere grundlegende Testverfahren – als Exkurse – aufgenommen (z.B. kombinatorisches Testen, »Pairwise Testing«).

Das durchgehende Fallbeispiel und das Literaturverzeichnis wurden aktualisiert. Das Verzeichnis der Normen und Standards wurde ebenfalls überarbeitet. Die Angaben zu den Internetseiten (URLs) sind auf den aktuellsten Stand gebracht worden.

Webseite

Um die Leserinnen und Leser über zukünftige Aktualisierungen des Lehrplans und des Glossars zu informieren, betreiben wir die Internetseite »Softwaretest Knowledge« [URL: Softwaretest Knowledge]. Auf dieser Seite werden auch notwendige Korrekturen zum Buchtext aufgeführt. Neben Übungsaufgaben zu den einzelnen Buchkapiteln findet sich dort auch eine Cross-Referenz-Tabelle, in der zu jedem Lernziel des Lehrplans die entsprechenden Abschnitte des Buches aufgeführt sind, in denen das Lernziel ausführlich behandelt wird.

Ebenfalls sind dort das Vorwort zur 1. Auflage des Buches und die Geleitworte von Dorothy Graham, David Parnas und Martin Pol zu finden.

Danksagung

Erfolg hat meist viele Väter und Mütter – so auch hier. Allen Kolleginnen und Kollegen des GTB und des ISTQB® sei an dieser Stelle herzlich gedankt. Ohne ihr Engagement hätte das »Certified Tester«-Ausbildungsschema nicht den geschilderten Erfolg und die weltweite Akzeptanz erreicht. Ebenso möchten wir uns für die vielen Anmerkungen und Rezensionen unserer Leserinnen und Leser bedanken, die uns für unsere Arbeit am Buch sehr motiviert und zur Qualitätssteigerung beigetragen haben. Unserer Lektorin Christa Preisendanz und dem gesamten dpunkt.team danken wir für die langjährige und sehr gute Zusammenarbeit.

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

Andreas Spillner und Tilo Linz

Bremen, Möhrendorf

März 2024

Inhaltsübersicht

1Einleitung

2Grundlagen des Softwaretestens

3Testen im Softwareentwicklungslebenszyklus

4Statischer Test

5Dynamischer Test

6Testmanagement

7Testwerkzeuge

Anhang

AWichtige Hinweise zum Lehrstoff und zur Prüfung zum Certified Tester

BGlossar

CQuellenverzeichnis

Index

Inhaltsverzeichnis

1Einleitung

2Grundlagen des Softwaretestens

2.1Begriffe und Motivation

2.1.1Fehlerbegriff

2.1.2Testbegriff

2.1.3Testartefakte und ihre Beziehungen

2.1.4Aufwand für das Testen

2.1.5Testwissen frühzeitig und damit erfolgreich nutzen

2.1.6Grundsätze des Testens

2.2Softwarequalität

2.2.1Qualitätsmanagement und Qualitätssicherung

2.3Der Testprozess

2.3.1Testplanung

2.3.2Testüberwachung und Teststeuerung

2.3.3Testanalyse

2.3.4Testentwurf

2.3.5Testrealisierung

2.3.6Testdurchführung

2.3.7Testabschluss

2.3.8Verfolgbarkeit

2.3.9Einfluss des Kontextes auf den Testprozess

2.4Psychologie, Denkweisen und Kompetenzen

2.4.1Denkweisen und Kompetenzen von Testern und Entwicklern

2.5Zusammenfassung

3Testen im Softwareentwicklungslebenszyklus

3.1Sequenzielle Entwicklungsmodelle

3.1.1Das Wasserfallmodell

3.1.2Das V-Modell

3.2Iterativ-inkrementelle und agile Entwicklung

3.2.1Klassische iterativ-inkrementelle Entwicklung

3.2.2Agile Softwareentwicklung

3.2.3Zusammenarbeit in der agilen Anforderungsermittlung

3.3Softwareentwicklung im Projekt- und Produktkontext

3.4Teststufen

3.4.1Komponententest

3.4.2(Komponenten-)Integrationstest

3.4.3Systemtest und Systemintegrationstest

3.4.4Abnahmetest

3.5Testarten

3.5.1Funktionale Tests

3.5.2Nicht funktionale Tests

3.5.3Anforderungsbezogener und strukturbezogener Test

3.6Test nach Änderung und Weiterentwicklung

3.6.1Testen nach Softwarewartung und -pflege

3.6.2Testen nach Weiterentwicklung

3.6.3Regressionstest

3.7Verbesserung und Automatisierung des Softwareentwicklungsprozesses

3.7.1Testgetriebene Entwicklung

3.7.2Continuous Integration, Continuous Delivery, Continuous Deployment

3.7.3DevOps

3.7.4Retrospektiven und Prozessverbesserung

3.8Zusammenfassung

4Statischer Test

4.1Was kann analysiert und geprüft werden?

4.2Vorgehen beim Review

4.3Der Reviewprozess

4.3.1Aktivitäten im Reviewprozess

4.3.2Unterschiedliche Vorgehensweisen beim individuellen Review

4.3.3Rollen und Verantwortlichkeiten im Reviewprozess

4.4Reviewarten

4.5Erfolgsfaktoren, Vorteile und Grenzen

4.6Werkzeuggestützte statische Analyse

4.7Unterschiede zwischen statischen und dynamischen Tests

4.8Zusammenfassung

5Dynamischer Test

5.1Blackbox-Testverfahren

5.1.1Äquivalenzklassenbildung

5.1.2Grenzwertanalyse

5.1.3Zustandsbasierter Test

5.1.4Entscheidungstabellentests

5.1.5Kombinatorisches Testen

5.1.6Anwendungsfallbasierter Test

5.1.7Allgemeine Bewertung der Blackbox-Verfahren

5.2Whitebox-Testverfahren

5.2.1Anweisungstest und Anweisungsüberdeckung

5.2.2Zweigtest und Zweigüberdeckung

5.2.3Test der Bedingungen

5.2.4Allgemeine Bewertung der Whitebox-Verfahren

5.3Erfahrungsbasierte Testfallermittlung

5.4Auswahl von Testverfahren

5.5Zusammenfassung

6Testmanagement

6.1Testorganisation

6.1.1Unabhängiges Testen

6.1.2Rollen, Aufgaben und Qualifikation

6.2Teststrategie

6.2.1Teststrategie und Testkonzept

6.2.2Auswahl der Teststrategie

6.2.3Verschiedene konkrete Strategien

6.2.4Testen und Risiko

6.2.5Testaufwand und Testkosten

6.2.6Schätzverfahren zum Testaufwand

6.2.7Testkosten vs. Fehlerkosten

6.3Testplanung, Teststeuerung und Testüberwachung

6.3.1Testplanung

6.3.2Teststeuerung

6.3.3Testüberwachung

6.3.4Testberichte

6.4Fehlermanagement

6.4.1Testprotokoll auswerten

6.4.2Fehlermeldung erstellen

6.4.3Fehlerwirkungen klassifizieren

6.4.4Fehlerstatus verfolgen

6.4.5Auswertungen und Berichte

6.5Konfigurationsmanagement

6.6Relevante Normen und Standards

6.7Zusammenfassung

7Testwerkzeuge

7.1Testwerkzeugtypen

7.1.1Werkzeuge für Management und Steuerung von Tests

7.1.2Werkzeuge zur Testspezifikation

7.1.3Werkzeuge für statischen Test

7.1.4Werkzeuge zur Automatisierung dynamischer Tests

7.1.5Werkzeuge für nicht funktionale Tests

7.1.6Werkzeuge in der CI/CD- und DevOps-Pipeline

7.2Nutzen und Risiken der Testautomatisierung

7.3Effektive Nutzung von Werkzeugen

7.3.1Auswahl und Einführung von Testwerkzeugen

7.3.2Werkzeugauswahl

7.3.3Pilotprojekt zur Werkzeugeinführung

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

7.4Zusammenfassung

Anhang

AWichtige Hinweise zum Lehrstoff und zur Prüfung zum Certified Tester

BGlossar

CQuellenverzeichnis

C.1Literatur

C.2Weitere empfohlene Literatur

C.3Normen und Standards

C.4WWW-Seiten

Index

1Einleitung

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. Systeme mit künstlicher Intelligenz finden zurzeit eine rasend schnelle Verbreitung und wirken sich bereits heute in ganz vielen Bereichen unseres Lebens aus. 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 sowie Mitglieder in agilen Teams, 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 besteht aus den Ausbildungsstufen »Foundation«, »Advanced« und »Expert«. Es wird ergänzt um Module für die Arbeit in agilen Teams sowie Spezialistenmodule. Details dazu finden sich auf der Webseite des ISTQB® [URL: ISTQB] und des GTB [URL: GTB]. Die Grundlagen zum Softwaretest – sowohl bei klassischer als auch bei agiler Entwicklung – 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. Ergänzend bietet das Schema »Specialist Module«, die spezielle oder domänenspezifische Methoden, Techniken und Prozesse vermitteln. Beispiele sind »Sicherheitstester«, »Usability Testing« und »Certified Tester AI Testing«. Die dritte Stufe, das »Expert Level«-Zertifikat, richtet sich an erfahrene, professionelle Softwaretester und umfasst die Module »Improving the Test Process« und »Test Management«.

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 auch auf erforderliche Kompetenzen beim Testen eingegangen.

Testen im Softwarelebenszyklus

Kapitel 3 stellt in der Softwareentwicklung gebräuchliche Lebenszyklusmodelle (sequenziell, iterativ-inkrementell, agil) kurz vor und erläutert, welche Rolle das Testen im jeweiligen Modell spielt. Wichtige Elemente agiler Vorgehensweisen (Backlogs, Whole-Team-Ansatz, User Stories, Continuous Integration etc.) werden erläutert und es wird aufgezeigt, welchen Einfluss sie auf die Gestaltung der Testaktivitäten haben. Die verschiedenen Teststufen und Testarten werden ausführlich erklärt und auf die Unterschiede beim funktionalen und nicht funktionalen Test eingegangen. Das Thema Regressionstest wird ebenfalls angesprochen. Wichtige Ansätze zur Verbesserung und Automatisierung der Softwareentwicklung und des Testprozesses (CI/CD, frühes Testen/Shift-Left, testgetriebene Entwicklung, DevOps) werden kompakt vorgestellt und erläutert.

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 »Whitebox«-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, Rollen und Aufgaben beim Testmanagement zu berücksichtigen sind und welche Anforderungen an die Qualifikation der Mitarbeiter bestehen, wird in Kapitel 6 diskutiert. Welche Elemente zu einer Teststrategie gehören und wie diese durch eine fundierte Testplanung, Teststeuerung und Testüberwachung umgesetzt wird, wird ausführlich erklärt. Wichtige Verfahren zur Schätzung von Testaufwand und Testkosten werden vorgestellt und es wird erläutert, welchen Beitrag das Testen leistet, um Risiken zu mindern, und wie risikobasiertes Testen funktioniert. Abschließend werden Anforderungen an das Fehlermanagement und Konfigurationsmanagement sowie das Thema Wirtschaftlichkeit des Testens besprochen.

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.

2Grundlagen 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, unterschiedliche Denkweisen und erforderliche Kompetenzen beim Testen eingegangen.

2.1Begriffe 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 (bzw. Kontrolle der Qualität) und verringert die Risiken beim Einsatz der Software, da mögliche Fehler während des Testens – und damit vor dem Einsatz des Softwaresystems – aufgedeckt werden können. Testen trägt somit dazu bei, die vereinbarten Ziele (s. Abschnitt 2.1.2) innerhalb des vereinbarten Umfangs zu erreichen sowie die festgelegten Zeit-, Qualitäts- und Budgetvorgaben einzuhalten.

Der Beitrag des Testens zum Erfolg ist nicht auf die Aktivitäten des Testteams – wenn es ein solches Team überhaupt gibt – beschränkt. Jeder am Projekt Beteiligte – ebenso die Stakeholder – kann und soll seine Fähigkeiten zum Testen einsetzen, damit das Projekt erfolgreich und mit der gewünschten Qualität durchgeführt und beendet wird.

Das (statische und dynamische, s. Kap. 4 und 5) Testen von Komponenten, Systemen und der zugehörigen Dokumentation erkennt Fehler (Fehlerzustände bzw. Fehlerwirkungen) in der Software. Dem Testen von Software kommt 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 mehr als nur die Ausführung von Testfällen. Neben dieser eher technischen Aktivität sind alle weiteren Aktivitäten rund um das Testen sorgfältig zu planen und zu verwalten. Auch ist der zu veranschlagende Aufwand für das Testen vorab zu schätzen und dann zu überwachen und ggf. anzupassen. Diese unterschiedlichen Aktivitäten werden oft als ein Prozess – der Testprozess – zusammengefasst. 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. 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 den Abschnitten 2.3 und 6.3.

Testen im Softwareentwicklungslebenszyklus

Die Testaktivitäten werden je nach Entwicklungslebenszyklus der Software unterschiedlich organisiert und durchgeführt. Testen ist in verschiedenen Abschnitten auch ein Mittel zur direkten Bewertung der Qualität eines Testobjekts. So kann beispielsweise der Übergang zu einer nächsten Phase der Softwareentwicklung oder die Planung der nächsten Iteration von den Ergebnissen der Tests abhängen (z.B. Entscheidung über die Freigabe des Testobjekts).

Testen ist eine intellektuell herausfordernde Tätigkeit.

Viele der Testaktivitäten werden durch Werkzeuge unterstützt oder auch erst durch sie ermöglicht (s. Kap. 7). Testen ist aber eine weitgehend intellektuelle Tätigkeit, die von den ausführenden Personen Fachwissen, analytische Fähigkeiten und kritisches Hinterfragen sowie Systemdenken erfordert (s. [Myers 11], [Roman 18]).

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 aus der Perspektive der späteren Nutzer

Eine Aufgabe des Testens ist somit die Sicherstellung, dass die Anforderungen der späteren Nutzer während des gesamten Entwicklungszyklus berücksichtigt werden. Eine repräsentative Gruppe von Nutzern in das Entwicklungsprojekt einzubinden, ist sicherlich eine gute Alternative, die aber in der Regel aufgrund der hohen Kosten und der mangelnden Verfügbarkeit geeigneter Nutzer meist nicht möglich ist. Testen beinhaltet somit auch die Validierung des Systems (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.1Fehlerbegriff

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. Der englische Begriff hierfür ist »Error«.

Fehlhandlungen können aus vielfältigen Gründen entstehen. Einige typische Fehlhandlungen bzw. Gründe (bzw. Hauptursachen) 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.

Oder die Projektbeteiligten sind abgelenkt, unkonzentriert oder einfach müde.

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 analysieren3, 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.2Testbegriff

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 für die betroffene Codekomponente verantwortlichen Softwareentwicklungsteams 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 werden dieselben Personen, die auch die Tests zur Aufdeckung der betreffenden Fehler durchgeführt haben, mit den Fehlernachtests beauftragt oder auch – insbesondere bei agiler Entwicklung – die Person, die den Fehler im Code korrigiert. Wenn ein automatisierter Test vorhanden ist, dann ist der Fehlernachtest nichts anderes als das erneute Ausführen des/der automatisierten Tests, die jetzt aber mit »passed« durchlaufen sollten, statt mit »failed«.

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 (Regressionstest, s. Abschnitt 3.6.3).

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

4

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 zu erhalten, ob eine geforderte Überdeckung – z.B. Ausführung aller Anweisungen (s.

Abschnitt 5.2.1

) nach Ausführung aller spezifizierten Testfälle – erfüllt ist oder ob zu deren Erreichung weitere Testfälle spezifiziert und ausgeführt werden müssen.

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, Komponentenintegrationstest, Systemtest, Systemintegrationstest, 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 und zu beheben (»Debugging«). Ein weiteres Ziel kann es sein, die Tests so zu wählen, dass die erreichte Überdeckung des Programmtexts (s. Abschnitt 5.2.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.3Testartefakte 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 und Informationen 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 Testbedingungen5 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«).

ProtokollTestkonzept & Testzeitplan

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

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, die im Testzeitplan festgelegt werden.6

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. Welche weiteren Artefakte während der einzelnen Aktivitäten des Testprozesses zu erstellen sind, wird dort beschrieben.

Abb. 2–2Testartefakte und ihre Beziehungen

2.1.4Aufwand 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.7

Der Stellenwert des Testens in einem Projekt war früher u.a. daran erkennbar, wie das Zahlenverhältnis von Testern zu Programmierern aussah. In der Praxis war eine große Bandbreite anzutreffen: von einem Tester auf zehn Programmierer bis hin zu drei Testern pro Programmierer. Bei agil durchgeführten Projekten, wo es keine feste Zuordnung zwischen Personen und ihren Rollen mehr gibt, lässt sich das so einfach nicht mehr erkennen. Hier muss man die Aufgabentypen im Backlog betrachten. Bei beiden Projekttypen sind in der Praxis aber weiterhin sehr unterschiedlich hohe Budgetanteile zu finden, die für den Test bzw. testbezogene Aufgaben investiert werden.

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 Fehlers8 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.

Beispiel: Risiko und Schaden im Fehlerfall

Während der Kaufinteressent sein Wunschfahrzeug konfiguriert, zeigt DreamCar laufend den Kaufpreis der aktuellen Konfiguration an. Bestandskunden des Herstellers oder Interessenten, die sich vorher bei einem Händler ausgewiesen und autorisiert haben, können ihr Wunschfahrzeug online bestellen! Sobald sie »verbindlich bestellen« anklicken und ihre »PIN« eintippen, ist das Fahrzeug gekauft und bestellt. Nach der gesetzlichen Widerrufsfrist für Online-Käufe wird die gewählte Konfiguration dann automatisch an den Produktionsplanungsrechner übermittelt, der die Produktion einplant und initiiert.

Wird dabei vom System eine fehlerhafte Preisberechnung durchgeführt, kann der Kunde auf dem angezeigten Preis bestehen. Denn es ist ein verbindlicher Kaufvertrag zustande gekommen! Somit kann eine fehlerhafte Preisberechnung dazu führen, dass Tausende von Fahrzeugen zu einem zu geringen Preis verkauft werden. Der Gesamtschaden kann, je nachdem wie stark sich das VSR-II-System je Fahrzeug »verrechnet«, in die Millionen gehen. Dass jeder Vertrag manuell überprüft wird, ist keine Option. Denn der Sinn der Funktion ist ja gerade, dass der Hersteller mit VSR-II einen solchen 100% automatisierten Online-Verkaufsprozess realisieren kann.

Testintensität und Testumfang in Abhängigkeit vom Risiko festlegen

Systeme oder Systemteile mit einem hohen Risiko müssen ausgiebiger getestet werden als solche, die im Fehlerfall keine großen Schäden verursachen.9 Wobei die Risikoeinschätzung für die einzelnen Systemteile oder sogar für einzelne Fehlermöglichkeiten durchzuführen ist. Bei einem hohen Risiko im Fehlverhalten eines Systems oder Teilsystems ist für den Test ein höherer Aufwand zu veranschlagen als bei weniger kritischen System(teil)en. Die Intensität des Tests muss entsprechend hoch sein. Internationale Standards für die Produktion von sicherheitskritischen Systemen geben ein solches Vorgehen vor, indem sie die Verwendung von verschiedenen aufwendigen Verfahren zum Testen vorschreiben (z.B. [RTC-DO 178C] für den Luftfahrtbereich).

Für die Herstellerfirma eines Computerspiels kann ein fehlerhaftes Speichern eines Spielstandes ein sehr hohes Risiko bedeuten (obwohl es keine direkten Schäden verursacht), da das fehlerhafte Spiel bei der Kundschaft nicht akzeptiert wird und zu hohen Absatzverlusten, möglicherweise bei allen Spielen der Firma, führen kann.

2.1.5Testwissen frühzeitig und damit erfolgreich nutzen

Erfolgsfaktor Testen

Mit dem Testen – genauer mit den Überlegungen und vorbereitenden Arbeiten zum Testen – soll so früh wie möglich begonnen werden (auch als Shift-Left-Ansatz bezeichnet). Im Folgenden werden Beispiele aufgeführt, die die Vorteile verdeutlichen, wenn Personen (Tester) mit entsprechendem Testwissen bei einzelnen Aktivitäten während der Softwareentwicklung involviert sind:

Enge Zusammenarbeit zwischen Entwicklern und Testern während der gesamten Softwareentwicklung

Beteiligen sich Tester an der Prüfung der Anforderungen (z.B. durch Reviews, s.

Abschnitt 4.2

) oder an der Verfeinerung (»Refinements«) von User Stories und bringen ihr Testfachwissen ein, können Unklarheiten und Fehler in den Arbeitsprodukten aufgedeckt und behoben werden. Die Identifizierung und Behebung der fehlerhaften Anforderungen reduzieren das Risiko der Entwicklung falscher oder nicht testbarer Funktionen.

Die enge Zusammenarbeit von Testern mit Systemdesignern während des Entwurfs des Systems kann das Verständnis jeder Partei für das Design und dessen Test erheblich verbessern. Dieses erhöhte Verständnis kann das Risiko grundlegender Konstruktionsfehler reduzieren und ermöglicht die frühzeitige Identifikation potenzieller Tests, z.B. zur Prüfung der Schnittstellen beim Komponentenintegrationstest (s.

Abschnitt 3.4.2

).

Arbeiten Entwickler und Tester während der Codeerstellung zusammen, kann das Verständnis auf beiden Seiten für den Code und dessen Test verbessert werden. Dieses reduziert das Risiko von Fehlerzuständen im Programmtext und auch von fehlerhaften Tests zur Prüfung des Programmtextes (falsch negatives Ergebnis, s.

Abschnitt 6.4.1

).

Wenn Tester die Software vor deren Freigabe verifizieren und validieren, können weitere Fehlerzustände erkannt und behoben werden, die ansonsten unentdeckt geblieben wären. Dies erhöht die Wahrscheinlichkeit, dass die Software den Bedürfnissen der Interessenvertreter gerecht wird und die Anforderungen erfüllt.

Zusätzlich zu diesen Beispielen trägt das Erreichen der oben definierten Testziele zum allgemeinen Erfolg der Softwareentwicklung bzw. der Wartung bei.

2.1.6Grundsätze des Testens

In den vorherigen Abschnitten wurde das Testen von Software behandelt. In diesem Abschnitt werden die wesentlichen Grundsätze des Testens zusammenfassend dargestellt, die sich aus den zurückliegenden Jahrzehnten herauskristallisiert haben und als generelle Leitlinien beim Testen angesehen werden.

Grundsatz:Testen zeigt die Anwesenheit von Fehlerzuständen

Mit Testen wird das Vorhandensein von Fehlerwirkungen und damit von Fehlerzuständen nachgewiesen. Testen verringert – je nach Testaufwand und Intensität – die Wahrscheinlichkeit, dass noch unentdeckte Fehlerzustände im Testobjekt vorhanden sind. Mit Testen lässt sich jedoch nicht beweisen, dass keine Fehlerzustände im Testobjekt vorhanden sind. Selbst wenn keine Fehlerwirkungen im Test aufgezeigt wurden, ist dies kein Nachweis für Fehlerfreiheit oder Korrektheit.

Grundsatz:Vollständiges Testen ist nicht möglich

Ein vollständiger Test, bei dem alle möglichen Eingabewerte und deren Kombinationen unter Berücksichtigung aller unterschiedlichen Vor- und Randbedingungen ausgeführt werden, ist nicht durchführbar, mit Ausnahme bei sehr trivialen Testobjekten. Tests sind immer nur Stichproben, und der Testaufwand ist deshalb unter Verwendung von Testverfahren (s. Kap. 5) nach Risiko und Prioritäten zu steuern.

Grundsatz:Frühes Testen spart Zeit und Geld

Testaktivitäten – sowohl statische als auch dynamische – sollen im System- oder Softwarelebenszyklus so früh wie möglich beginnen und definierte Ziele verfolgen. Frühes Testen wird auch mit »shift left« bezeichnet. Durch frühzeitiges Prüfen werden Fehlerzustände frühzeitig erkannt. Es hilft dabei, im Softwareentwicklungslebenszyklus späte und damit kostenintensive Änderungen zu reduzieren oder zu vermeiden.

Grundsatz:Häufung von Fehlerzuständen

In der Regel ist keine Gleichverteilung der Fehlerzustände über das gesamte System gegeben. Vielmehr finden sich die meisten Fehlerzustände in nur wenigen Teilen (Komponenten) eines Systems. Die geschätzte oder auch tatsächlich beobachtete Anhäufung von Fehlerzuständen in einzelnen Systemteilen kann zur Risikoanalyse genutzt werden. Der Testaufwand kann dann auf die fehlerträchtigen Teile konzentriert werden (s. auch Grundsatz 2).

Grundsatz:Testfälle »nutzen sich ab«

Werden Tests an unveränderten Systemversionen nur wiederholt, decken sie keine neuen Fehlerwirkungen mehr auf. Damit die Effektivität der Tests nicht absinkt, sind die vorhandenen Testfälle regelmäßig zu prüfen und durch neue oder modifizierte Testfälle zu ergänzen. Bisher nicht geprüfte Teile der Software oder unberücksichtigte Konstellationen bei der Eingabe werden dann ausgeführt und somit mögliche weitere Fehlerwirkungen nachgewiesen. Trotz allem kann die Wiederholung von unveränderten Testfällen sinnvoll sein, wenn z.B. ein automatisierter Regressionstest durchgeführt wird (s. Abschnitt 3.6.3).

Grundsatz:Testen ist kontextabhängig

Je nach Einsatzgebiet und Umfeld des zu prüfenden Systems ist das Testen anzupassen. Keine zwei Systeme sind auf die exakt gleiche Art und Weise zu testen. Intensität des Testens, Definition der Endekriterien usw. sind bei jedem System entsprechend seines Einsatzumfelds festzulegen. Eingebettete Systeme (»Embedded Systems«) verlangen andere Prüfungen als etwa ein E-Commerce-System. Testen in agilen Projekten ist anders durchzuführen als das Testen in einem Projekt mit sequenziellem Softwareentwicklungslebenszyklus.

Grundsatz:Trugschluss: Keine Fehler bedeutet ein brauchbares System

Trotz gründlicher Tests aller spezifizierten Anforderungen und Beheben aller gefundenen Fehlerzustände kann ein System entwickelt worden sein, das schwer zu nutzen ist, das die Bedürfnisse und Erwartungen der Nutzer nicht erfüllt oder das geringe Qualität aufweist im Vergleich zu ähnlichen anderen Systemen (oder dem Vorgängersystem). Frühzeitige Einbeziehung der späteren Nutzer in den Entwicklungsprozess und die Nutzung von Prototyping sind vorbeugende Maßnahmen zur Vermeidung des Problems.

2.2Softwarequalität10

Exkurs

Das Testen von Software dient durch die Identifizierung von Fehlerwirkungen und deren anschließender Beseitigung zur Steigerung der Softwarequalität. Die Testfälle sollten so gewählt werden, dass sie weitgehend der späteren Benutzung der Software entsprechen. Die nachgewiesene Qualität des Programms während der Tests entspricht dann der zu erwartenden Qualität während der späteren Nutzung.

Softwarequalität umfasst aber mehr als nur die Beseitigung der beim Test aufgedeckten Fehlerwirkungen. Nach ISO 25010 [ISO 25010] wird Softwarequalität in zwei Modelle unterteilt:

ISO 25010: quality in use model & product quality model

das Nutzungsqualitätsmodell (quality in use model) unddas Produktqualitätsmodell (product quality model).

Im Nutzungsqualitätsmodell werden folgende fünf Eigenschaften (characteristics) zusammengefasst:

Effektivität (effectiveness)Effizienz (efficiency)Nutzungszufriedenheit (satisfaction)Risikofreiheit (freedom from risk)Kontextabdeckung (context coverage)

Das Produktqualitätsmodell umfasst acht Eigenschaften:

Funktionelle Eignung (functional sustainability)Leistungseffizienz (performance efficiency)Kompatibilität (compatibility)Gebrauchstauglichkeit (usability)Zuverlässigkeit (reliability)Sicherheit (security)Wartbarkeit (maintainability)Portabilität (portability)

Im Produktqualitätsmodell finden sich die meisten Überschneidungen zur Vorgängerversion, der ISO-Norm 9126. Detaillierte Informationen zum Datenqualitätsmodell (data quality model) sind der ISO-Norm 25012 [ISO 25012] zu entnehmen.

Alle diese Eigenschaften bzw. Qualitätsmerkmale sind beim Testen zu bedenken, um die Gesamtqualität eines Softwareprodukts umfassend beurteilen zu können. Welches Qualitätsniveau das Testobjekt dabei in jeder einzelnen Eigenschaftsdimension aufweisen soll, muss vorab als Qualitätsanforderung festgelegt werden. Die Erfüllung dieser Anforderungen ist dann je Kriterium durch geeignete Tests zu überprüfen.

Beispiel: Anwendung der ISO 25010 für VSR-II

Die verantwortliche Leiterin für Test/QS des VSR-II-Gesamtsystems schlägt dem Projektlenkungsausschuss vor, als Grundlage für die Bewertung und Verfolgung der Produktqualität von VSR-II das Produktqualitätsmodell aus der ISO 25010 zu verwenden. Dies findet breite Zustimmung und die Leiterin Test/QS wird beauftragt, bis zur nächsten Sitzung einen Vorschlag zu erarbeiten, wie ISO 25010 im VSR-II-Projekt angewendet wird. Als Kern ihres Vorschlags erarbeitet sie eine Matrix, die darstellt, welche Qualitätseigenschaft für welche Produktkomponente welche Relevanz hat und welche Interpretation gelten soll. Die erste Fassung dieser Matrix sieht folgendermaßen aus:

Tab. 2–1Festlegung der Qualitätseigenschaften

Die Einstufungen sind relativ zueinander zu verstehen. Für jede Matrix-Zelle begründet sie, warum die jeweilige Einstufung erfolgt, z.B.:

Funktionelle Eignung/alle

Jedes der Systeme bedient sehr hohe Anwenderzahlen bzw. verarbeitet deren Daten, funktionelle Fehler haben daher hohes wirtschaftliches Schadenspotenzial. Die Anforderungen an die Funktionelle Eignung sind daher durchgehend mit »high« bewertet.

Kompatibilität/ConnectedCar

Keine Anforderung, da das System komplett neu entsteht.

Gebrauchstauglichkeit/FactBook

Keine Anforderung, da das System ein Backend-System ist und die API bereits feststeht.

Portabilität/DreamCar

Einstufung »low«, da das Framework, das verwendet wird, dies ohne besondere Maßnahmen weitgehend abdeckt.

Welche Prüfungen und Tests jeweils vorzusehen sind, muss im Zuge der QS/Test-Planung je Teilsystem festgelegt werden. Auf dieser obersten Ebene können jedoch Rahmenbedingungen vorgegeben werden, wie beispielsweise: Zu einem »high«-Kriterium müssen automatisierte Tests für »Continuous Integration« (s. Abschnitt 3.7.2