Praxiswissen Softwaretest - Test Analyst und Technical Test Analyst E-Book

Graham Bath

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Serie: iSQI-Reihe
• Sprache: Deutsch

Seitenzahl: 829

Veröffentlichungsjahr: 2015

Beschreibung

Das Buch deckt sowohl funktionale als auch technische Aspekte des Softwaretestens ab und vermittelt damit das notwendige Praxiswissen für Test Analysts und Technical Test Analysts - beides entscheidende Rollen in Testteams. Der Test Analyst fokussiert dabei stärker auf betriebswirtschaftliche Aspekte, während der Technical Test Analyst technisch orientiert ist und in den meisten Fällen bereits viel Erfahrung mit Softwareentwicklung und Softwaretesten mitbringt. Die Autoren behandeln das Testen aller Qualitätsmerkmale nach der ISO-Norm 9126. Mit einer durchgängigen Beispielanwendung, Erfahrungsberichten und Lernkontrollen vermitteln sie hilfreiche Testverfahren und Methoden für die Berufspraxis eines Testers. Jedes Qualitätsmerkmal wird entsprechend der einzelnen Schritte des vom International Software Testing Qualifications Board (ISTQB) festgelegten Standardtestprozesses dargestellt. Das Buch deckt alle Inhalte ab, um die PrŸfungen zum Erwerb der ISTQB Advanced-Level-Zertifikate "Test Analyst" und "Technical Test Analyst" zu bestehen. Der Lehrstoff wurde um zusätzliche Informationen und Beispiele aus der Praxis erweitert. Die 3. Auflage wurde überarbeitet und ist konform zur aktuellen Ausgabe der ISTQB-Lehrpläne Advanced Level von Oktober 2012.

Leseprobe

Graham Bath ist seit über 30 Jahren in der Welt des Softwaretestens tätig. Seine Erfahrung und Expertise umspannen eine breite Palette verschiedener Fachgebiete und Technologien. Als Testmanager trug er die Verantwortung für das Testen missionskritischer Systeme in der Raumfahrt, der Telekommunikation und der polizeilichen Störungskontrolle. Er war verantwortlich für den Entwurf von Tests höchster Gründlichkeitsstufen im Bereich Echtzeit-Luftfahrtsysteme, z. B. für die Militärflugzeuge Tornado und Eurofighter.

Als einer der Hauptberater der T-Systems Global Delivery Unit, Testing Services leitete er die Qualitätsförderungsprogramme mehrerer großer Unternehmen, insbesondere im Finanz- und Regierungssektor. In seiner aktuellen Position ist Graham Bath für das Fortbildungsprogramm des Unternehmens verantwortlich.

Im ISTQB ist Graham Bath Leiter der Arbeitsgruppe »Expert Level«. Er ist Koautor des Buches »Improving the Test Process« (Rocky Nook) und gibt ISTQB akkreditierte Schulungen zu diesem Thema.

Judy McKay ist seit 25 Jahren mit dem Schwerpunkt Softwarequalitätssicherung in der Hightech-Branche tätig. Ihre Berufspraxis deckt alle Aspekte des Softwarelebenszyklus ab. Hierzu zählen Bedarfsentwurf und -analyse, Softwareentwicklung, Datenbankentwurf, Sicherung der Softwarequalität, Softwaretests, technische Kundenbetreuung, Fachleistungen, Konfigurations-management, technische Veröffentlichungen und Softwarelizenzierung. Judy McKay hat in kommerziellen Softwareunternehmen, der Raumfahrtbranche, internationaler Forschung und Entwicklung, Vernetzungsprojekten und Internetunternehmen gearbeitet.

Judy McKay bietet auch Fortbildungen und Beratungsdienste zur Softwarequalitätssicherung an. Zu den Themen zählen der Aufbau und die Pflege eines erstklassigen Qualitätssicherungsteams, der Entwurf und die Implementierung von Qualitätssicherung und effektiven Tests sowie die Erstellung und Implementierung aussagekräftiger Testdokumentationen und Metriken. Sie ist Mitverfasserin des Lehrplans zum ISTQB-Advanced-Level und Vorstand des American Testing Board. Sie ist Autorin von »Managing the Test People« (Rocky Nook), einem Buch voller Ratschläge und Anektoden für neue und erfahrene Softwaretestmanager und -leiter.

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.de/plus

Praxiswissen Softwaretest – Test Analyst und Technical Test Analyst

Aus- und Weiterbildung zum Certified Tester – Advanced Level nach ISTQB-Standard

3., überarbeitete Auflage

Graham BathJudy McKay

Graham Bath, [email protected]

Judy McKay, [email protected]

Lektorat: Christa Preisendanz

Übersetzung: Volkmar Gronau

Copy-Editing: Ursula Zimpfer, Herrenberg

Herstellung: Birgit Bäuerlein

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: Media-Print Informationstechnologie, Paderborn

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:

Buch 978-3-86490-137-9

PDF 978-3-86491-639-7

ePub 978-3-86491-640-3

3., überarbeitete Auflage 2015

Translation copyright für die deutschsprachige Ausgabe © 2015 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Copyright der amerikanischen Originalausgabe © 2014 by Graham Bath and Judy McKay

Title of American original: The Software Test Engineer’s Handbook

Rocky Nook Inc., Santa Barbara, www.rockynook.com

ISBN 978-1-937538-44-6

Fachliche Beratung und Herausgabe von dpunkt.büchern zum Thema »ISTQB® Certified Tester«: Prof. Dr. Andreas Spillner · [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

Geleitwort

Das Testen von Software gehört mittlerweile zu den Grundfesten der Qualitätssicherung in Unternehmen. Damit Tester dieser essenziellen Rolle gerecht werden können, bedarf es einer fundierten Qualifizierung zur Professionalisierung des Softwaretestens. Mit dem international anerkannten »ISTQB Certified Tester«-Weiterbildungsprogramm existiert ein Branchenstandard, der die Kernkompetenzen des Berufsbildes festlegt und sowohl theoretische Begriffsdefinitionen als auch erforderliches Praxiswissen vereinheitlicht vermittelt. Viele Unternehmen haben die ISTQB-Qualifikation in die eigene Mitarbeiterfortbildung integriert und machen sie in Stellenausschreibungen für Bewerber zur Pflicht.

Das vorliegende Buch richtet sich an Softwaretester, deren Beruf gleichzeitig Berufung ist: Sie haben Ihre Fähigkeiten bereits in Testprojekten unter Beweis gestellt, sind »ISTQB Foundation Level«-zertifiziert und können in einem Projekt die Rolle eines »ISTQB Advanced Tester« übernehmen: Testmanager, Test Analyst oder Technical Test Analyst. Welche besonderen Fähigkeiten und Fertigkeiten von Test Analyst und Technical Test Analyst erwartet werden, erfahren Sie auf den folgenden Seiten. Basierend auf dem ISTQB-Advanced-Level-Lehrplan, angereichert mit zusätzlichen Informationen und Beispielen aus der Praxis, verbindet das vorliegende Buch sowohl technische als auch funktionale Aspekte des Testens miteinander. Es ist deshalb für jeden professionellen Softwaretester von Nutzen.

Die Autoren haben sich große Verdienste bei der Weiterentwicklung des Certified-Tester-Schemas erworben. Diese Publikation komplettiert die Reihe der Module des ISTQB-Standards. Alle Lerninhalte des Buches decken sich mit den Vorgaben des ISTQB-Standards, sodass Ihre Weiterbildung den Kriterien Unabhängigkeit, Transparenz und internationale Akzeptanz in vollem Umfang genügt. Denn:

1. Professionalisierung tut not:

Software muss zuverlässig sein, also müssen auch die Entwickler verlässlich ausgebildet sein. Sonst gehen mit Vertrauensverlusten in Softwaresysteme auch Auftrags- und Arbeitsplatzverluste einher.

2. Lebenslanges Lernen wird zur Pflicht:

Software wird immer komplexer, die Anforderungen steigen täglich. Lebenslanges Lernen ist daher unabdingbar, da die Erstausbildung nicht mehr aktuell und meist zu übergreifend allgemein ist.

3. Die Hersteller- und produktunabhängige Standardisierung schafft Transparenz – und damit wiederum Akzeptanz und allgemeine Gültigkeit. Nationale und internationale Vergleichbarkeit von Berufsqualifikationen ist in der heutigen globalen Zusammenarbeit für Arbeitgeber und -nehmer von gleichem Vorteil und sichert die internationale Kooperations- und Wettbewerbsfähigkeit.

Das International Software Quality Institute (iSQI GmbH) zertifiziert in 90 Ländern auf 6 Kontinenten das Know-how von (IT-)Fachkräften. Weit über 300.000 Professionals sind nach dem ISTQB-Lehrplan geschult und haben ihre Kenntnisse durch die Zertifizierungsabschlussprüfung unter Beweis gestellt. Ich freue mich, dass Sie sich entschlossen haben, ein Teil dieser weltweiten Testergemeinde zu werden und wünsche Ihnen Freude beim Durcharbeiten des Buches, viel Erfolg bei der späteren Zertifizierungsprüfung und schließlich gutes Gelingen Ihrer Projekte!

Stephan GoerickeCEOInternational Software Quality Institute

Vorwort zur 3. Auflage

Mit diesem Buch schließen Sie eine Lücke zwischen den Softwaretestbüchern in Ihrer Fachbibliothek. Zwar gibt es viel gute Literatur zu den grundlegenden Testtechniken, aber nur relativ wenige Bücher decken sowohl funktionales als auch technisches Testen in ausgewogenem Maße ab.

Dieses Buch fügt sowohl funktionale als auch technische Aspekte des Testens zu einem einheitlichen Ganzen zusammen, wovon nicht nur Test Analysts, sondern auch Testmanager profitieren können. Test Analysts und Testmanager leben nicht in einer abgeschotteten Welt; effektive Kommunikation, z. B. mit anderen Testern, spielt eine große Rolle. Um sich effektiv verständigen zu können, müssen sie sowohl die funktionalen als auch die technischen Aspekte des Testens verstehen, einschließlich der erforderlichen Testtechniken.

Dieses Buch behandelt das Testen aller Qualitätsmerkmale der ISO-Norm 9126, einschließlich Performanz, Zuverlässigkeit, Sicherheit, Funktionalität, Benutzbarkeit, Wartbarkeit und Übertragbarkeit. Jedes Qualitätsmerkmal wird in Hinblick auf die einzelnen Schritte des vom International Software Testing Qualifications Board (ISTQB) festgelegten Standardtestprozesses behandelt. Dadurch wird eine abgerundete und ausgewogene Abdeckung dieser Qualitätsmerkmale erreicht.

Vollständige Abdeckung des 2012 erschienenen ISTQB-Lehrplans für Test Analysts und Technical Test Analysts

Der Inhalt dieses Buches basiert auf den englischsprachigen Advanced-Level-Lehrplänen zum Test Analyst [ISTQB-ATA] und zum Technical Test Analyst [ISTQB-ATTA], die 2012 vom ISTQB herausgegeben wurden1. Es werden alle Inhalte abgedeckt, die Sie kennen müssen, um die Prüfungen zum Erwerb der Advanced-Level-Zertifi-kate Test Analyst und Technical Test Analyst zu bestehen. Das Buch bietet allen, die an einer oder beiden Prüfungen teilnehmen möchten, eine solide Vorbereitungsbasis. Es wird deutlich angezeigt, welche Abschnitte sich auf welche Prüfung beziehen. Alle prüfungsrelevanten Inhalte sind gekennzeichnet.

Obwohl der Inhalt in erster Linie mit dem ISTQB-Advanced-Level-Lehrplan abgestimmt ist, haben wir Wert darauf gelegt, dass das Buch für jeden professionellen Tester von Nutzen sein kann. Wir haben daher den Lehrstoff um zusätzliche Informationen und Beispiele aus der Praxis erweitert.

Danksagung

Unser Dank gilt unseren Kollegen im internationalen Autorenteam, mit denen wir in vielstündiger Arbeit die Lehrpläne zum ISTQB Certified Tester, Advanced Level verfasst haben:

Rex Black, Bernard Homès, Paul Jorgensen, Jamie Mitchell, Mike Smith, Kenji Onishi, Tsuyoshi Yumoto.

Mein (Grahams) Dank gilt besonders:

meinen Kollegen bei T-Systems, Global Delivery Unit »Testing Services«, für ihre Hilfsbereitschaft und Professionalität,

meiner Familie (Elke, Christopher, Jennifer) für ihr Verständnis und ihre Geduld.

Mein (Judys) Dank gilt besonders:

Rex Black für das Eröffnen neuer Möglichkeiten sowie für seine Beratung und Hilfe bei der beruflichen Weiterentwicklung,

den Mitarbeitern des Cedar Glen Inn, die mir erlaubten, in meinen verlängerten Mittagspausen dieses Buch in ihrem Restaurant zu schreiben,

meiner Familie für ihre Hilfe, ihr Verständnis und ihre Bereitschaft, meine endlosen Manuskriptbearbeitungen zu ertragen.

Inhaltsübersicht

1  Einführung

2  Marathon – unsere Beispielanwendung

3  Systemarten

4  Aufgaben des Test Analyst für das Testmanagement

5  Der Testprozess

6  Spezifikationsorientierte Testverfahren

7  Fehlerbasierte Testverfahren

8  Erfahrungsbasierte Testverfahren

9  Funktionales Testen

10 Benutzbarkeits- und Zugänglichkeitstests

11 Reviews für Test Analysts

12 Management von Fehlern und Abweichungen

13 Werkzeugkonzepte

14 Aufgaben des Technical Test Analyst für das Testmanagement

15 Analysetechniken

16 Strukturbasierte Testverfahren

17 Effizienztests

18 Sicherheitstests

19 Zuverlässigkeitstests

20 Wartbarkeitstests

21 Portabilitätstests

22 Reviews für Technical Test Analysts

23 Werkzeuge für Technical Test Analysts

Anhang

A   Glossar

B   Literatur

      Stichwortverzeichnis

Inhaltsverzeichnis

1         Einführung

1.1      Der Aufbau dieses Buches

1.2      Anforderungen an dieses Buch

1.2.1    Vollständigkeit

1.2.2    Lesbarkeit

1.3      Was bedeutet »advanced«?

1.4      Was ist ein »Test Analyst«?

2         Marathon – unsere Beispielanwendung

2.1      Überblick über das Marathon-System

2.2      Allgemeine Anforderungen

2.3      Einsatz des Marathon-Systems

2.4      Verfügbarkeit des Marathon-Systems

2.5      Erweiterungen vorbehalten

3         Systemarten

3.1      Einführung

3.1.1    Multisysteme

3.1.2    Sicherheitskritische Systeme

3.1.3    Echtzeit- und eingebettete Systeme

4         Aufgaben des Test Analyst für das Testmanagement

4.1      Einführung

4.2      Überwachung und Steuerung des Projekts

4.2.1    Produkt(qualitäts)risiken

4.2.2    Fehler

4.2.3    Testfälle

4.2.4    Nachverfolgbarkeit

4.2.5    Vertrauen

4.3      Kommunikation mit anderen Testern – wo auch immer sie sich aufhalten

4.4      Blick in die Praxis

4.5      Lernkontrollen

5         Der Testprozess

5.1      Einführung in den Testprozess

5.2      Den Prozess in den Lebenszyklus einpassen

5.3      Die Schritte des Testprozesses

5.3.1    Testplanung, -überwachung und -steuerung

5.3.2    Testanalyse

5.3.3    Testentwurf

5.3.4    Testrealisierung

5.3.5    Testausführung

5.3.6    Abschluss der Testaktivitäten

5.4      Lernkontrolle

6         Spezifikationsorientierte Testverfahren

6.1      Einführung

6.2      Einzelne spezifikationsorientierte Testverfahren

6.2.1    Äquivalenzklassenbildung

6.2.2    Grenzwertanalyse

6.2.3    Entscheidungstabellen

6.2.4    Ursache-Wirkungs-Graph-Analyse

6.2.5    Zustandsbasiertes Testen

6.2.6    Kombinatorisches Testen – paarweises Testen und orthogonale Arrays

6.2.7    Kombinatorisches Testen – Klassifikationsbäume

6.2.8    Anwendungsfallbasiertes Testen

6.2.9    User-Story-basiertes Testen

6.2.10  Wertebereichsanalyse

6.3      Auswahl eines spezifikationsorientierten Testverfahrens

6.4      Blick in die Praxis

6.5      Lernkontrolle

7         Fehlerbasierte Testverfahren

7.1      Einführung

7.2      Taxonomien

7.3      Die Anwendung der Technik

7.4      Blick in die Praxis

7.5      Lernkontrolle

8         Erfahrungsbasierte Testverfahren

8.1      Einführung

8.2      Intuitive Testfallermittlung

8.3      Checklistenbasiertes Testen

8.4      Exploratives Testen

8.5      Stärken und Schwächen

8.6      Blick in die Praxis

8.7      Lernkontrolle

9         Funktionales Testen

9.1      Einführung

9.2      Testen auf Richtigkeit

9.3      Testen auf Angemessenheit

9.4      Interoperabilitätstests

9.5      Blick in die Praxis

9.6      Lernkontrolle

10       Benutzbarkeits- und Zugänglichkeitstests

10.1    Benutzbarkeitstests

10.1.1    Effektivität

10.1.2    Effizienz

10.1.3    Zufriedenheit

10.1.4    Teilaspekte der Benutzbarkeit

10.2    Zugänglichkeitstests

10.3    Testprozess für Benutzbarkeits- und Zugänglichkeitstests

10.3.1    Planungsfragen

10.3.2    Testentwurf

10.3.3    Spezifizierung von Benutzbarkeitstests

10.4    Blick in die Praxis

10.5    Lernkontrolle

11      Reviews für Test Analysts

11.1    Einführung

11.2    Welche Arbeitsergebnisse können wir einem Review unterziehen?

11.3    Wann sollten Test Analysts die Reviews durchführen?

11.4    Aspekte von Reviews

11.4.1  Wie können wir unser Review effektiv gestalten?

11.4.2  Haben wir die richtigen Leute?

11.4.3  Wir haben die Fehler gefunden – was nun?

11.4.4  Wir haben keine Zeit für Reviews!

11.5    Checkliste für Reviews

11.6    Checkliste für Anforderungsreviews

11.7    Checkliste für die Reviews von Anwendungsfällen

11.8    Checkliste für Benutzbarkeitsreviews

11.9    Checkliste für Reviews von User Stories

11.10  Checkliste für die erfolgreiche Durchführung

11.11  Blick in die Praxis

11.12  Lernkontrolle

12       Management von Fehlern und Abweichungen

12.1    Einführung

12.2    Was ist ein Fehlerzustand?

12.3    Wie können wir Fehlerzustände finden

12.4    Felder für Fehlerzustände

12.5    Lebenszyklen von Fehlerzuständen

12.6    Metriken und Berichterstattung

12.6.1  Überwachung des Testfortschritts

12.6.2  Analyse der Fehlerdichte

12.6.3  Messungen gefundener versus behobener Fehler

12.6.4  Konvergenzmetriken

12.6.5  Informationen zur Einhaltung der Phasen

12.6.6  Ist unsere Fehlerinformation objektiv?

12.7    Möglichkeiten der Prozessverbesserung

12.8    Blick in die Praxis

12.9    Lernkontrolle

13       Werkzeugkonzepte

13.1    Was ist ein Testwerkzeug?

13.2    Warum setzen wir Werkzeuge ein?

13.3    Werkzeugarten

13.3.1  Testentwurfswerkzeuge

13.3.2  Datenwerkzeuge

13.3.3  Testdurchführungswerkzeuge

13.3.4  Wann sollten Sie eine Automatisierung durchführen?

13.3.5  Was Sie über Automatisierung wissen sollten

13.3.6  Umsetzen der Automatisierung

13.4    Sollten wir alle unsere Tests automatisieren?

13.5    Blick in die Praxis

13.6    Lernkontrolle

14       Aufgaben des Technical Test Analyst für das Testmanagement

14.1    Einführung

14.2    Blick in die Praxis

14.3    Lernkontrolle

15       Analysetechniken

15.1    Statische Analyse

15.1.1  Nutzen

15.1.2  Einschränkungen

15.1.3  Kontrollflussanalyse

15.1.4  Datenflussanalyse

15.1.5  Einhaltung von Codierungsstandards

15.1.6  Ermittlung von Codemetriken

15.1.7  Statische Analyse von Websites

15.1.8  Aufrufgraphen

15.2     Dynamische Analyse

15.2.1  Nutzen

15.2.2  Einschränkungen

15.2.3  Speicherlecks

15.2.4  Probleme mit Zeigern

15.2.5  Analyse der Performanz

15.3    Blick in die Praxis

15.4    Lernkontrolle

16       Strukturbasierte Testverfahren

16.1    Nutzen

16.2    Nachteile

16.3    Anwendung von strukturbasierten Testverfahren

16.4    Einzelne strukturbasierte Testverfahren

16.4.1  Anweisungstests

16.4.2  Zweig-/Entscheidungstests

16.4.3  Bedingungstests

16.4.4  Bedingungs-/Entscheidungstests

16.4.5  Mehrfachbedingungstests

16.4.6  Tests mit modifizierter Bedingungs-/Entscheidungsüberdeckung (MC/DC)

16.4.7  Pfadtests

16.4.8  API-Tests

16.5    Auswahl eines strukturbasierten Testverfahrens

16.6    Lernkontrolle

17       Effizienztests

17.1    Überblick

17.2    Performanztests

17.3    Lasttests

17.4    Stresstests

17.5    Skalierbarkeitstests

17.6    Testen der Ressourcennutzung

17.7    Messen der Effizienz

17.8    Planen von Effizienztests

17.8.1  Risiken und typische Effizienzfehler

17.8.2  Verschiedene Arten von Testobjekten

17.8.3  Anforderungen für Effizienztests

17.8.4  Vorgehensweisen für Effizienztests

17.8.5  Bestanden-/Nicht-bestanden-Kriterien für Effizienztests

17.8.6  Werkzeuge für Effizienztests

17.8.7  Umgebungen

17.8.8  Organisatorische Aspekte

17.8.9  Aspekte des Lebenszyklus

17.9    Spezifikation von Effizienztests

17.10  Durchführung von Effizienztests

17.11  Berichterstattung von Effizienztests

17.12  Werkzeuge für Performanztests

17.13  Blick in die Praxis

17.14  Lernkontrolle

18       Sicherheitstests

18.1    Überblick über Sicherheitstests

18.2    Definition von Sicherheit

18.3    Typische Sicherheitsbedrohungen

18.4    Vorgehensweise für Sicherheitstests

18.5    Organisatorische Aspekte

18.6    Aspekte des Lebenszyklus

18.7    Planen von Sicherheitstests

18.8    Analyse und Entwurf von Sicherheitstests

18.8.1  Softwareangriffe

18.8.2  Weitere Entwurfstechniken für Sicherheitstests

18.9    Durchführung von Sicherheitstests

18.10  Berichterstattung von Sicherheitstests

18.11  Werkzeuge für Sicherheitstests

18.12  Blick in die Praxis

18.13  Lernkontrolle

19       Zuverlässigkeitstests

19.1    Überblick

19.1.1  Reife

19.1.2  Fehlertoleranz

19.1.3  Wiederherstellbarkeit

19.2    Planung von Zuverlässigkeitstests

19.2.1  Bewertung des Risikos

19.2.2  Festlegen von Zuverlässigkeitszielen

19.2.3  Aspekte des Lebenszyklus

19.2.4  Vorgehensweise für Zuverlässigkeitstests

19.2.5  Vorgehensweise für das Messen des Zuverlässigkeitsgrads

19.2.6  Vorgehensweise für das Messen der Fehlertoleranz

19.2.7  Vorgehensweise für Failover-Tests

19.2.8  Vorgehensweise für Backup- und Wiederherstellungstests

19.3    Spezifikation von Zuverlässigkeitstests

19.3.1  Testspezifikation für das Zuverlässigkeitswachstum

19.3.2  Testspezifikation für die Fehlertoleranz

19.3.3  Spezifikation von Failover-Tests

19.3.4  Spezifikation von Backup- und Wiederherstellungstests

19.4    Durchführung von Zuverlässigkeitstests

19.5    Berichterstattung von Zuverlässigkeitstests

19.6    Werkzeuge für Zuverlässigkeitstests

19.7    Blick in die Praxis

19.8    Lernkontrolle

20       Wartbarkeitstests

20.1    Überblick

20.2    Testen auf Wartbarkeit

20.2.1  Definition von Wartbarkeit

20.2.2  Warum hat die Wartbarkeit einen geringen Stellenwert?

20.2.3  Ursachen schlechter Wartbarkeit

20.3    Planung von Wartbarkeitstests

20.4    Spezifikation von Wartbarkeitstests

20.5    Wartbarkeitstests und Analysen durchführen

20.6    Wartungstests

20.7    Aufgaben von Technical Test Analysts

20.8    Blick in die Praxis

20.9    Lernkontrolle

21       Portabilitätstests

21.1    Anpassbarkeit

21.1.1  Gründe für mangelnde Anpassbarkeit

21.1.2  Anpassbarkeitstests

21.2    Austauschbarkeit

21.2.1  Fragen der Austauschbarkeit

21.2.2  Austauschbarkeitstests

21.3    Installierbarkeit

21.3.1  Risikofaktoren der Installierbarkeit

21.3.2  Installationstests

21.4    Koexistenz/Kompatibilität

21.5    Blick in die Praxis

21.6    Lernkontrolle

22       Reviews für Technical Test Analysts

22.1    Einführung

22.2    Checklisten für Reviews

22.3    Checklisten für Codereviews

22.4    Checkliste für Architekturreviews

22.5    Lernkontrolle

23       Werkzeuge für Technical Test Analysts

23.1    Einführung

23.2    Aufgaben und Fähigkeiten von Technical Test Analysts für die Testautomatisierung

23.3    Integration und Informationsaustausch zwischen Werkzeugen

23.4    Definition eines Testautomatisierungsprojekts

23.5    Sollten wir alle unsere Tests automatisieren?

23.6    Werkzeugarten

23.6.1  Fehlereinpflanzungs- und Fehlereinfügungswerkzeuge

23.6.2  Werkzeuge für Komponententests und Builds

23.6.3  Werkzeuge für die statische Analyse von Websites

23.6.4  Werkzeuge zur Unterstützung modellbasierter Tests

23.6.5  Statische und dynamische Analysewerkzeuge

23.6.6  Performanztestwerkzeuge

23.6.7  Simulations- und Emulationswerkzeuge

23.6.8  Debugging- und Troubleshooting-Werkzeuge

23.7    Lernkontrolle

Anhang

A Glossar

B Literatur

Stichwortverzeichnis

1 Einführung

Es war eine dunkle und stürmische Nacht ... Oder war das der Anfang eines anderen Buches? Zumindest beschreibt dieser erste Satz sehr treffend, wie sich manche Testprojekte in einer ewigen Krise befinden und wie das Management oft im Dunkeln tappt – aber lassen wir dies vorerst beiseite.

Dieses Buch soll zwei Aufgaben erfüllen. Erstens bietet es hilfreiche Techniken und Methoden, die den erfahrenen Tester im Alltag erfolgreich unterstützen. Zweitens werden alle Inhalte abgedeckt, die Sie kennen müssen, um die Prüfung zum Erwerb der ISTQB-Advanced-Level-Zertifikate Test Analyst und Technical Test Analyst zu bestehen. Im ersten Kapitel beschreiben wir die Ziele, die wir uns für dieses Buch gesteckt haben, sowie die grobe Struktur der einzelnen Kapitel. Danach befassen wir uns mit zwei grundlegenden Fragen: Was bedeutet die Bezeichnung »advanced« im Zusammenhang mit der Tester-Zertifizierung und wie ist die Rolle des Test Analyst und Technical Test Analyst definiert?

Ein Wort zur Klärung:Im Originaltitel dieses Buches kommt der Begriff »Test Engineer« vor. In vielen, aber nicht allen Ländern ist dies die Bezeichnung für den leitenden Tester mit der höchsten technischen Qualifikation. In Abgrenzung zu Gebieten, in denen dieser Begriff eine andere Bedeutung haben mag, hat sich das ISTQB für die Verwendung der Begriffe »Test Analyst« (weniger technisch, sondern mehr geschäftlich orientiert) und »Technical Test Analyst« (stärker technisch orientiert, möglicherweise sogar mit einem Hintergrund nicht nur im Testwesen, sondern auch in der Entwicklung) entschieden. In diesem Buch werden deshalb analog zur ISTQB-Terminologie durchgängig die Begriffe Test Analyst und Technical Test Analyst verwendet.

1.1 Der Aufbau dieses Buches

Die Lehrpläne ISTQB Advanced Test Analyst und ISTQB Advanced Technical Test Analyst wurden in der Ausgabe 2012 als getrennte Dokumente angelegt. Dadurch ergibt sich für dieses Buch die folgende klare Struktur:

Hauptthema

Kapitel

Hauptautoren

Gemeinsame Bereiche

1 bis 3

Judy und Graham

Test Analyst (TA)

4 bis 13

Judy

Technical Test Analyst (TTA)

14 bis 23

Graham

Anhänge

A, B

Judy und Graham

1.2 Anforderungen an dieses Buch

Wir haben sehr hohe Anforderungen an dieses Buch gestellt. Bevor wir mit dem eigentlichen Inhalt des funktionalen und technischen Testens beginnen, möchten wir Ihnen kurz diese Anforderungen darlegen und gleichzeitig damit auch unsere allgemeine Vorgehensweise verdeutlichen.

Unser Ziel war es, ein gut lesbares und vollständiges Buch zu schreiben.

1.2.1 Vollständigkeit

Dieses Buch basiert auf dem englischsprachigen ISTQB-Advanced-Level-Lehrplan (2012, [ISTQB-CTAL])1 und deckt alle Inhalte ab, die Sie kennen müssen, um die Prüfungen zum Test Analyst und Technical Test Analyst zu bestehen. Außerdem können Sie mithilfe des vermittelten Wissens Ihre Fähigkeiten und Kenntnisse vertiefen und dadurch Ihre Chancen auf dem Arbeitsmarkt verbessern.

1.2.2 Lesbarkeit

In diesem Buch geht es um mehr, als einfach nur den Advanced-Level-Lehrplan abzudecken.

Wenn man ein Buch auf der Basis eines bereits definierten Lehrplans schreibt, kann man leicht in einen Formulierungsstil verfallen, der sich lediglich auf die Behandlung des Lehrplans konzentriert. Natürlich ist es notwendig, die Inhalte des Lehrplans abzudecken. Das Ergebnis ist jedoch allzu oft ein eher trockener Stil, der sich an Definitionen orientiert und viele verschiedene Schriftarten und Symbole enthält, um auf einzelne Teile des Lehrplans zu verweisen. Dies wollten wir vermeiden. Wir möchten Ihnen ein Buch bieten, das den Lehrplan abdeckt und sich gleichzeitig gut liest.

Wir möchten die Lesbarkeit dieses Buches erhöhen, indem jedes Kapitel dem gleichen Aufbau folgt:

Technischer Inhalt

Nach einer kurzen Einführung geben wir die in dem Kapitel behandelten Begriffe an. Die Definitionen dieser in der Branche gewöhnlich benutzten Begriffe finden Sie in dem kleinen Glossar in Anhang A. Da wir gerade von Branchenslang sprechen: Die Begriffe Bug und Fehler werden hier austauschbar verwendet. Aufgrund unserer praktischen Erfahrungen in der Branche neigen wir dazu, die gebräuchlicheren Begriffe zu verwenden.

Danach kommen wir zum eigentlichen technischen Inhalt des Kapitels. Die Lernziele des ISTQB-Advanced-Level-Lehrplans beschränken sich nicht nur auf die Wiedergabe von angeeignetem Wissen. Vielmehr sollen sie dabei helfen, das Gelernte anzuwenden und eine Basis für gut begründete Entscheidungen zu schaffen. Das Buch geht daher über die Inhalte des Lehrplans hinaus und bietet Ihnen anschauliches Material, um Ihr Wissen weiter abzurunden.

Wir verwenden ein komplexes, realistisches Praxisbeispiel.

Blick in die Praxis

Die meisten Kapitel enthalten einen Abschnitt mit dem Titel »Blick in die Praxis«. Dieser Abschnitt hilft Ihnen, das erlernte Wissen zu vertiefen und zu verinnerlichen. Zudem bietet er eine willkommene Abwechslung vom typischen Lehrbuchstil, der bei lehrplanorientierten Veröffentlichungen unwillkürlich vorherrscht. Diese Abschnitte sind daher vor allem für Leser von Interesse, die sich nicht nur auf den ISTQB-Lehrplan konzentrieren.

Wir beziehen uns hierbei auf unsere Marathon-Beispielanwendung (Beschreibung siehe Kap. 2). Diese Beispielanwendung basiert auf einem realen System und wird uns durch das gesamte Buch begleiten. Auf diese Weise behalten wir die vielfältigen Aspekte des Testens stets im Auge.

Erfahrungsberichte und Lessons Learned

Wir haben im Laufe unserer Berufsjahre einen umfangreichen Erfahrungsschatz gesammelt und möchten ein paar dieser Erfahrungen mit Ihnen teilen. Wie so oft im Leben verlaufen die Dinge nicht immer nach Plan. Diese Erfahrungen zeigen uns, dass eine Zertifizierung als Tester keine automatische Erfolgsgarantie darstellt – in erster Linie deshalb, weil sich die Praxis nicht immer an die Theorie hält! Diese grau hinterlegten Textblöcke werden Sie durch das ganze Buch begleiten.

Wer äußert sich in diesen Berichten? Wenn es in dem Kapitel um Test Analysts geht, ist es im Allgemeinen Judy, wenn es um Technical Test Analysts geht, Graham. Damit wissen Sie, wer mit »ich« gemeint ist, wenn wir Erfahrungen und Lessons Learned mitteilen sowie Vorkommnisse erzählen, die wir ansonsten gerne verdrängen.

Lernkontrolle

Am Ende jedes Kapitels finden Sie einige Multiple-Choice-Fragen, um Ihren Kenntnisstand zu überprüfen. Diese Fragen werden Ihnen in den ISTQB-Prüfungen natürlich nicht begegnen (das wäre etwas zu einfach!).

1.3 Was bedeutet »advanced«?

Wenn man sich als »Advanced Tester« bezeichnet, kann das für viele ein rotes Tuch sein. Eine typische Reaktion darauf könnte folgendermaßen lauten: »Gut, dann sehen wir doch mal, ob Sie dieses Problem lösen können.« Konfrontiert mit dieser Herausforderung, sollte ein professioneller Tester in der Lage sein, die Bezeichnung »Advanced Tester« zu erklären. Hier sind für alle Fälle ein paar schnelle Antworten für Sie:

Advanced Tester haben Softwaretesten als ihren Beruf gewählt und sind bereits vom ISTQB zertifiziert (Foundation Level).

Sie haben ihre Fähigkeiten im Bereich Softwaretesten bereits auf theoretischer und praktischer Ebene unter Beweis gestellt und arbeiten auf einem hohen, international anerkannten Niveau.

Sie haben bereits Erfahrungen mit Testprojekten gesammelt.

Sie können in einem Projekt die Rolle des Testmanagers, Test Analyst oder des Technical Test Analyst übernehmen.

Sie wissen, dass Lernen ein lebenslanger Prozess ist und man sich immer weiter verbessern kann.

Sie haben daher höhere Chancen auf dem Arbeitsmarkt.

Professionelle Tester haben den Vorteil, dass sie eine gemeinsame Branchensprache sprechen.

Noch ein weiterer (teilweise umstrittener) Aspekt zum Thema Zertifizierung: Die Advanced-Level-Zertifizierung bringt keinerlei Garantie mit sich. Es gibt viele gute Tester, die nicht zertifiziert sind. Die Zertifizierung zeigt jedoch, dass Sie einen hohen professionellen Standard erreicht haben und dass Sie die allgemein anerkannte Sprache der Branche sprechen. Da die IT-Branche stark globalisiert ist und viele Testprojekte in mehreren Ländern durchgeführt werden, ist dies ein gewaltiger Vorteil.

Wir, die Autoren, sind übrigens in allen drei Rollen auf dem Advanced Level zertifiziert und sind stolz darauf. Die wichtigsten Organisationen, mit denen wir zusammenarbeiten, haben die Zertifizierungsprogramme in ihr Fortbildungsangebot aufgenommen, was sich sehr gut auf die Mitarbeitermotivation und die Kundenzufriedenheit ausgewirkt hat.

Neben zertifizierungsrelevanten Inhalten bietet das Buch auch eine Fülle an wertvollen Informationen, aus denen man als Advanced Tester Nutzen ziehen kann. Ganz egal, ob Zertifizierung für Sie ein Thema ist oder nicht, wir sind uns sicher, dass Sie in der Praxis von dem Gelernten profitieren werden.

1.4 Was ist ein »Test Analyst«?

Es ist nicht leicht, eine Berufsbezeichnung auf internationaler Ebene zu definieren. Oft verwenden unterschiedliche Länder oder sogar unterschiedliche Unternehmen im gleichen Land verschiedene Bezeichnungen für die gleiche Rolle oder assoziieren ein etwas anderes Aufgabengebiet mit einer bestimmten Rolle. Dafür gibt es keinen bestimmten Grund – die Terminologie hat sich schlicht und einfach so entwickelt.

Im Foundation Level hat das ISTQB dieses Problem teilweise behoben, indem es die Rollen des Testmanagers (auch Testleiter genannt) und Testers eingeführt hat.

Die Rolle des Test Analyst baut auf der Rolle des Testers auf.

Im Advanced Level hat das ISTQB diesen Trend zur Standardisierung weitergeführt und die Rolle des Test Analyst eingerichtet. Vom Test Analyst werden zunächst die gleichen Fähigkeiten erwartet, die ein Tester gemäß ISTQB-Foundation-Level-Lehrplan [ISTQB-CTFL] vorweisen muss. Bei der Rolle des Test Analyst kommt jedoch eine Spezialisierung hinzu, die wir in diesem Abschnitt ansprechen möchten.

Was erwarten Sie von einem Test Analyst? Bei höchsten Anforderungen würde ein Arbeitgeber die folgenden grundlegenden Fähigkeiten von einem Test Analyst erwarten:

Durchführung geeigneter Testaktivitäten auf der Grundlage des verwendeten Lebenszyklus der Softwareentwicklung

Bestimmung der Priorität der Testaktivitäten auf der Grundlage der Informationen aus der Risikoanalyse

Auswahl und Anwendung geeigneter Testtechniken, um sicherzustellen, dass die Tests einen angemessenen Grad an Vertrauen auf der Grundlage der definierten Abdeckungskriterien bieten

Bereitstellung einer angemessenen Dokumentation der Testaktivitäten

Bestimmung des geeigneten Typs durchzuführender Funktionstests

Übernahme der Verantwortung für Usability-Tests eines Projekts

Aktive Teilnahme an formalen und informellen Reviews mit Stakeholdern; Anwendung von Kenntnissen über typische Fehler in Arbeitserzeugnissen

Entwurf und Umsetzung eines Verfahrens zur Fehlerklassifizierung

Anwendung von Werkzeugen zur Unterstützung eines effizienten Testprozesses

Die Fähigkeit, den Testmanager bei der Entwicklung geeigneter Teststrategien zu unterstützen

Die Fähigkeit, die erforderlichen Testaufgaben zu strukturieren, um die Teststrategie umzusetzen

Die Fähigkeit, das System mit der Genauigkeit zu analysieren, die erforderlich ist, um die angemessenen Testbedingungen zu bestimmen

Die Fähigkeit, geeignete Techniken anzuwenden, um die definierten Testziele zu erreichen

Die Fähigkeit, alle erforderlichen Testaktivitäten vorzubereiten und auszuführen

Die Fähigkeit, zu beurteilen, ob die Testkriterien erfüllt worden sind

Die Fähigkeit, Fortschrittsberichte knapp und gründlich zu formulieren

Die Fähigkeit, Auswertungen und Reviews mit Belegen aus Tests zu unterstützen

Die Fähigkeit, die geeigneten Werkzeuge zur Durchführung der Test-aufgaben einzusetzen

Der Test Analyst ist mit der Rolle des Testmanagers vertraut und kennt die Grundprinzipien des Testmanagements. Darunter fällt auch die Fähigkeit, bestimmte Anforderungen zu verstehen und die verschiedenen Risikotypen einzuschätzen.

Es werden zwei bestimmte Arten von Test Analysts definiert.

Die Position des Test Analyst wiederum wird laut Advanced-Level-Lehrplan und den Gepflogenheiten der Branche durch zwei unterschiedliche Rollen definiert. Beide Rollen erfordern die zuvor genannten allgemeinen Fähigkeiten, jedoch werden sie in unterschiedlichen Zusammenhängen angewandt. Ganz allgemein kann man sagen, dass der Technical Test Analyst eine eher technische Funktion erfüllt, während der Domain Test Analyst eine eher betriebswissenschaftliche Herangehensweise vertritt und Tests in seinem fachlichen Umfeld (domain) durchführt.

Ein Technical Test Analyst hat folgende Fähigkeiten:

Erkennt und klassifiziert die typischen Risiken für Performanz, Sicherheit, Zuverlässigkeit, Portabilität und Wartbarkeit von Softwaresystemen.

Stellt Testkonzepte auf, die ausführlich die Planung, das Design und die Ausführung von Tests beschreiben, mit denen Risiken für Performanz, Sicherheit, Zuverlässigkeit, Portabilität und Wartbarkeit abgemildert werden.

Wählt geeignete strukturelle Designtechniken aus und wendet sie an, um sicherzustellen, dass die Tests eine Code- und Designabdeckung aufweisen, die einen angemessenen Grad an Vertrauen bietet.

Nimmt aktiv an technischen Reviews mit Entwicklern und Softwarearchitekten teil und bringt Kenntnisse über typische Fehler in Code und Architektur mit ein.

Erkennt Risiken im Code und in der Softwarearchitektur und stellt Testkonzeptelemente auf, um diese Risiken durch dynamische Analyse abzuschwächen.

Schlägt durch Anwendung statistischer Analyse Verbesserungen für die Sicherheit, Wartbarkeit und Testbarkeit von Code vor.

Skizziert die Kosten und Vorteile, die bei der Einführung bestimmter Arten von Testautomatisierung zu erwarten sind.

Wählt geeignete Werkzeuge aus, um technische Testaufgaben zu automatisieren.

Versteht die technischen Probleme und Prinzipien bei der Anwendung der Testautomatisierung.

2 Marathon – unsere Beispielanwendung

Testkonzepte sind in der Regel einfacher zu verstehen, wenn sie auf ein realistisches Projekt angewandt werden. Wir haben daher eine fiktive Anwendung entwickelt, mit der wir die verschiedenen in diesem Buch behandelten Techniken und Testarten darstellen möchten. Die Marathon-Anwendung ist ein typisches Beispiel für ein heute häufig vorkommendes System, das sowohl funktionales als auch nicht funktionales Testen erfordert.

Wie man es von einem Vorbereitungsbuch für die Zertifizierung zum ISTQB Advanced Level erwarten kann, ist die Beispielanwendung kompliziert genug, um realistische Testszenarien zu bieten. Die erforderliche Mühe, das Marathon-System zu verstehen, wird sich jedoch zu einem späteren Zeitpunkt durch ein tieferes Verständnis bestimmter Aspekte des Testens bei praktischen Anwendungen auszahlen.

Im Verlauf des Buches werden wir die allgemeine Beschreibung der Marathon-Anwendung immer wieder erweitern (ganz im Sinne der wohlbekannten schleichenden Änderung des Projektumfangs). Dies erlaubt eine gründlichere Behandlung einzelner Aspekte.

Erwarten Sie jedoch nicht, dass das Marathon-System in jeder Hinsicht vollkommen ist (die Autoren sind schließlich professionelle Tester, keine Systemarchitekten). Falls Sie Lücken oder Inkonsistenzen im Design finden, ist das ein Zeichen dafür, dass Sie bereits jetzt wie ein Advanced Tester denken!

2.1 Überblick über das Marathon-System

Das System ermöglicht den Organisatoren großer Marathonveranstaltungen (z. B. Boston, London), die Läufe mithilfe moderner Technologie effizient zu planen und zu organisieren.

Schauen Sie sich die Abbildung 2–1 an. Was sehen Sie? Vermutlich haben Sie unseren ausdauernden Marathonläufer bemerkt. Sicherlich ist Ihnen auch aufgefallen, dass das Marathon-System aus einer Anzahl unabhängiger Hardware-und Softwarekomponenten besteht, die zusammen eine komplette Anwendung ergeben (die Pfeile stehen für den wichtigsten Daten- und Kontrollfluss). Einige der Softwarekomponenten sind kommerzielle Standardprodukte (auch Commercial Off-The-Shelf Systems (COTS) genannt), manche werden intern entwickelt, und wiederum andere werden bei Subunternehmen in Auftrag gegeben.

Abb. 2–1 Das Marathon-System

Der Einfachheit halber gehen wir in der Abbildung nicht auf die technische Architektur ein. Wir können jedoch annehmen, dass eine Mischung aus verschiedenen Plattformen (Clients, Server und Betriebssysteme), Kommunikationsprotokollen, Datenbanken und Implementierungssprachen verwendet wird. Kurz gesagt ist es ein typisches Beispiel für ein System, mit dem wir uns als Tester in der Praxis befassen müssen.

In den Abschnitten mit der Überschrift »Blick in die Praxis« wird uns unser unerschrockener Marathonläufer durch das ganze Buch begleiten. Zunächst werden wir uns jedoch die funktionalen Anforderungen näher anschauen und kurz die Benutzung des Systems ansprechen.

2.2 Allgemeine Anforderungen

Die Marathon-Anwendung soll die folgenden Funktionen erfüllen:

Verwaltungssystem für die Organisatoren des Laufs

System für die Anmeldung der Läufer

System für das Sponsern von Läufern

Rechtzeitige und genaue Informationen für Läufer und Medien

Berichtsystem für Läufer und Medien

Informationsstelle (Helpdesk) für alle, die Fragen zur Veranstaltung haben

Fakturierungssystem, das die Sponsorenbeträge und Teilnahmegebühren in Rechnung stellt

Das System muss in der Lage sein, pro Veranstaltung die Daten von bis zu 100.000 Läufern und 10.000 Sponsoren ohne Ausfälle zu bewältigen, und es muss die Kapazität haben, bis zu fünf Veranstaltungen pro Jahr durchzuführen.

2.3 Einsatz des Marathon-Systems

Das Marathon-System kommt während des gesamten Laufs, inklusive der Vor- und Nachbereitung, zum Einsatz. Diese Hauptaktivitäten sind in Abbildung 2–2 dargestellt (nicht maßstabgetreu).

Abb. 2–2 Einsatzphasen des Marathon-Systems

Wie das Marathon-System verwendet wird, wollen wir uns im Folgenden anschauen.

Registrierung der Läufer und Sponsoren

Vor jedem Lauf werden über das System Läufer und Sponsoren registriert.

Die Registrierung der Teilnehmer beginnt vier Wochen vor der Veranstaltung und geht eine Woche. Sobald die Registrierung möglich ist, können sich die Läufer über eine Internetanwendung für den Marathon anmelden. Es kann sich jeder für den Lauf anmelden, jedoch darf die maximale Teilnehmerzahl (100.000) nicht überschritten werden. Die Teilnehmer werden in der Reihenfolge registriert, in der sie sich anmelden.

Am Ende des Registrierungszeitraums aktiviert der Systemadministrator das Fakturierungssystem, das den registrierten Läufern die Teilnahmegebühren in Rechnung stellt.

Das Sponsoring findet im Verlauf der folgenden drei Wochen statt. Sponsoren können sich über die Internetanwendung registrieren und können die Läufer auswählen, die sie sponsern möchten.

Bei der Registrierung der Läufer und Sponsoren darf die Antwortzeit des Systems vom Zeitpunkt der Bestätigung durch den Anwender bis zur Anzeige der Bestätigungsseite nicht mehr als acht Sekunden betragen.

Alle Informationen zu den Läufern und Sponsoren sind in einer Datenbank gespeichert, die als zentrale Informationsquelle für alle anderen Softwarekomponenten des Marathon-Systems dient.

Die Veranstaltungsinformationen sind vor dem Marathon über die Internetanwendung zugänglich. Spezifische Fragen werden über das Customer-Relationship-Management-System (CRM-System) und den Helpdesk beantwortet.

Auf die Plätze, fertig, ...

Während des Laufs verfolgt das System die Position jedes Läufers.

Die Verfolgung geschieht mithilfe eines winzigen Laufgeräts (Transponders), das jeder Läufer am Arm trägt. Das Gerät empfängt GPS-Daten zur Positionsbestimmung und überträgt die Position des Läufers einmal pro Minute per Short Message Service (SMS).

Während des Marathons werden gewaltige Datenmengen verarbeitet.

Ein Kommunikationsserver empfängt die von den Transpondern verschickten SMS-Nachrichten, erstellt Positionsprotokolle und überträgt sie in eine Positionsdatenbank.

Ein Kostenkalkulationssystem berechnet auf Grundlage der Sponsoreninformationen und der aktuellen Position der gesponserten Läufer die Kostenprotokolle der Sponsoren. Es wird angenommen, dass nicht jeder Teilnehmer den Marathon beenden wird. In diesem Fall wird das Sponsorengeld entsprechend der zurückgelegten Distanz berechnet.

Ein Berichtsgenerator erstellt alle 10 Minuten einen Onlinebericht für die Internetanwendung und erzeugt einmal pro Minute Einzelberichte für die Läufer. Diese Einzelberichte werden momentan noch in Form einer E-Mail zur Übertragung an den Kommunikationsserver geschickt. Die Teilnehmer können diese Information dann während des Laufs über ihr Smartphone sehen.

Die E-Mail-Methode ist bei den Läufern nicht mehr allzu beliebt. Für die Zukunft ist daher eine Erweiterung geplant, bei der auch die Einzelberichte per SMS vom Berichtsgenerator verschickt werden können. Der Kommunikationsserver wird dann in der Lage sein, diese Nachrichten direkt an die Transponder zu verschicken.

Nach dem Lauf werden die Endberichte erstellt und die finanzielle Seite abgeschlossen.

Der Berichtsgenerator erstellt einen Endbericht zur Veröffentlichung über die Internetanwendung. Dieser Bericht enthält die Endpositionen und verschiedene Laufinformationen, wie z. B. die Anzahl der gestarteten Teilnehmer und der Teilnehmer, die den Lauf beendet haben, Wetterinformationen, den ältesten und den jüngsten Teilnehmer etc. Erstellt wird der vorläufige Bericht eine Stunde, nachdem der erste Läufer die Ziellinie überschritten hat. Fünf Stunden später, wenn der Lauf offiziell zu Ende ist, wird der Bericht aktualisiert.

Einen Tag nach dem Marathon startet der Systemadministrator die Fakturierungsanwendung. Diese Anwendung greift auf die Kostendatenbank zu und erstellt auf Grundlage der gesponserten Läufer und deren zurückgelegter Distanz die Rechnungen an die Sponsoren. Diese Rechnungen werden dann per E-Mail an die Sponsoren verschickt.

Einziehen der Sponsorengelder

Rechnungen werden nur auf Anfrage ausgedruckt und einer Poststelle zum Versand übergeben (manuelles System).

Die Überprüfung des Zahlungseingangs ist ausgelagert und fällt daher nicht unter unsere Anwendung.

Der Helpdesk steht weiterhin für Fragen oder Kritik zur Verfügung.

2.4 Verfügbarkeit des Marathon-Systems

Während der Anmeldewoche für die Läufer, den Registrierungswochen für die Sponsoren und am Tag des Marathons selbst muss das System rund um die Uhr zur Verfügung stehen.

Ab dem Tag nach dem Marathon müssen dem Helpdesk/CRM-System alle Daten eine Woche lang zwischen 8 und 20 Uhr zugänglich sein. Danach müssen die Daten mindestens für 2 Jahre archiviert werden.

2.5 Erweiterungen vorbehalten

Wie Sie sehen, bietet dieses Projekt interessante Herausforderungen für den Tester. Um jedoch sicherzugehen, dass wir unsere Testtechniken auf eine realistische Situation anwenden, behalten wir uns das Recht vor, dieses Projekt durch Änderungswünsche in letzter Minute komplizierter zu machen. Willkommen in der Wirklichkeit!

3 Systemarten

Test Analyst und Technical Test Analyst müssen die Arten von Systemen kennen, mit denen sie zu tun haben, und wissen, welche Auswirkungen diese verschiedenen Arten auf die Vorgehensweise beim Testen haben. Außerdem müssen sie den Gesamtprozess des Tests kennen und wissen, was sie in den einzelnen Schritten beitragen. Außerdem sind gute Kenntnisse von risikoorientiertem Testen und Risikomanagement für Projekt- und Produktrisiken für Test Analysts sehr wertvoll.

3.1 Einführung

Die Teststrategien hängen von der Art des zu testenden Systems ab.

Als Tester begegnet man einer Vielzahl unterschiedlicher Systeme. Jedes System bringt unterschiedliche Risiken mit sich, die eine bestimmte Auswahl von Teststrategien nach sich ziehen. Eine ausführliche Behandlung konkreter Systemarten und deren Architekturen würde den Rahmen eines Buches über Testanalyse deutlich sprengen. In den folgenden Abschnitten wollen wir jedoch bestimmte Systemarten beschreiben, die eine wichtige und unmittelbare Auswirkung auf die Qualitätsmerkmale haben, mit denen wir uns im Rahmen der Teststrategien befassen. Wir werden die folgenden Systemarten erläutern:

Multisysteme

Sicherheitskritische Systeme

Echtzeit- und eingebettete Systeme

3.1.1 Multisysteme

Wir stehen heute häufig vor der Aufgabe, ein Multisystem zu testen. Wir fassen im Folgenden in mehreren Punkten für Sie zusammen, was diese Systeme zu einer großen Herausforderung für alle am Testprozess Beteiligten macht.

Die Architektur eines solchen Systems besteht aus mehreren Einzelkomponenten, die selbst als Systeme bezeichnet werden können. Diese Komponenten arbeiten zum Vorteil eines bestimmten Stakeholders (z. B. des Geschäftseigentümers) zusammen. Die Komponenten des Gesamtsystems bestehen in der Regel aus verschiedenen Softwareanwendungen oder -services, einer Kommunikationsinfrastruktur und Hardwaregeräten. Diese können wiederum durch Softwareanwendungen unterstützt sein.

Das Marathon-Beispiel ist ein »System von Systemen«.

Ein Multisystem wird nach dem Baukastenprinzip entwickelt. Einzelne Komponenten werden zusammengefügt, sodass ganze Systeme geschaffen werden können, ohne Anwendungen neu entwickeln zu müssen. Ein Multisystem besteht häufig aus wiederverwendbaren Softwarekomponenten, Drittanwendungen, kommerziellen Softwareprodukten und verteilten Geschäftsobjekten.

Bei diesem Konzept können auf der einen Seite bei der Entwicklung Kosten gespart werden, auf der anderen Seite steigen jedoch die Ausgaben für den Testprozess erheblich. Worin liegen die Gründe?

Hohe Komplexität

Komplexität ist eine inhärente Eigenschaft der Multisysteme. Die Ursachen hierfür liegen z. B. in der eingesetzten Systemarchitektur, den unterschiedlichen Lebenszyklusmodellen, die für einzelne Anwendungsentwicklungen verwendet werden, und in den komplexen Kompatibilitätsfragen sowohl technischer als auch funktionaler Natur (Wie passen die Bausteine zusammen?). Professionelle Tester wissen, dass Komplexität das Produktrisiko in starkem Maße begünstigt. Bei hoher Komplexität erwarten wir generell, dass mehr Produktfehler vorkommen – sowohl funktionaler als auch technischer Art.

Aufwand der Fehlerlokalisierung

Die Fehlerlokalisierung kann innerhalb eines Multisystems eine technische und organisatorische Herausforderung darstellen. Es kann sehr viel Zeit und Mühe kosten, Fehler zu lokalisieren, da die Tester in der Regel keinen unbeschränkten Zugang zu allen Systemkomponenten haben. Daher ist es teilweise nicht möglich, eine detaillierte Analyse durchzuführen oder an gewünschten Orten Monitore zur Überwachung zu installieren.

Systemintegrationstests spielen eine entscheidende Rolle.

Weitere Integrationstests können notwendig sein

Während die Entwicklung eines Einzelsystems nur eine einzige Integrationsteststufe erfordert, kommt bei den Multisystemen auf der Ebene zwischen den Systemen eine zusätzliche »Schicht« von Integrationstests hinzu. Diese Teststufe, oft Systemintegrationstest genannt, kann die Entwicklung von Simulatoren notwendig machen, die als Platzhalter fehlender Komponenten dienen.

Höherer Managementaufwand

Zusätzlicher Aufwand entsteht aus Managementsicht oft durch die vielen organisatorischen Einheiten, die an der Entwicklung eines Multisystems beteiligt sind und unter einen Hut gebracht werden müssen. Diese Einheiten können verschiedene Produktlieferanten, Dienstleistungsunternehmen und vielerlei andere Anbieter sein, die nicht unmittelbar in das Projekt involviert sein müssen. Dies kann es schwierig machen, eine kohärente Managementstruktur zu schaffen, wodurch es wiederum schwierig wird, Verbindlichkeit und Verantwortlichkeit für das Testen zu etablieren. Test Analysts müssen sich dessen bewusst sein, wenn sie bestimmte Tests entwerfen – z. B. bei End-to-End-Tests von Geschäftsprozessen. Wenn ein Anwender zum Beispiel eine Transaktion initiiert, kann es sein, dass sich die technische und organisatorische Verantwortung für diese Transaktion mehrfach ändert und auf Systemen abgeschlossen wird, die völlig außerhalb der Kontrolle der ursprünglichen Organisation liegen.

Keine übergeordnete Kontrolle

Da es nicht immer möglich ist, Kontrolle über alle Systemkomponenten zu haben, werden für bestimmte Komponenten üblicherweise Softwaresimulationen entwickelt, um die Systemintegrationstests mit einem gewissen Grad an Sicherheit durchführen zu können. Aus den gleichen Gründen muss der Testmanager auch gut definierte Unterstützungsprozesse wie z. B. ein Release-Management einrichten, damit die Software in kontrollierter Weise von externen Quellen an das Testteam geliefert werden kann. Test Analysts müssen mit diesen Unterstützungsprozessen arbeiten, sodass Tests z. B. in Übereinstimmung mit definierten Releases und Basisdaten entwickelt werden.

Das Marathon-Beispiel besitzt viele Eigenschaften eines Multisystems:

Individuelle Komponenten wie z. B. das CRM-System können selbst als System betrachtet werden.

Die verwendeten Systemkomponenten bestehen aus verschiedenen Softwareanwendungen (z. B. Fakturierungssystem) und software-getriebenen Hardwaregeräten (z. B. Transponder).

Zwei der Anwendungen (CRM-System und Fakturierungssystem) sind kommerzielle Produkte, die vielleicht noch nie zusammen innerhalb eines Multisystems wie dem Marathon-System eingesetzt worden sind. Dies macht Systemintegrationstests umso notwendiger.

3.1.2 Sicherheitskritische Systeme

Als sicherheitskritisch bezeichnet man ein System, bei dem das Auftreten eines Fehlers Leben gefährden oder zu anderen schweren Verlusten führen kann. In der Regel wird der Kritikalitätsgrad eines Projekts entweder im Rahmen der Machbarkeitsstudie eingeschätzt oder er geht aus anfänglichen Risikomanagement-Aktivitäten hervor. Der Test Analyst und der Technical Test Analyst müssen wissen, wie die Kritikalität des Projekts eingeschätzt wurde und vor allem, ob es als sicherheitskritisches System eingestuft wurde.

Sicherheitskritische Systeme erfordern gründlicheres Testen.

Die Strategien, die wir für das Testen sicherheitskritischer Systeme anwenden, stimmen im Allgemeinen mit den in diesem Buch behandelten Strategien überein. Das Testen sicherheitskritischer Systeme unterscheidet sich jedoch durch die höhere Gründlichkeit, mit der Testaufgaben erfüllt werden müssen. Diese höhere Gründlichkeit bestimmt daher auch unsere Teststrategien. Im Folgenden sind einige der Aufgaben und Strategien aufgelistet:

Durchführen einer detaillierten Sicherheitsanalyse als Teil des Risikomanagements. Die Fehlermöglichkeits- und -einflussanalyse (FMEA) kann diese Aufgabe unterstützen (weitere Informationen siehe Abschnitt 3.10 im Advanced-Level-Lehrplan).

Durchführen von Tests anhand eines definierten Lebenszyklusmodells wie z. B. dem V-Modell.

Durchführen von Failover- und Wiederherstellungstests, um sicherzustellen, dass die Softwarearchitekturen korrekt entworfen und implementiert worden sind.

Durchführen von Zuverlässigkeitstests, um niedrige Ausfallraten und einen hohen Grad an Verfügbarkeit zu belegen.

Ergreifen von Maßnahmen, anhand derer die vollständige Erfüllung der Sicherheitsanforderungen überprüft wird.

Zeigen, dass Defekte korrekt gehandhabt werden.

Nachweisen, dass ein bestimmter Überdeckungsgrad erreicht wurde.

Erstellen einer vollständigen Testdokumentation mit lückenloser Rückverfolgbarkeit zwischen Anforderungen und Testfällen.

Aufbewahren der Testdaten, Ergebnisse und Testumgebungen (für eventuelle Audits).

Bei sicherheitskritischen Systemen gelten oft branchenspezifische Standards.

Wie die folgenden Beispiele zeigen, werden diese Aspekte oft durch branchenspezifische Standards geregelt:

Raumfahrtindustrie

Die Europäische Kooperation für Raumfahrtnormung (ECSS) [URL: ECSS] empfiehlt Methoden und Techniken abhängig von der Kritikalität der Software.

Nahrungs- und Arzneimittelindustrie

Die US-Bundesbehörde zur Überwachung von Nahrungs- und Arzneimitteln (FDA) empfiehlt bestimmte strukturelle und funktionale Testtechniken für medizinische Systeme gemäß Titel 21 des CFR (Bundesverordnungsbuch), Teil 820.

Luftfahrzeugindustrie

Die internationalen Joint Aviation Authorities (JAA) definieren auf Grundlage der ermittelten Softwarekritikalität den Grad und die Art der strukturellen Überdeckung, die für Luftfahrzeugsoftware nachgewiesen werden muss.

Der Testmanager gibt an, wie sicherheitskritisch das zu testende System und die zu testende Software sind und ob besondere Standards gelten. Wir wiederum müssen unsere Tests gemäß diesen Standards entwerfen und den Testmanager unterstützen, indem wir die Einhaltung der Standards nicht nur innerhalb des Testprojekts, sondern eventuell auch externen Prüfern darlegen können.

3.1.3 Echtzeit- und eingebettete Systeme

Echtzeitsysteme enthalten in der Regel bestimmte Komponenten, deren Befehlsausführungszeiten für das Funktionieren des gesamten Systems von zentraler Bedeutung sind. Die Aufgabe dieser Komponenten kann es zum Beispiel sein, mit einer hohen Aktualisierungsrate Daten zu berechnen (z. B. 50 Mal pro Sekunde), auf bestimmte Ereignisse innerhalb einer minimalen Zeitspanne zu reagieren oder Prozesse zu überwachen.

Eingebettete Systeme begegnen uns überall.

Software, die in Echtzeit reagieren muss, ist häufig in eine Hardwareumgebung »eingebettet«. Dies ist bei vielen alltäglichen Konsumartikeln wie z. B. Mobiltelefonen und auch in sicherheitskritischen Systemen wie der Luftfahrtelektronik der Fall.

Echtzeit- und eingebettete Systeme stellen eine besondere Herausforderung für den Technical Test Analyst dar. Zum Beispiel:

Spezifische Testtechniken können notwendig sein, um z. B. Race Conditions (ständig wiederkehrende Bedingungen) aufzudecken.

Eine dynamische, werkzeuggestützte Analyse muss festgelegt und durchgeführt werden (siehe Abschnitt 15.2 »Dynamische Analyse«).

Eine Testinfrastruktur muss zur Verfügung gestellt werden, die es ermöglicht, eingebettete Software auszuführen und Ergebnisse zu erhalten.

Es kann notwendig werden, Simulatoren und Emulatoren zu entwickeln und zu testen, die während des Testprozesses eingesetzt werden (weitere Einzelheiten siehe Abschnitt 23.6.7).

4 Aufgaben des Test Analyst für das Testmanagement

Testmanagement ist Sache der Testmanager, aber ohne angemessene, korrekte und aktuelle Daten können sie diese Aufgabe nicht erfüllen. Außerdem brauchen sie Informationen für ein an Risiken orientiertes Testverfahren. Neben solchen Informationen wird vom Test Analyst manchmal auch erwartet, in Umgebungen zu arbeiten, die hervorragende Kommunikationsfähigkeiten und -techniken erfordern. Das Management von Testprojekten ist eine Teamaufgabe, und nur bei guter Zusammenarbeit kann das Projekt bis zu einem erfolgreichen Ende geführt werden.

In diesem Kapitel verwendete Begriffe:

Produktrisiko, Risikoabschwächung, Risikoanalyse, Risikoidentifizierung, Risikomanagement, Risikoniveau, risikoorientiertes Testen, Test-strategie, Testüberwachung

4.1 Einführung

Test Analysts gehören zu den Mitarbeitern, die die meisten Daten produzieren. Angesichts all der Zeit, die wir mit der Dokumentation unserer Tätigkeiten zubringen, ist es schön zu wissen, dass diese Daten auch tatsächlich irgendwo landen. Wie oft haben Sie bei der Eingabe eines Fehlerberichts angesichts der vielen auszufüllenden Felder schon laut aufstöhnen müssen? Haben Sie sich auch schon gefragt, ob diese Informationen überhaupt jemals verwendet werden? Willkommen im Club! Ich kenne keine Tester, die sich noch nicht über die Menge der von ihnen verlangten Dokumentation beschwert hätten (bis auf die Tester, die gar keine Dokumentation durchführen, aber das ist ein anderes Problem). Wir sind uns also darüber einig, dass Dokumentation ein notwendiges Übel ist oder zumindest ein Ärgernis, wenn man nicht gleich von einem Übel sprechen will.

In diesem Kapitel sehen wir uns an, warum wir unsere Zeit mit der Verfolgung von Daten zubringen, wie diese Informationen verwendet werden und warum sie wirklich von Bedeutung sind (nicht etwa nur, weil Ihr Vorgesetzter diese Dokumentation von Ihnen verlangt).

4.2 Überwachung und Steuerung des Projekts

Testprojekte werden überwacht, um festzustellen, ob sie wie erwartet voranschreiten. Manchmal entwickeln sie sich besser, manchmal schlechter als gedacht, aber nur selten folgen sie exakt dem vorgesehenen Plan. Es gibt viele Techniken zur Abschätzung, aber letzten Endes ist jedes Projekt einzigartig und bringt seine eigenen Probleme und Triumphe mit sich. Gute Test Analysts und gute Testmanager schöpfen Verdacht, wenn ein Projekt reibungslos abläuft und genau im Zeitplan liegt. Das mag daran liegen, dass wir kein Vertrauen in andere Leute setzen, aber auch daran, dass wir realistische Erwartungen hegen. Glauben Sie mir: Seien Sie vorsichtig bei Projekten, die im Zeitplan liegen.

Aber genug der negativen Gedanken! Sehen wir uns nun an, welcher Art die Daten sind, die verfolgt werden, und wie sie zur Testüberwachung eingesetzt werden. Eine wichtige Aufgabe von Test Analysts besteht darin, genaue Informationen herauszufinden und zu melden. Die Motivation dafür steigt, wenn Sie genau wissen, wie und warum diese Daten verwendet werden und wie die von Ihnen beigesteuerten Informationen den Lauf des Projekts beeinflussen können.

4.2.1 Produkt(qualitäts)risiken

Jegliche Software ist von Natur aus mit Risiken behaftet. Sie ist kompliziert, sie läuft in vielen verschiedenen Umgebungen und Konfigurationen, sie bringt Voraussetzungen mit, die möglicherweise nicht ganz verstanden sind. Die Liste lässt sich noch beliebig verlängern. Wenn wir immer alles testen könnten, müssten wir keine Prioritäten festlegen. Natürlich würden wir dann wahrscheinlich niemals irgendetwas liefern, da wir nie fertig würden, aber nichtsdestoweniger ist es eine schöne Vorstellung, alles prüfen zu können. In der Realität dagegen haben wir keine Zeit, um alles testen, und müssen daher festlegen, was geprüft wird und mit welcher Gründlichkeit das geschieht.

Im Rahmen des risikoorientierten Testens wird vom Test Analyst erwartet, sich an der Identifizierung der Projektrisiken, der Bewertung dieser Risiken und ihrer Abschwächung zu beteiligen. Ebenso wie wir keine erschöpfenden Tests durchführen können, sind wir nicht in der Lage, alle Risiken komplett abzudecken. Wir können nur ein gewisses Maß an Abdeckung der erkannten Risiken erreichen. Dieses Maß an Abdeckung wird durch das vereinbarte Risikoniveau für ein Element, den gewünschten Abdeckungsgrad und die verfügbare Zeit bestimmt. Es ist gut, sich vor Beginn einer Risikoanalyse darüber im Klaren zu sein, dass wir Prioritäten setzen müssen, da einige Elemente nur minimal oder gar nicht abgedeckt werden, während andere unsere volle Aufmerksamkeit erhalten. Der Trick besteht darin, herauszufinden, was für welches Element gilt. Risikomanagement ist gewöhnlich ein dreistufiger Vorgang, in dem wir zuerst die Risiken identifizieren, dann die Risiken bewerten und schließlich eine Planung zur Beherrschung der Risiken aufstellen.

Risiken identifizieren

Bei der Identifizierung von Risiken geht es darum, die Sachen herauszufinden, die uns Angst einflößen.

Erinnern Sie sich noch daran, wie Sie als kleines Kind (oder vielleicht auch als nicht ganz so kleines Kind) Angst vor Ungeheuern hatten, die sich im Kleiderschrank versteckten? Natürlich wollten Sie nicht nachsehen gehen, da die Monster sie dabei anspringen konnten, weshalb Sie sich unter Ihre Zauberbettdecke verkrochen, unter der Sie geschützt waren. Das können wir auf Risiken in der Software übertragen. Die Risiken sind die Monster, und der Schrank ist die Masse an Code, die Sie testen, und das Projektframework. Das Öffnen der Schranktür entspricht der Identifizierung und Bewertung der Risiken. Unsere Testfälle und Testtechniken bilden die Zauberbettdecke. Im Gegensatz zu unserer guten, alten Bettdecke aber, die alle Monster abwehren konnte, lassen unsere Testfälle einige Risiken unerkannt durchschlüpfen. Risikoorientiertes Testen ist keine perfekte Lösung, gibt uns aber eine Möglichkeit an die Hand, um der Behandlung der wichtigsten Risiken die höchste Priorität einzuräumen.

Wir wollen die Risiken identifizieren, sodass wir sie hervorlocken, untersuchen und nach Prioritäten ordnen sowie bestimmen können, was wir mit ihnen tun sollen. Für eine gute Risikoidentifizierung sollte eine breite Palette von Stakeholdern einbezogen werden, die jeweils ihren eigenen Gesichtspunkt beitragen. Personen aus dem technischen Support nehmen andere Risiken wahr als Entwickler und Leute aus dem geschäftlichen Bereich. Als Test Analysts bringen wir unsere eigene Kenntnis der Software, des Fachbereichs, der Kunden und anderer Projekte ein, um dabei zu helfen, so viele Risiken wie möglich zu identifizieren. Wir können Gespräche mit Fachexperten und Benutzern führen, um die Umgebung des Projekts besser zu verstehen. Wir können unabhängige Bewertungen durchführen, um bei der Auswertung und Identifizierung möglicher Risiken zu helfen. Wir können Risiko-Arbeitskreise und Brainstorming-Sitzungen leiten, um Beiträge von den Benutzern (oder potenziellen Benutzern) über ihre jeweiligen Gebiete und möglichen Risikobereiche zu gewinnen. Wir können sogar Test-checklisten verwenden, die sich in der Vergangenheit als nützlich erwiesen haben, um uns auf die Bereiche zu konzentrieren, die schon seit jeher als »riskant« angesehen wurden. Und natürlich können wir auch unsere Erfahrungen aus früheren Projekten einsetzen, die dem vorliegenden Projekt in der einen oder anderen Weise ähnelten. Probleme neigen dazu, immer wieder aufzutreten, weshalb die Betrachtung früherer Projekte eine sinnvolle Möglichkeit ist, um die Risiken zukünftiger Projekte zu identifizieren.

Für Test Analysts liegt der Schwerpunkt auf Geschäftsrisiken, für Technical Test Analysts auf technischen Risiken. Unser Anliegen besteht darin, nach Elementen zu suchen, die die Kunden in ihren Fähigkeiten, ihre Geschäftsziele zu erreichen, beeinträchtigen. Diese Elemente können einen großen Bereich an Testgebieten abdecken. Beispielsweise kann ein Problem mit der Genauigkeit der Berechnung von Hypothekenraten für Banken und Kreditinstitute eine Katastrophe darstellen. Für ein kleines E-Commerce-Unternehmen sind Genauigkeitsprobleme bei Bestellmengen ein erhebliches Risiko. Usability-Schwierigkeiten wie die falsche Tabulatorreihenfolge bei Feldern oder schwer zu erlernende Software stellen große Probleme für Kunden dar, die für benutzerfreundliche und leicht erlernbare Produkte bekannt sind.

Risiken können überall in der Software lauern. Es ist wichtig, sich darüber im Klaren zu sein, dass Sie sich nicht allein auf die Funktionalität konzentrieren dürfen. Ich habe schon Software kennengelernt, die aufgrund ihrer komplizierten Schnittstelle für mich nicht verwendbar war. Stellt das ein hohes Risiko dar? Die Hersteller haben damit einen Kunden verloren, was meiner Meinung nach schon ein ziemlich großes Risiko ist (zumindest sofern sie mich als Kunden wertschätzen).

Risiken bewerten

Nachdem wir die Risiken identifiziert haben, müssen wir sie untersuchen, kategorisieren und nach Rangfolge ordnen. Dazu werden gewöhnlich die Wahrscheinlichkeit für das Eintreten des Risikos und die Auswirkungen betrachtet, die dieser Vorgang auf die Kunden hat. Die Wahrscheinlichkeit lässt sich schwer abschätzen. Dazu müssen Sie berücksichtigen, ob das Problem in der Testumgebung erkannt werden kann und ob es erkannt wird, wenn es in der Produktionsumgebung auftritt. Manche Risiken sind nur in einer dieser Umgebungen offensichtlich. Beispielsweise kann es in der Testumgebung ein Problem mit der Netzwerklatenz geben, nicht aber in der Produktion, da das dortige Netzwerk anders konfiguriert ist. Es ist wichtig, zwischen Risiken zu unterscheiden, die in beiden Umgebungen auftreten, und solchen, die nur in einer vorkommen. Wenn ein Problem nur in der Testumgebung ein Risiko darstellt, wie wichtig ist es dann? Wenn es den gesamten Testvorgang zum Erliegen bringt, ist es sehr wichtig. Wenn es sich nur auf die Usability auswirkt, spielt es keine Rolle. (Das kann beispielsweise der Fall sein, wenn ein Fenster auf den Bildschirmen in der Testumgebung nicht korrekt angezeigt werden kann, in der Produktionsumgebung aber richtig dargestellt wird.) Was geschieht, wenn sich ein Problem nur in der Produktionsumgebung zeigt? Wie können Sie Tests dafür durchführen? Probleme dieser Art aufzudecken, ist schwierig. Manchmal ist eine Abschwächungsstrategie die einzige Möglichkeit, mit ihnen umzugehen.

Die Wahrscheinlichkeit des Auftretens ist gewöhnlich ein Ergebnis des technischen Risikos. Auf dieser Ebene erfolgt die Bewertung in der Regel durch den Technical Test Analyst, wobei der Test Analyst jedoch mit Sicherheit dazu beitragen kann, die Auswirkungen zu verstehen, die das Eintreten des Risikos auf das Geschäft hat. Diese Auswirkungen lassen sich jedoch schwer beurteilen. Sie werden als Geschäftsrisiko interpretiert. Da wir als Test Analysts ein gutes Verständnis des Geschäfts und des Fachbereichs haben, sind wir aber zum Glück gut ausgerüstet, um die Auswirkungen auf das Geschäft zu beurteilen.

Viele Faktoren beeinflussen die Bewertung des Geschäftsrisikos. Betrachten wir als Beispiel eine Software zur Ampelsteuerung, bei der das Risiko besteht, dass gleichzeitig alle Fahrtrichtungen grün bekommen. Das wäre wirklich schlimm, oder? Wie aber können wir die einzelnen Bereiche bewerten?

Häufigkeit der Verwendung

Sie ist sehr hoch, da unsere Ampeln an Kreuzungen mit hohem Verkehrsaufkommen stehen.

Geschäftliche Verluste

Würde das Unternehmen weitere Aufträge für Ampeln bekommen? Ich hoffe nicht!

Mögliche finanzielle, ökologische und soziale Verluste oder Haftbarkeit

Was geschieht mit dem Unternehmen, das diese fehlerhaften Ampeln hergestellt hat? Kommt es zu einem Gerichtsverfahren? Zivilrechtlich oder vielleicht sogar strafrechtlich wegen Fahrlässigkeit?

Zivil- oder strafrechtliche Sanktionen

Siehe den vorherigen Punkt.

Sicherheitsprobleme

Dies ist ein sicherheitskritisches Gerät. Bei einem Fehler dieser Größenordnung ist davon auszugehen, dass Menschen verletzt werden, sogar schwer.

Geldbußen, Lizenzverlust

Das ist wahrscheinlich, oder? Zumindest sollte so etwas die Folge sein.

Mangel an sinnvollen Notlösungen

Darüber müssen wir mit dem Rest des Teams sprechen. Was kann geschehen, wenn ein solcher Fehler auftritt? Gibt es eine Sicherheitssoftware, die die Ampel rot blinken lässt, wenn so etwas passiert? Wenn ja, kann das die Auswirkungen des Risikos senken (sofern die Sicherheitssoftware selbst zuverlässig ist).

Sichtbarkeit des Merkmals

Ein solcher Fehler macht sich deutlich bemerkbar, vor allem dann, wenn auch die Sicherheitssoftware ausfällt. Es wäre interessant, herauszufinden, wie lange die Software in dem fehlerhaften Status verbleibt, bis die Sicherheitssoftware eingreift. Reicht der Zeitraum dafür aus, dass ein Auto aus jeder Richtung in die Kreuzung einfahren kann? Wenn ja, wäre das immer noch eine Katastrophe.

Sichtbarkeit des Fehlers, die zu negativer Publicity und einer Imageschädigung führt

Ich weiß nicht, wie es Ihnen geht, aber ich wäre dagegen, Produkte dieser Firma weiterhin zu benutzen.

Kundenverluste

Ja, das ist mit Sicherheit ein Problem.

Nachdem wir Zahlen für das Geschäftsrisiko (Auswirkung) und das technische Risiko (Eintrittswahrscheinlichkeit) festgelegt haben, können wir sie addieren oder multiplizieren, um das Gesamtrisiko zu bestimmen. Wir können Sie auch separat angehen, um sicherzustellen, dass beide Ebenen angemessen behandelt werden. Wie sieht die Gesamtbewertung für ein Risiko aus, dessen Eintreten katastrophale Folgen hätte (und ihr Bankkonto leeren würde), das aber äußerst unwahrscheinlich ist? Wenn Sie Zahlen zur Bewertung verwenden und sie addieren oder multiplizieren, können Sie dabei die gleiche Gesamtbewertung erhalten wie für ein Risiko, das zwar sehr wahrscheinlich ist (falsche Ausrichtung der Spalten in einem Bericht), aber nur minimale Auswirkungen hat (der Bericht ist immer noch lesbar). Es gibt risikoorientierte Testmodelle wie PRISMA [van Veenendaal 12], die diese beiden Risikobewertungen getrennt behandeln und mit solchen Situationen möglicherweise besser umgehen können.

Risiken abschwächen

Was machen wir nun mit den Risiken, nachdem wir sie identifiziert und bewertet haben? Es gibt eine Reihe von Möglichkeiten, aber im Allgemeinen sollten wir als Erstes herausfinden, ob wir Testfälle für dieses Risiko erstellen können, um zu prüfen, ob es vorhanden ist oder nicht. Das kann es mit sich bringen, die Dokumentation der Anforderungen und des Designs sowie Benutzerrichtlinien zu untersuchen und auch sicherzustellen, ob Codereviews durchgeführt worden sind. Wenn wir Tests auf ein Risiko durchführen können, ist das eine Form von Abschwächung. Sollten wir dabei feststellen, dass es das identifizierte Risiko tatsächlich gibt, können wir etwas dagegen tun und es dadurch verringern. Noch besser ist es, wenn wir durch den Test herausfinden, dass das Risiko gar nicht vorhanden ist und wir aufhören können, uns darüber Sorgen zu machen. Je besser wir die Risikobereiche durch Tests abdecken, umso mehr Risikoabschwächung können wir leisten.

Tests sind nicht die einzige Möglichkeit zur Risikoabschwächung. Im Testkonzept oder in der Teststrategie können auch Tätigkeiten definiert sein, die uns bei der Risikoabschwächung helfen. Dabei kann es sich um die Durchführung von Reviews an festgelegten Punkten handeln oder wir können dafür sorgen, dass die Testdaten repräsentativ sind oder unsere Konfiguration und unsere Umgebung realistisch sind usw.

Vergessen Sie auch nicht, sich die identifizierten Risiken mit fort-schreitendem Projekt immer wieder anzusehen. Es kann sein, dass Sie bei dem Test auf ein bestimmtes Risiko festgestellt haben, dass es nicht existiert. Was aber, wenn sich der Code erheblich geändert hat oder die Architektur neu gestaltet wurde? Es kann erforderlich sein, den Test zu wiederholen, um sicherzugehen, dass das Risiko abgeschwächt ist. Es kann auch vorkommen, dass sich ein zuvor als gering eingestuftes Risiko als hoch erweist, weil wir inzwischen mehr Informationen zur Verfügung haben als bei der ursprünglichen Bewertung. Umgekehrt kann es auch sein, dass sich eine vermeintlich starke Auswirkung als weniger stark erweist (etwa weil wir feststellen, dass der betroffene Teil der Software nur selten genutzt wird). Risiken sind nicht statisch, sondern verändern sich. Sie müssen regelmäßig neu bewertet werden, um sicherzustellen, dass die Bewertungen korrekt sind.

Was geschieht, wenn Sie etwas entdecken, das eindeutig ein Risiko ist, aber nicht als solches betrachtet wurde? Sie müssen dafür sorgen, dass es in die Risikoabschätzung aufgenommen und bewertet wird, und ggf. einen Abschwächungsplan aufstellen.

Wenn Sie zur Abschwächung identifizierter und bewerteter Risiken Tests durchführen, müssen Sie Prioritäten für die Tests aufstellen, da nur selten ausreichend Zeit für Tests vorhanden ist. Das Ziel bei dieser Priorisierung besteht darin, die wichtigsten Risiken so früh wie möglich anzugehen. Das mag offensichtlich erscheinen, aber sobald die Tests beginnen, neue Merkmale hinzukommen und Fehler den Fortschritt hemmen, kann man nur allzu leicht den Überblick über die Prioritäten verlieren. Nachverfolgbarkeit vom Risikoelement zu den Testfällen kann dabei helfen, die Abschwächungsaktivitäten deutlich nachvollziehbar zu machen. Wie wir alle wissen, stimmen hübsche Diagramme die Geschäftsleitung fröhlich – insbesondere wenn diese Diagramme viel Grün enthalten.

Im Idealfall sollten die Testfälle zu den Elementen mit höherem Risiko vor denen für die geringeren Risiken ausgeführt werden. Hier spricht man manchmal vom Depth-first-Vorgehen, da die Tests auf der Grundlage des Risikoniveaus tief in die Funktionalität vordringen. Es kann jedoch auch sinnvoll sein, die Tests über alle Risikobereiche hinweg vorzunehmen, also einen sogenannten Breadth-first-Ansatz zu verfolgen. Da die Tester die Auswahl der Tests dabei immer noch anhand des Risikos gewichten, aber auch sicherstellen, dass alle Risiken (unabhängig von der Bewertung) mindestens einmal überprüft werden, kann dadurch eine breitere Abdeckung erreicht werden. Breadth-first-Tests helfen dabei, Risiken zu identifizieren, die noch nicht korrekt klassifiziert wurden (indem sie z. B. als zu gering eingestuft wurden). Bei der Depth-first-Vorgehensweise schwächen Sie zunächst alle hohen Risiken ab, dann die mittleren und schließlich die geringen. Wenn die Priorisierung der Risiken korrekt vorgenommen worden ist, bietet diese Option die vollständigste und zielgerichtetste Möglichkeit zur Risikoabschwächung.

Es wird Zeit, um mit der Planung für das Wartungsrelease zu beginnen!

Was aber, wenn Ihnen die Zeit davonläuft? Das ist durchaus realistisch, denn wir haben meistens nicht genug Zeit, um alle Tests vorzunehmen. In einer zeitkritischen Umgebung ist das wahrscheinlich der Grund, aus dem Sie überhaupt risikoorientiert testen. Wenn Sie einen solchen risikoorientierten Ansatz verfolgen und dabei eine gute Nachverfolgbarkeit von Risikoelementen zu Testfällen gewährt ist, können Sie, wenn die Zeit knapp wird, leicht erkennen, wie viele Risiken bereits abgeschwächt sind und welche Risikoelemente noch nicht behandelt wurden. Das liefert die Informationen, die Entscheidungsträger brauchen, um zu bestimmen, ob mehr Zeit für Tests bereitgestellt werden soll oder ob das Restrisiko akzeptabel ist.

Wie bereits erwähnt können sich Risiken im Verlauf eines Projekts ändern – und damit auch die Risikostrategie. Nehmen wir an, Sie haben zu Beginn des Projekts entschieden, dass Sie für jedes Element mit hohem Risiko 20 Testfälle brauchen, müssen aber im weiteren Verlauf feststellen, dass Sie nicht den erwarteten Fortschritt erzielen. Daher kann es sinnvoll sein, die Rate auf zehn Testfälle für jedes Hochrisikoelement zu beschneiden, um mehr Risikoelemente abdecken zu können. Sie müssen auch alle neu entdeckten Risiken sowie die Bereiche der Software bedenken, die stärker geändert wurden als erwartet. Die Behebung von Fehlern kann neue Risiken hervorbringen. Ich habe schon einige denkwürdige Unterhaltungen mit Entwicklern geführt, bei denen ich sie über Tests für einzelne Reparaturen befragte. Besonders im Gedächtnis haften geblieben ist mir ein Entwickler, der nur den Kopf schüttelte, mich anschaute und sagte: »Am besten testen Sie alles noch mal neu. Die Änderung war so weitreichend, dass nicht einmal ich sicher bin, was davon alles beeinflusst worden sein mag.« Das ist natürlich nicht gerade das, was Sie hören wollen, aber es zeigt Ihnen, dass es jetzt einen großen Risikobereich gibt, der nicht vorhergesehen war.

Wenn Sie herausfinden wollen, ob Sie den Risikoansatz für den nächsten Testzyklus ändern müssen, können Sie auch die Arten der Fehler untersuchen, die bisher gefunden wurden. Zeigen sich dabei Fehlerhäufungen, die auf bestimmte Risikogebiete hindeuten? Sind Korrekturen zu finden, die zusätzliche Probleme hervorgerufen haben? Wenn Sie sich Messwerte ansehen, sollten Sie auch einen Blick auf die Bereiche mit unzureichender Testabdeckung werfen. Solche Bereiche können entstehen, wenn Teile des Codes zum vorgesehenen Zeitpunkt nicht verfügbar waren, wenn bestimmte Konfigurationen oder Hardware nicht bereitstanden oder wenn der Testzeitplan selbst aus den Fugen geraten ist. Unzureichend getestete Bereiche sind von Natur aus risikobehaftet, da sie Fehler enthalten können, die den Zeitplan gefährden.

Erfahrungsbericht:Aber ich habe doch nur ein einziges Zeichen geändert!

Da wir gerade von Risiken sprechen: Können Sie den Entwicklern zutrauen, das Risiko einer Änderung oder auch nur das Risiko in einem bestimmten Bereich des Codes korrekt zu identifizieren? Das hängt natürlich vom Entwickler und von der Situation ab, aber ich rate Ihnen zur Vorsicht. Ich habe einmal mit einem sehr erfahrenen Entwickler zusammengearbeitet, der die Architektur des zu testenden Systems entworfen hatte.