praxiswissen softwaretestdownload.e-bookshelf.de/download/0000/4043/05/l-g...mit denen wir in...
TRANSCRIPT
Praxiswissen Softwaretest – Test Analyst und Technical Test Analyst
Graham Bath ist seit über 25 Jahren in der Welt des Software-testens tätig. Seine Erfahrung und Expertise umspannen eine breite Palette verschiedener Fachgebiete und Technologien. Als Testmanager trug er die Verantwortung für das Testen missions-kritischer 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 Echt-zeit-Luftfahrtsysteme, z.B. für die Militärflugzeuge Tornado und Eurofighter.
Als einer der Hauptberater der T-Systems Test Factory leitete er die Qualitätsförderungsprogramme mehrerer großer Unterneh-
men, insbesondere im Finanz- und Regierungssektor. In seiner aktuellen Position ist Graham Bath für das Fortbildungsprogramm des Unternehmens verantwortlich und führt die Test-experten der Test Factory in innovative Testlösungen ein.
Graham Bath ist Mitverfasser des Lehrplans zum ISTQB-Advanced-Level. Er ist ein langjäh-riges Mitglied des German Testing Board und Vorsitzender der zugehörigen Arbeitsgruppe für den Advanced-Level-Lehrplan.
Judy McKay ist seit 20 Jahren mit dem Schwerpunkt Software-qualitätssicherung in der Hightech-Branche tätig. Ihre Berufspraxis deckt alle Aspekte des Softwarelebenszyklus ab. Hierzu zählen Bedarfsentwurf und -analyse, Softwareentwicklung, Datenbank-entwurf, Sicherung der Softwarequalität, Softwaretests, technische Kundenbetreuung, Fachleistungen, Konfigurationsmanagement, technische Veröffentlichungen und Softwarelizenzierung. Judy McKay hat in kommerziellen Softwareunternehmen, der Raum-fahrtbranche, internationaler Forschung und Entwicklung, Vernet-zungsprojekten 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ätssicherungssteams, der Entwurf und die Implementierung von Quali-tätssicherung und effektiven Tests sowie die Erstellung und Implementierung aussagekräfti-ger Testdokumentationen und Metriken. Sie ist Mitverfasserin des Lehrplans zum ISTQB-Advanced-Level und Mitglied im Sachverständigenrat des American Testing Board. Sie ist Autorin des Buches Managing the Test People (RockyNook).
Graham Bath · Judy McKay
Praxiswissen Softwaretest – Test Analyst und Technical Test Analyst
Aus- und Weiterbildung zum Certified Tester – Advanced Level nach ISTQB-Standard
Graham Bath, [email protected] Judy McKay, [email protected]
Lektorat: Christa Preisendanz Übersetzung: Julia Neumann, www.textart-translations.com Copy-Editing: Ursula Zimpfer, Herrenberg Herstellung: Nadine Thiele Umschlaggestaltung: Helmut Kraus, www.exclam.de Druck und Bindung: Media-Print Informationstechnologie, Paderborn
Bibliografische Information der Deutschen NationalbibliothekDie 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-89864-735-9PDF 978-3-86491-036-4ePub 978-3-86491-037-1
2., durchgesehene Auflage 2011 Translation copyright für die deutschsprachige Ausgabe © 2010 dpunkt.verlag GmbH Ringstraße 19 B 69115 Heidelberg
Copyright der amerikanischen Originalausgabe © 2008 by Graham Bath and Judy McKay Title of American original: The Software Test Engineer's Handbook Rocky Nook Inc., Sants Barbara, www.rockynook.com ISBN 978-1-933952-24-6
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
Fachliche Beratung und Herausgabe von dpunkt.büchern zum Thema »ISTQB® Certified Tester«: Prof. Dr. Andreas Spillner · [email protected]
v
Geleitwort
Softwaretest etabliert sich als eine der Grundfesten der Qualitätssiche-rung in Unternehmen. Damit Tester dieser essenziellen Rolle gerecht werden können, bedarf es einer fundierten Qualifizierung zur Profes-sionalisierung des Softwaretestens. Mit dem international anerkannten »ISTQB Certified Tester«-Weiterbildungsprogramm existiert ein Bran-chenstandard, 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 Testpro-jekten unter Beweis gestellt, sind »ISTQB Foundation Level«-zertifi-ziert 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. Die Autoren haben sich große Verdienste bei der Weiterentwicklung des Certified-Tester-Schemas erworben. Dieses Buch komplettiert die Reihe der Module des ISTQB-Standards. Alle Lerninhalte des Buches decken sich mit den Vorgaben des ISTQB-Stan-dards, 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 ge-hen mit Vertrauensverlusten in Softwaresysteme auch Auftrags- und Arbeitsplatzverluste einher.
2. Lebenslanges Lernen wird zur Pflicht: Software wird immer kom-plexer, die Anforderungen steigen täglich. Lebenslanges Lernen ist
Geleitwortvi
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 Be-rufsqualifikationen 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 40 Ländern auf 6 Kontinenten das Know-how von (IT-)Fachkräf-ten. Weit über 100.000 Professionals sind nach dem ISTQB-Lehrplan geschult und haben ihre Kenntnisse durch die Zertifizierungsab-schlussprüfung unter Beweis gestellt. Ich freue mich, dass Sie sich ent-schlossen 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 GoerickeDirector International Software Quality Institute
vii
Vorwort
Mit diesem Buch schließen Sie eine Lücke zwischen den Softwaretest-bü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, Sicher-heit, Funktionalität, Benutzbarkeit, Wartbarkeit und Übertragbarkeit. Jedes Qualitätsmerkmal wird in Hinblick auf die einzelnen Schritte des vom International Software Testing Qualifications Board (ISTQB) fest-gelegten Standardtestprozesses behandelt. Dadurch wird eine abgerun-dete und ausgewogene Abdeckung dieser Qualitätsmerkmale erreicht.
Vollständige Abdeckung
des 2007 erschienenen
ISTQB-Lehrplans für den
Test Analyst und Technical Test Analyst
Der Inhalt dieses Buches basiert auf dem englischsprachigen Lehr-plan zum Certified Tester, Advanced Level [ISTQB-CTAL], der 2007 vom ISTQB herausgegeben wurde.1 Es werden alle Inhalte abgedeckt, die Sie kennen müssen, um die Prüfungen zum Erwerb der Advanced-Level-Zertifikate 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,
1. Die vorliegende Übersetzung basiert auf dem deutschsprachigen Lehrplan zum Certified Tester, Advanced Level [URL: GTB].
Vorwortviii
welche Abschnitte sich auf welche Prüfung beziehen. Alle prüfungs-relevanten 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.
ix
Danksagung
Unser Dank gilt unseren Kollegen im internationalen Autorenteam, mit denen wir in vielstündiger Arbeit den Lehrplan zum ISTQB Certi-fied Tester, Advanced Level verfasst haben:
Rex Black, Bernard Homès, Jayapradeep Jiothis, Paul Jorgensen, Vipul Kocher, Judy McKay, Thomas Müller, Klaus Olsen, Randy Rice, Jürgen Richter, Eric Riou du Cosquer, Mike Smith, Geoff Thompson, Erik van Veenendaal.
Mein (Grahams) Dank gilt besonders:■ Prof. Dr. Andreas Spillner, meinem Kollegen im German Testing
Board, für die Motivation, dieses Buch zu schreiben,■ meinen Kollegen bei T-Systems, Test Factory, für ihre Hilfsbereit-
schaft und Professionalität,■ meiner Familie (Elke, Christopher, Jennifer) für ihr Verständnis
und ihre Geduld.
Mein (Judys) Dank gilt besonders:■ Meiner Familie für ihre Hilfe und ihr Verständnis,■ Rex Black für das Eröffnen neuer Möglichkeiten sowie für seine
Beratung und Hilfe bei der beruflichen Weiterentwicklung,■ den Mitarbeitern der Cedar Glen Inn, die mir erlaubten, in meinen
verlängerten Mittagspausen dieses Buch in ihrem Restaurant zu schreiben,
■ Gary Garman, der mir gezeigt hat, dass man, selbst wenn man schon an einer unglaublichen Anzahl an Projekten arbeitet, immer noch Platz für ein weiteres hat!
Danksagungx
xi
Inhaltsverzeichnis
1 Einführung 1
1.1 Anforderungen an dieses Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Vollständigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Lesbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Was bedeutet »advanced«? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Was ist ein »Test Analyst«? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Marathon – unsere Beispielanwendung 9
2.1 Überblick über das Marathon-System . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Allgemeine Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Einsatz des Marathon-Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Verfügbarkeit des Marathon-Systems . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Erweiterungen vorbehalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Aspekte des Testmanagements 15
3.1 Systemarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Multisysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Sicherheitskritische Systeme . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 Echtzeit- und eingebettete Systeme . . . . . . . . . . . . . . . . . . . 19
3.2 Testprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.4 Testplanung und Teststeuerung . . . . . . . . . . . . . . . . . . . . . . 213.2.5 Testanalyse und Testentwurf . . . . . . . . . . . . . . . . . . . . . . . . 223.2.6 Testrealisierung und Testdurchführung . . . . . . . . . . . . . . . . 253.2.7 Testauswertung und Bericht . . . . . . . . . . . . . . . . . . . . . . . . 273.2.8 Abschluss der Testaktivitäten . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Inhaltsverzeichnisxii
4 Spezifikationsorientierte Testverfahren 31
4.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Einzelne spezifikationsorientierte Testverfahren . . . . . . . . . . . . . . . . 32
4.2.1 Äquivalenzklassenbildung . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.2 Grenzwertanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.3 Entscheidungstabellen und
Ursache-Wirkungs-Graph-Analyse . . . . . . . . . . . . . . . . . . . . 414.2.4 Zustandsbasiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.5 Orthogonale Arrays und Paartabellen . . . . . . . . . . . . . . . . . 494.2.6 Klassifikationsbäume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.7 Anwendungsfallbasiertes Testen . . . . . . . . . . . . . . . . . . . . . 59
4.3 Auswahl eines spezifikationsorientierten Testverfahrens . . . . . . . . . . 60
4.4 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5 Strukturorientierte Testverfahren 77
5.1 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2 Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3 Anwendung von strukturorientierten Testverfahren . . . . . . . . . . . . . 82
5.4 Einzelne strukturorientierte Testverfahren . . . . . . . . . . . . . . . . . . . . . 83
5.4.1 Anweisungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.4.2 Entscheidungs-/Zweigtests . . . . . . . . . . . . . . . . . . . . . . . . . . 865.4.3 Einfache Bedingungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.4.4 Mehrfachbedingungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.4.5 Definierte Bedingungstests . . . . . . . . . . . . . . . . . . . . . . . . . . 915.4.6 Pfadtests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.4.7 LCSAJ (Schleifentest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.5 Auswahl eines strukturorientierten Testverfahrens . . . . . . . . . . . . . . 94
5.6 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6 Fehlerbasierte Testverfahren 101
6.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.2 Taxonomien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
xiiiInhaltsverzeichnis
7 Erfahrungsbasierte Testverfahren 105
7.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2 Intuitive Testfallermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3 Checklistenbasiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.4 Exploratives Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.5 Fehlerangriffe (Attacken) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.6 Stärken und Schwächen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.7 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.8 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8 Analysetechniken 115
8.1 Statische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.1.1 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.1.2 Grenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178.1.3 Kontrollflussanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.1.4 Datenflussanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208.1.5 Einhaltung von Codierungsstandards . . . . . . . . . . . . . . . . 1228.1.6 Ermittlung von Codemetriken . . . . . . . . . . . . . . . . . . . . . . 1248.1.7 Statische Analyse einer Webseite . . . . . . . . . . . . . . . . . . . . 1258.1.8 Aufrufgraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.2 Dynamische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.2.1 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.2.2 Grenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.2.3 Speicherlecks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308.2.4 Wilder Zeiger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328.2.5 Analyse der Performanz . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.3 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.4 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9 Testen der Softwareeigenschaften 139
9.1 Qualitätsmerkmale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9.2 Qualitätsmerkmale für den Test Analyst . . . . . . . . . . . . . . . . . . . . 140
9.3 Qualitätsmerkmale für den Technical Test Analyst . . . . . . . . . . . . 140
Inhaltsverzeichnisxiv
10 Funktionales Testen 141
10.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
10.2 Testen auf Richtigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
10.3 Testen auf Angemessenheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.4 Interoperabilitätstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
10.5 Funktionale Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.6 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
10.7 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
11 Benutzbarkeits- und Zugänglichkeitstests 159
11.1 Benutzbarkeitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
11.2 Effektivität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
11.2.1 Effizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16011.2.2 Zufriedenheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
11.3 Zugänglichkeitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
11.4 Testprozess für Benutzbarkeits- und Zugänglichkeitstests . . . . . . . . 162
11.4.1 Planungsfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16211.4.2 Testentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16311.4.3 Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16611.4.4 Berichterstattung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
11.5 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
11.6 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
12 Effizienztests 171
12.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.2 Performanztests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.3 Lasttests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.4 Stresstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.5 Skalierbarkeitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
12.6 Testen der Ressourcennutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
12.7 Messen der Effizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
xvInhaltsverzeichnis
12.8 Planen von Effizienztests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
12.8.1 Risiken und typische Effizienzfehler . . . . . . . . . . . . . . . . . 18212.8.2 Verschiedene Arten von Testobjekten . . . . . . . . . . . . . . . . 18312.8.3 Anforderungen für Effizienztests . . . . . . . . . . . . . . . . . . . . 18312.8.4 Vorgehensweisen für Effizienztests . . . . . . . . . . . . . . . . . . 18712.8.5 Bestanden-/Nicht-bestanden-Kriterien für Effizienztests . . 18812.8.6 Werkzeuge für Effizienztests . . . . . . . . . . . . . . . . . . . . . . . 18812.8.7 Umgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19112.8.8 Organisatorische Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . 19212.8.9 Fragen zum Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . 193
12.9 Spezifikation von Effizienztests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
12.10 Durchführung von Effizienztests . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
12.11 Berichterstattung von Effizienztests . . . . . . . . . . . . . . . . . . . . . . . . 201
12.12 Werkzeuge für Effizienztests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
12.13 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
12.14 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
13 Sicherheitstests 211
13.1 Überblick über Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
13.2 Definition von Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
13.3 Planen von Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
13.4 Typische Sicherheitsbedrohungen . . . . . . . . . . . . . . . . . . . . . . . . . . 212
13.4.1 Vorgehensweise für Sicherheitstests . . . . . . . . . . . . . . . . . . 22113.4.2 Organisatorische Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . 22413.4.3 Aspekte des Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . 224
13.5 Analyse und Entwurf von Sicherheitstests . . . . . . . . . . . . . . . . . . . . 225
13.5.1 Softwareangriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22513.5.2 Weitere Entwurfstechniken für Sicherheitstests . . . . . . . . . 226
13.6 Durchführung von Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . . . . 227
13.7 Berichterstattung von Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . . 228
13.8 Werkzeuge für Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
13.9 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
13.10 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Inhaltsverzeichnisxvi
14 Zuverlässigkeitstests 233
14.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
14.2 Planen von Zuverlässigkeitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
14.2.1 Bewertung des Risikos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23514.2.2 Festlegen von Zuverlässigkeitszielen . . . . . . . . . . . . . . . . . . 23714.2.3 Aspekte des Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . 23914.2.4 Vorgehensweise für Zuverlässigkeitstests . . . . . . . . . . . . . . 23914.2.5 Vorgehensweise für das Messen des Zuverlässigkeitsgrads . 24014.2.6 Vorgehensweise für das Messen der Fehlertoleranz . . . . . . 24014.2.7 Vorgehensweise für Failover-Tests . . . . . . . . . . . . . . . . . . . 24114.2.8 Vorgehensweise für Backup- und Wiederherstellungstests . 243
14.3 Spezifikation von Zuverlässigkeitstests . . . . . . . . . . . . . . . . . . . . . . 244
14.3.1 Testspezifikation für das Zuverlässigkeitswachstum . . . . . . 24414.3.1 Testspezifikation für die Fehlertoleranz . . . . . . . . . . . . . . . 24814.3.2 Spezifikation von Failover-Tests . . . . . . . . . . . . . . . . . . . . . 24814.3.3 Spezifikation von Backup- und Wiederherstellungstests . . . 250
14.4 Durchführung von Zuverlässigkeitstests . . . . . . . . . . . . . . . . . . . . . 252
14.5 Berichterstattung von Zuverlässigkeitstests . . . . . . . . . . . . . . . . . . . 253
14.6 Werkzeuge für Zuverlässigkeitstests . . . . . . . . . . . . . . . . . . . . . . . . 254
14.7 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
14.8 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
15 Wartbarkeitstests 263
15.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
15.1.1 Definition von Wartungstests . . . . . . . . . . . . . . . . . . . . . . . 26315.1.2 Definition von Wartbarkeit . . . . . . . . . . . . . . . . . . . . . . . . 26415.1.3 Warum hat die Wartbarkeit einen geringen Stellenwert? . . 266
15.2 Planung von Wartbarkeitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
15.2.1 Grundlegende Wartbarkeitsrisiken . . . . . . . . . . . . . . . . . . 26915.2.2 Ursachen schlechter Wartbarkeit . . . . . . . . . . . . . . . . . . . . 26915.2.3 Erarbeitung einer Testvorgehensweise . . . . . . . . . . . . . . . . 277
15.3 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
15.4 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
xviiInhaltsverzeichnis
16 Portabilitätstests 283
16.1 Anpassbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
16.1.1 Gründe für mangelnde Anpassbarkeit . . . . . . . . . . . . . . . 28416.1.2 Anpassbarkeitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
16.2 Austauschbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
16.2.1 Fragen der Austauschbarkeit . . . . . . . . . . . . . . . . . . . . . . . 28716.2.2 Austauschbarkeitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
16.3 Installierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
16.3.1 Risikofaktoren der Installierbarkeit . . . . . . . . . . . . . . . . . . 29016.3.2 Installationstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
16.4 Koexistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
16.4.1 Koexistenztests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
16.5 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
16.6 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
17 Reviews 303
17.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
17.2 Welche Arbeitsergebnisse können wir einem Review unterziehen? 304
17.3 Wann sollten die Reviews durchgeführt werden? . . . . . . . . . . . . . . 305
17.4 Welche Art von Review sollten wir durchführen? . . . . . . . . . . . . . . 305
17.4.1 Informelles Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30617.4.2 Walkthroughs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30717.4.3 Technische Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30717.4.4 Inspektionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30717.4.5 Managementreviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30817.4.6 Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30817.4.7 Vertragsreviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30917.4.8 Anforderungsreviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30917.4.9 Designreviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31017.4.10 Akzeptanz-/Qualifikationsreviews . . . . . . . . . . . . . . . . . . . 31017.4.11 Betriebsbereitschaftsreviews . . . . . . . . . . . . . . . . . . . . . . . 311
17.5 Fragen zum Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
17.5.1 Wie können wir unser Review effektiv gestalten? . . . . . . . 31117.5.2 Haben wir die richtigen Leute? . . . . . . . . . . . . . . . . . . . . . 31217.5.3 Wir haben die Fehler gefunden – was nun? . . . . . . . . . . . . 31517.5.4 Wir haben keine Zeit für Reviews! . . . . . . . . . . . . . . . . . . 316
17.6 Checkliste für den Erfolg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
17.7 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
17.8 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Inhaltsverzeichnisxviii
18 Werkzeugkonzepte 323
18.1 Was ist ein Testwerkzeug? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
18.2 Warum setzen wir Werkzeuge ein? . . . . . . . . . . . . . . . . . . . . . . . . . 324
18.3 Werkzeugarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
18.3.1 Testmanagementwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . 32518.3.2 Fehlereinpflanzungswerkzeuge . . . . . . . . . . . . . . . . . . . . . . 32618.3.3 Simulations- und Emulationswerkzeuge . . . . . . . . . . . . . . . 32818.3.4 Statische und dynamische Analysewerkzeuge . . . . . . . . . . . 32918.3.5 Performanztestwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . 33018.3.6 Hyperlink-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33018.3.7 Debugging- und Troubleshooting-Werkzeuge . . . . . . . . . . 33118.3.8 Wie kann ich wissen, ob die Software funktioniert?
(Orakel und Komparatoren) . . . . . . . . . . . . . . . . . . . . . . . . 33218.3.9 Werkzeuge zur Testausführung . . . . . . . . . . . . . . . . . . . . . 33318.3.10 Sollte einfach ein Mitschnittwerkzeug eingesetzt werden? . 33518.3.11 Datengetriebene Automatisierung . . . . . . . . . . . . . . . . . . . 33618.3.12 Schlüsselwortgetriebene Automatisierung . . . . . . . . . . . . . . 33818.3.13 Nutzen von Automatisierungstechniken . . . . . . . . . . . . . . . 339
18.4 Integration von Werkzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
18.5 Weitere Werkzeugklassifizierungen . . . . . . . . . . . . . . . . . . . . . . . . . 342
18.6 Sollten wir alle unsere Tests automatisieren? . . . . . . . . . . . . . . . . . . 343
18.7 Bestimmung der Kosten von Testwerkzeugen . . . . . . . . . . . . . . . . . 345
18.8 Bestimmung der Nutzen von Testwerkzeugen . . . . . . . . . . . . . . . . . 348
18.9 Kaufen oder selbst erstellen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
18.10 Pflege von Werkzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
18.11 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
18.12 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
19 Abweichungsmanagement 353
19.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
19.2 Was ist ein Fehler? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
19.3 Fehlerklassifizierungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
19.4 Fehlerlebenszyklen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
19.5 Was sollte ein Fehlerbericht enthalten? . . . . . . . . . . . . . . . . . . . . . . 361
xixInhaltsverzeichnis
19.6 Metriken und Berichterstattung . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
19.6.1 Überwachung des Testfortschritts . . . . . . . . . . . . . . . . . . . 36319.6.2 Analyse der Fehlerdichte . . . . . . . . . . . . . . . . . . . . . . . . . . 36319.6.3 Messungen gefundener versus behobener Fehler . . . . . . . . 36419.6.4 Konvergenzmetriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36519.6.5 Möglichkeiten der Prozessverbesserung . . . . . . . . . . . . . . . 36619.6.6 Informationen zur Einhaltung der Phasen . . . . . . . . . . . . . 36819.6.7 Ist unsere Fehlerinformation objektiv? . . . . . . . . . . . . . . . 370
19.7 Blick in die Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
19.8 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
20 Kommunikationsfähigkeiten 375
20.1 Seine Rolle kennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
20.2 Ich habe alles im Griff. Warum hört mir niemand zu? . . . . . . . . . . 376
20.3 Effektiver Einsatz Ihrer Sprachfähigkeiten . . . . . . . . . . . . . . . . . . . 377
20.4 Ist unabhängiges Testen wünschenswert? . . . . . . . . . . . . . . . . . . . . 378
20.5 Aktive Beteiligung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
20.6 Aus dem Leben gegriffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
20.7 Lernkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
A Glossar 383
B Quellenverzeichnis 401
C Zuordnung zum Advanced-Lehrplan 407
Index 409
Inhaltsverzeichnisxx
1
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 Dun-keln 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 In-halte 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 be-schreiben wir die Ziele, die wir uns für dieses Buch gesteckt haben, sowie die grobe Struktur der einzelnen Kapitel. Da-nach 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?
Anmerkung: Um eine einheitliche Berufsbezeichnung einzu-führen, hat sich ISTQB für die Verwendung der Begriffe Test Analyst und Technical Test Analyst entschieden. Der Test Ana-lyst konzentriert sich eher auf betriebswirtschaftliche als auf technische Aspekte, während der Technical Test Analyst tech-nisch orientiert ist und in den meisten Fällen sehr viel Erfah-rung mit Softwareentwicklung und Softwaretesten mitbringt. In diesem Buch werden analog zur ISTQB-Terminologie durchgängig die Begriffe Test Analyst und Technical Test Ana-lyst verwendet.
1 Einführung2
1.1 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.1.1 Vollständigkeit
Dieses Buch basiert auf dem englischsprachigen ISTQB-Advanced-Level-Lehrplan (2007, [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 vermittel-ten Wissens Ihre Fähigkeiten und Kenntnisse vertiefen und dadurch Ihre Chancen auf dem Arbeitsmarkt verbessern.
1.1.2 Lesbarkeit
Die Abdeckung des
Lehrplans ist nur eines der
Ziele dieses Buches.
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 orien-tiert 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 kommen wir zum eigentlichen tech-nischen 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 Entschei-dungen zu schaffen. Das Buch geht daher über die Inhalte des
1. Die vorliegende Übersetzung basiert auf dem deutschsprachigen Lehrplan zum Certified Tester, Advanced Level [URL: GTB].
31.1 Anforderungen an dieses Buch
Lehrplans hinaus und bietet Ihnen anschauliches Material, um Ihr Wissen weiter abzurunden.
Eine realistische und komplexe
Beispielanwendung aus der Praxis
■ 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. Auch bietet er eine willkommene Abwechslung vom typischen Lehrbuchstil, der bei lehrplanorien-tierten Veröffentlichungen unwillkürlich vorherrscht. Diese Ab-schnitte 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-Beispielanwen-dung (Beschreibung siehe Kapitel 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.
■ Lernkontrolle Am Ende jedes Kapitels geben wir Ihnen einen Überblick über die vermittelten Inhalte. Die im Laufe des Kapitels behandelten ISTQB-Begriffe werden in diesem Abschnitt aufgelistet. Die Defini-tionen dieser Begriffe finden Sie im [ISTQB-Glossar] sowie im Miniglossar in Anhang A.
Das Buch enthält außerdem eine Liste mit konkreten Lernzie-len. Diese basieren in erster Linie auf den Zielen des ISTQB-Advanced-Level-Lehrplans und werden vor allem für die Vorberei-tung auf die Zertifizierungsprüfungen von Nutzen sein. Wo es sinnvoll erschien, haben wir die Lernziele des Lehrplans um unsere eigenen Ziele erweitert.
■ Erfahrungsberichte und Lessons Learned Wir haben im Laufe unserer Berufsjahre einen umfangreichen Erfahrungsschatz gesammelt und möchten ein paar dieser Erfah-rungen 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 dar-stellt – 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 steckt hinter dem »ich«? Bei jedem Kapitel gibt es einen Hauptautor. Die nachfolgende Tabelle zeigt, wer welches Kapitel verfasst hat. Somit wissen Sie, wer mit »ich« gemeint ist, wenn wir Erfahrungen und Lessons Learned mitteilen sowie Vorkommnisse erzählen, die wir ansonsten gerne verdrängen.
1 Einführung4
■ Übungen Durch die Übungen lernen Sie, das theoretische Wissen anzuwen-den. Diese Übungen werden Ihnen in den ISTQB-Prüfungen natür-lich nicht begegnen (das wäre etwas zu einfach!).
Kapitel Titel Autor: Judy
Autor: Graham
1 Einführung x x
2 Marathon – unsere Beispielanwendung x
3 Aspekte des Testmanagements
3.1 Systemarten x
3.2 Testprozess x
4 Spezifikationsorientierte Testverfahren x
5 Strukturorientierte Testverfahren x
6 Fehlerbasierte Testverfahren x
7 Erfahrungsbasierte Testverfahren x
8 Analysetechniken x
9 Testen der Softwareeigenschaften x
10 Funktionales Testen x
11 Benutzbarkeitstests und Zugänglichkeitstests
x
12 Effizienztests x
13 Sicherheitstests x
14 Zuverlässigkeitstests x
15 Wartbarkeitstests x
16 Portabilitätstests x
17 Reviews x
18 Werkzeugkonzepte x
19 Abweichungsmanagement x
20 Kommunikationsfähigkeiten x
Tab. 1–1
Wer hat welches Kapitel
geschrieben?
51.2 Was bedeutet »advanced«?
1.2 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 folgender-maß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 Antwor-ten 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 Ana-
lyst 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.
Professionellen Testern
kommt eine gemeinsame
Sprache zugute.
Noch ein weiterer (teilweise umstrittener) Aspekt zum Thema Zertifi-zierung: Die Advanced-Level-Zertifizierung bringt keinerlei Garantie mit sich. Es gibt viele gute Tester, die nicht zertifiziert sind. Die Zertifi-zierung 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 Zertifi-zierungsprogramme in ihr Fortbildungsangebot aufgenommen, was sich sehr gut auf die Mitarbeitermotivation und die Kundenzufrieden-heit ausgewirkt hat.
Neben zertifizierungsrelevanten Inhalten bietet das Buch auch eine Fülle an wertvollen Informationen, aus denen man als Advanced Tes-ter 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 Einführung6
1.3 Was ist ein »Test Analyst«?
Es ist nicht leicht, eine Berufsbezeichnung auf internationaler Ebene zu definieren. Oft verwenden unterschiedliche Länder oder sogar unter-schiedliche Unternehmen im gleichen Land verschiedene Bezeichnun-gen für die gleiche Rolle oder assoziieren ein etwas anderes Aufgaben-gebiet 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 des Testers
auf.
Im Advanced Level hat das ISTQB diesen Trend zur Standardisie-rung 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] vor-weisen muss. Bei der Rolle des Test Analyst kommt jedoch eine Spezia-lisierung hinzu, die wir in diesem Abschnitt ansprechen möchten.
Was erwarten Sie von einem Test Analyst? Bei höchsten Anforde-rungen würde ein Arbeitgeber die folgenden grundlegenden Fähigkei-ten von einem Test Analyst erwarten:
■ Unterstützung des Testmanagers bei der Entwicklung geeigneter Teststrategien
■ Strukturierung der Testaufgaben, die notwendig sind, um die Test-strategie umzusetzen
■ Analyse eines Systems mit einer Genauigkeit, die eine Bestimmung der angemessenen Testbedingungen zulässt
■ Anwendung von geeigneten Techniken zur Erfüllung der definier-ten Testziele
■ Vorbereitung und Durchführung aller notwendigen Testaktivitäten ■ Beurteilung, wann Testkriterien erfüllt sind■ Präzise und gründliche Berichterstattung über den Fortschritt des
Projekts■ Belegen der Bewertungen und Reviews durch konkrete Testbei-
spiele■ Einführung der geeigneten Werkzeuge zur Erfüllung der Testaufga-
ben
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 verschiede-nen Risikotypen einzuschätzen.
71.3 Was ist ein »Test Analyst«?
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 unter-schiedliche Rollen definiert. Beide Rollen erfordern die zuvor genann-ten 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äh-rend der Domain Test Analyst eine eher betriebswissenschaftliche Her-angehensweise vertritt und Tests in seinem fachlichen Umfeld (domain) durchführt.
Technical Test Analyst:
■ Konzentriert sich auf technische Eigenschaften der Software, wie z. B. Zuverlässigkeit und Effizienz
■ Wendet strukturorientierte Testverfahren wie z. B. Entscheidungs-überdeckungstests an sowie bestimmte spezifikationsorientierte Testverfahren wie Äquivalenzklassenbildung
■ Führt statische und dynamische Analysen durch■ Wendet Reviewtechniken auf Codedokumente und technische
Dokumente wie z.B. Architekturentwürfe an■ Ist in der Lage, Testautomatisierung effektiv durchzuführen■ Kann die Werkzeuge für Effizienztests (z. B. Performanztests) und
für Analysen erfolgreich anwenden
Domain Test Analyst:
■ Konzentriert sich auf funktionale Eigenschaften der Software wie z.B. Funktionalität und Benutzbarkeit im jeweiligen Anwendungs- oder Fachbereich
■ Wendet eine breite Palette an spezifikationsorientierten Testverfah-ren an (mehr als der Technical Test Analyst)
■ Wendet Reviewtechniken auf fachspezifische Dokumente wie z. B. Anforderungen und Anwendungsfälle an
Der »Domain Test
Analyst« wird kurz »Test Analyst« genannt.
Im Lehrplan zum ISTQB Advanced Level wird die Bezeichnung »Domain Test Analyst« zu »Test Analyst« gekürzt. Um Konsistenz mit der Lehrplanterminologie zu gewährleisten, haben wir diese Bezeich-nung ebenfalls übernommen.
Wenn wir im Verlauf des Buches die Lernziele erläutern, kenn-zeichnen wir stets deutlich, welche Abschnitte sich auf welche Rolle beziehen. Dies ist insbesondere für diejenigen Leser wichtig, die an einem Trainingsseminar teilnehmen und/oder eine Zertifizierungsprü-fung ablegen möchten, da diese rollenbezogen angeboten werden (z. B. Test Analyst und Technical Test Analyst).
1 Einführung8
9
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 ver-schiedenen in diesem Buch behandelten Techniken und Test-arten 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 er-fordert.
Wie man es von einem Vorbereitungsbuch für die Zertifi-zierung zum ISTQB Advanced Level erwarten kann, ist die Beispielanwendung kompliziert genug, um realistische Test-szenarien zu bieten. Die erforderliche Mühe, das Marathon-System zu verstehen, wird sich jedoch zu einem späteren Zeit-punkt durch ein tieferes Verständnis bestimmter Aspekte des Testens bei praktischen Anwendungen auszahlen.
Im Verlauf des Buches werden wir die allgemeine Beschrei-bung der Marathon-Anwendung immer wieder erweitern (ganz im Sinne der wohlbekannten schleichenden Änderung des Projektumfangs). Dies erlaubt eine gründlichere Behand-lung einzelner Aspekte.
Erwarten Sie jedoch nicht, dass das Marathon-System in je-der Hinsicht vollkommen ist (die Autoren sind schließlich pro-fessionelle Tester, keine Systemarchitekten). Falls Sie Lücken oder Inkonsistenzen im Design finden, ist das ein Zeichen da-fü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 Marathonveranstal-tungen (z.B. Boston, London), die Läufe mithilfe moderner Technolo-gie effizient zu planen und zu organisieren.