Praxiswissen Softwaretest - Test Analyst und Technical Test Analyst: Aus- und Weiterbildung zum Certified Tester - Advanced Level nach ISTQB-Standard

Von Graham Bath und Judy McKay

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.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 3. März 2015
• ISBN: 9783864916403

Graham Bath

Graham Bath's experience in testing spans over 25 years and has covered a wide array of domains and technologies. As a test manager, he has been responsible for the testing of mission-critical systems in spaceflight, telecommunications, and police incident control. Graham has designed tests to the highest levels of rigor within real-time aerospace systems such as the Eurofighter military aircraft. As a principal consultant for the T-Systems Global Delivery Unit "Testing Services," he has mastered the Quality Improvement Programs of several major companies, primarily in the financial and government sectors. In his current position, Graham is responsible for the company's training and test-consulting programs. Graham is co-author of the ISTQB Expert Level syllabus, Improving the Test Process. He is a long-standing member of the German Testing Board and is chairman of the ISTQB Expert Level working group.

Buchvorschau

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 Goericke

CEO

International 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 wurden¹. 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:

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])¹ 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.

Es gibt gewöhnlich eine Klassifizierung oder Bewertung für die einzelnen Risikoelemente, z. B. in Form vorn Wörtern (sehr hoch, hoch, mittel usw.) oder Zahlen. Denken Sie aber daran, dass eine echte quantitative Bewertung ohne eine Menge von Informationen nur sehr schwer zu erreichen ist. (Beispielsweise haben die Leute, die die Risikoberechnungen für Lebensversicherungen durchführen, riesige Mengen von Daten zur Verfügung, sodass sie eine echte quantitative Bewertung erreichen können.) Wir anderen verwenden zwar Zahlen, doch stellen diese Zahlen auch nur eine qualitative Bewertung dar, da sie jeweils einer qualitativen Bewertung entsprechen, z. B. 1 = sehr hohes Risiko.

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