Softwaretesten nach ISTQB CTFL 4.0 für Dummies E-Book

Maud Schlich

• Herausgeber: Wiley-VCH GmbH
• Kategorie: Wissenschaft und neue Technologien
• Serie: ...für Dummies
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Beschreibung

Neue Hauptversion 4.0: Neuer Lehrplan, geänderter Prüfungsumfang!

Soll in Ihrem Unternehmen neue Software eingeführt werden und Sie müssen sie testen? Oder wollen Sie als Entwickler über den Tellerrand schauen und sich auch mit dem Softwaretesten beschäftigen? Leicht verständlich erläutert Ihnen Maud Schlich alle vom ISTQB^® Certified Tester Foundation Level geforderten Lerninhalte sowohl für Programmierer als auch mit Blick auf Fachanwender, die die Software später einsetzen. Zahlreiche praxisorientierte Beispiele und übungen sorgen für eine optimale Prüfungsvorbereitung. Darüber hinaus erfahren Sie für alle Testaktivitäten, wie sie jeweils im klassischen oder im agilen Kontext geplant und durchgeführt werden.

Sie erfahren

• Aus welchen Aktivitäten der Testprozess besteht
• Wie Sie unterschiedliche Testverfahren nutzen
• Wie Entwickler und Tester optimal zusammenarbeiten
• Wie Sie prüfen, ob Sie noch im Plan sind

Leseprobe

Softwaretesten nach ISTQB® CTFL 4.0 für Dummies

Schummelseite

DER ALLGEMEINE TESTPROZESS

ÜBERSICHT ÜBER DIE WICHTIGSTEN TESTDOKUMENTE

ÜBERSICHT ÜBER TESTTECHNIKEN

Softwaretesten nach ISTQB® CTFL 4.0 für Dummies

Bibliografische Information der Deutschen Nationalbibliothek

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

1. Auflage 2024

© 2024 Wiley-VCH GmbH, Boschstraße 12, 69469 Weinheim, Germany

All rights reserved including the right of reproduction in whole or in part in any form. This book published by arrangement with John Wiley and Sons, Inc.

Alle Rechte vorbehalten inklusive des Rechtes auf Reproduktion im Ganzen oder in Teilen und in jeglicher Form. Dieses Buch wird mit Genehmigung von John Wiley and Sons, Inc. publiziert.

Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.

Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.

Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.

Although the author and Wiley-VCH publishing house have made every effort to ensure that the information in this book was correct and up-to-date at press time, the views and opinions expressed in this book are those of the author and do not necessarily reflect the official policy or position of the ISTQB®. The ISTQB® does not assume and hereby disclaim any liability to any party for any loss, damage, or disruption caused by errors or omissions, whether such errors or omissions result from negligence, accident, or any other cause.

Obwohl der Autor und der Wiley-VCH-Verlag alle Anstrengungen unternommen haben, um sicherzustellen, dass die Informationen in diesem Buch zum Zeitpunkt der Veröffentlichung korrekt und aktuell waren, sind die in diesem Buch geäußerten Ansichten und Meinungen die des Autors und spiegeln nicht unbedingt die offizielle Politik oder Position des ISTQB® wider. Das ISTQB® lehnt jegliche Haftung für Einbußen, Schäden oder Beeinträchtigungen ab, die durch Fehler oder Auslassungen verursacht werden, unabhängig davon, ob diese auf Fahrlässigkeit, Zufall oder eine andere Ursache zurückzuführen sind.

Coverfoto: tuyen – stock.adobe.comKorrektur: Geesche Kieckbusch

Print ISBN: 978-3-527-72165-8ePub ISBN: 978-3-527-84673-3

Über die Autorin

Maud Schlich begann ihre Berufstätigkeit 1991 als Systemprogrammiererin und Trainerin. 1996 wechselte sie die Seiten und kümmerte sich in der Qualitätssicherung um die Durchführung von Tests und Reviews. Von 1998 bis 2004 war sie als wissenschaftliche Mitarbeiterin am Fraunhofer-Institut für Experimentelles Software Engineering (IESE) in Kaiserslautern tätig. 2000 übernahm sie die Leitung der Außenstelle des IESE in Kaiserslautern und die Geschäftsführung der Software Technologie Initiative (STI) e.V. 2004 verantwortete sie den Bereich R&D der PFAFF Industrie Maschinen GmbH.

Seit Ende 2004 ist Maud Schlich mit »Maud Schlich THE QUALITEERS« selbstständig. Schwerpunkt ihrer Beratungstätigkeit ist das nachhaltige Coaching von Testmanagern und QS-Teams im klassischen und im agilen Kontext. Zudem ist sie seit 2018 für die EXCO GmbH als Coach und Beraterin für den Aufbau und die Verbesserung des Qualitätsmanagements im Rahmen der Validierung von Systemen im GxP-Umfeld tätig.

Maud Schlich ist seit 2007 Mitglied des German Testing Board (GTB).

Online-Coachings und E-Learnings zum Thema Testen finden Sie auf ihrer Website unter https://thequaliteers.de.

Danksagung

Dieses Buch habe ich allein geschrieben, aber es ist natürlich nicht mein ureigenes Wissen. Mein Dank gilt daher allen meinen Kolleginnen und Kollegen des German Testing Board und des International Software Qualification Board: Ich bin der Überzeugung, dass wir gemeinsam die Welt des Testens immer weiter ein Stückchen besser machen. Glücklicherweise hatte ich für die Erstauflage mit Frau Andrea Baulig eine wunderbare Lektorin, die genau die richtigen Fragen stellte. Und was wäre dieses Buch ohne ein paar sehr gute Reviewer, die mich auf viele Dinge hingewiesen und dafür gesorgt haben, dass Sie jetzt dieses Werk in einer guten Qualität lesen können, Danke an Martin Klein, Cornelia Pieper, Andreas Porr und Florian Fieber. Mein ganz besonderer Dank geht an meine zwei Liebsten Erik Schlich und Norbert Schlich: Danke für alles.

Alle Fehler, die jetzt noch enthalten sind, liegen ganz sicher an mir und an niemandem sonst. Ich danke allen für die Hinweise und Verbesserungsvorschläge, die ich nun in dieser Auflage berücksichtigt habe, und freue mich auf weitere.

Tabellenverzeichnis

Kapitel 4

Tabelle 4.1: Vor- und Nachteile von Integrationsteststrategien

Kapitel 5

Tabelle 5.1: Eingangs- und Endekriterien verschiedener Dokumenttypen

Tabelle 5.2: Analyse möglicher Perspektiven

Tabelle 5.3: Verbesserungsfähige Checkliste: Prüfung der GUI auf Erwartungskonfor...

Kapitel 6

Tabelle 6.1: Beispiel für abstrakten Testfall

Tabelle 6.2: Beispiel für abstrakten Testfall mit Nachbedingung

Tabelle 6.3: Beispiel für konkreten Testfall

Kapitel 7

Tabelle 7.1: Äquivalenzklassenanalyse Drucker-Dialog (Anzahl Exemplare)

Tabelle 7.2: Äquivalenzklassenanalyse Drucker-Dialog (Anzahl Exemplare erweitert)

Tabelle 7.3: Äquivalenzklassenanalyse Drucker-Dialog (vereinfacht)

Tabelle 7.4: Äquivalenzklassenanalyse Drucker-Dialog (vollständig)

Tabelle 7.5: Testfallermittlung zur Äquivalenzklassenanalyse Drucken-Dialog

Tabelle 7.6: Beispiele von verschiedenartigen Äquivalenzklassen

Tabelle 7.7: Grenzwertanalyse Drucken-Dialog

Tabelle 7.8: Testfälle Grenzwertanalyse Drucken-Dialog

Tabelle 7.9: Testfälle Grenzwertanalyse Spezielle Dateien für Drucken-Dialog

Tabelle 7.10: Entscheidungstabelle – Bedingungen für Bonus auf Zahnersatz

Tabelle 7.11: Entscheidungstabelle – Aktionen für Bonus auf Zahnersatz

Tabelle 7.12: Entscheidungstabelle – Kombinatorik der Bedingungen für Bonus auf Z...

Tabelle 7.13: Entscheidungstabelle – Aktionen für Bonus auf Zahnersatz

Tabelle 7.14: Entscheidungstabelle – Testfälle für Bonus auf Zahnersatz

Tabelle 7.15: Entscheidungstabelle – Erfolgsbeteiligung

Tabelle 7.16: Zustandsübergangstabelle Musikschule

Tabelle 7.17: Testfallermittlung zum Zustandsübergangsbaum Musikschule

Tabelle 7.18: Testfallermittlung zur switch-1-Überdeckung Musikschule

Tabelle 7.19: Beispiel Use Case »Wir kriegen dich wach«

Kapitel 8

Tabelle 8.1: Testfälle Knotenüberdeckung

Tabelle 8.2: Testfälle Kantenüberdeckung

Tabelle 8.3: Beispiel »Einfache Bedingungsüberdeckung«

Tabelle 8.4: Beispiel Mehrfachbedingungsüberdeckung

Tabelle 8.5: Beispiel modifizierte Bedingungs-/Entscheidungsüberdeckung

Kapitel 9

Tabelle 9.1: Optimierte Checkliste: Prüfung der GUI auf Erwartungskonformität und...

Kapitel 12

Tabelle 12.1: Auszug aus einer RACI-Matrix in einem Systemtestkonzept

Kapitel 14

Tabelle 14.1: Eintrittswahrscheinlichkeit der Fahrsituation (Automotive)

Tabelle 14.2: Schwere der Verletzung (Automotive)

Tabelle 14.3: Beherrschbarkeit (Automotive)

Tabelle 14.4: Risikoanalyse (H, M, N) für das Forumsbeispiel

Tabelle 14.5: Risikoanalyse (1–10) für das Forumsbeispiel

Kapitel 17

Tabelle 17.1: Inhalte eines Fehlerberichts

Anhang A

Tabelle 22.1: Optimierte Checkliste: Prüfung der GUI auf Erwartungskonformität un...

Tabelle 22.2: Äquivalenzklassenanalyse Drucker-Dialog (vollständig)

Tabelle 22.3: Testfälle zur Äquivalenzklassenanalyse Drucken-Dialog

Tabelle 22.4: Äquivalenzklassenanalyse Schulinformationssystem

Tabelle 22.5: Zustandsübergangstabelle Musikschule

Tabelle 22.6: Testfallermittlung zur switch-0-Überdeckung Musikschule (ohne Erwe...

Tabelle 22.7: Testfallermittlung zur switch-1-Überdeckung Musikschule (ohne Erwe...

Illustrationsverzeichnis

Kapitel 1

Abbildung 1.1: Fehlhandlung – Fehlerzustand – Fehlerwirkung

Abbildung 1.2: Aktivitäten im Testprozess

Kapitel 2

Abbildung 2.1: Testaktivitäten und Testdokumente

Abbildung 2.2: Bidirektionale Verfolgbarkeit

Abbildung 2.3: Testprozess im Kontext

Kapitel 3

Abbildung 3.1: Wasserfallmodell nach Royce

Abbildung 3.2: Wasserfallmodell mit Rückschleifen

Abbildung 3.3: Allgemeines V-Modell

Abbildung 3.4: W-Modell nach A. Spillner

Abbildung 3.5: Scrum

Kapitel 4

Abbildung 4.1: Allgemeines V-Modell

Abbildung 4.2: Integrationsteststrategie Big Bang

Abbildung 4.3: Integrationsteststrategie Top-down

Abbildung 4.4: Integrationsteststrategie Bottom-up

Abbildung 4.5: Integrationsteststrategie Critical-First

Abbildung 4.6: Integrationsteststrategie Backbone

Abbildung 4.7: Continuous Integration

Kapitel 5

Abbildung 5.1: Explosion der Fehlerkosten (nach Boehm)

Abbildung 5.2: Übersicht Reviewprozess

Kapitel 7

Abbildung 7.1: Drucken-Dialog

Abbildung 7.2: Ablauf Testfallerstellung Äquivalenzklassen

Abbildung 7.3: Grenzwert

Abbildung 7.4: Hysterese einer Heizungsregelung

Abbildung 7.5: Darstellung von Zustandsgraphen in UML

Abbildung 7.6: Zustandsgraph Musikschule – Ausgangs- und Endzustand

Abbildung 7.7: Zustandsgraph Musikschule – Zustände ermitteln

Abbildung 7.8: Zustandsgraph Musikschule – Zustandsübergänge ermitteln (1)

Abbildung 7.9: Zustandsgraph Musikschule – Zustandsübergänge ermitteln (2)

Abbildung 7.10: Zustandsgraph Musikschule – Zustandsübergänge ermitteln (3)

Abbildung 7.11: Zustandsgraph Musikschule – Zustandsübergänge ermitteln (4)

Abbildung 7.12: Zustandsgraph Musikschule

Abbildung 7.13: Zustandsübergangsbaum Musikschule

Abbildung 7.14: User Story Vorderseite

Abbildung 7.15: User Story Rückseite

Abbildung 7.16: Beispiel BPMN

Kapitel 8

Abbildung 8.1: Aufrufhierarchie »Seminare buchen«

Abbildung 8.2: Kontrollflussgraph

Abbildung 8.3: Knotenüberdeckung »Seminare buchen«

Abbildung 8.4: Kontrollflussgraph mit Kantenüberdeckung

Kapitel 11

Abbildung 11.1: Produktqualität nach ISO/IEC 25010

Abbildung 11.2: Effizienztests

Kapitel 12

Abbildung 12.1: Kanban-Board für das Testen

Abbildung 12.2: Zwei Sichtweisen auf die Testpyramide

Abbildung 12.3: Testquadranten

Abbildung 12.4: Tests in den Testquadranten

Abbildung 12.5: Burndown-Chart

Kapitel 13

Abbildung 13.1: Testfortschritt

Abbildung 13.2: Fehlerstatus

Abbildung 13.3: Teststatus

Abbildung 13.4: Abdeckung von Anforderungen und Automatisierungsgrad

Abbildung 13.5: Retrospektive als Spinnennetz-Radar

Abbildung 13.6: Teststatusbericht von DokuP

Kapitel 14

Abbildung 14.1: Risikomatrix

Kapitel 17

Abbildung 17.1: Fehlermeldungen auf einem agilen Board

Kapitel 19

Abbildung 19.1: Agiler Testquadrant

Anhang A

Abbildung 22.1: Erweiterter Zustandsgraph

Orientierungspunkte

Cover

Titelblatt

Impressum

Über die Autorin

Inhaltsverzeichnis

Einführung

Fangen Sie an zu lesen

Anhang A: Musterlösungen

Abbildungsverzeichnis

Stichwortverzeichnis

End User License Agreement

Seitenliste

1

2

3

4

7

8

9

21

22

23

24

25

26

27

29

30

31

32

33

34

35

36

37

38

39

40

41

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

133

134

135

136

137

138

139

140

141

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

347

348

349

350

351

352

353

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

Einführung

Noch ein Buch zum Testen? Es gibt doch schon so viele!? Und keiner hält sich an das, was darin steht … Oder?

Wann haben Sie sich das letzte Mal über schlecht oder gar nicht funktionierende Software oder Geräte geärgert? Ich vermute, dass ist noch nicht lange her. Und da immer mehr Software Einzug in unseren Alltag hält, ja, es kaum noch ein rein mechanisches Gerät in unserem Leben gibt, wird die Wahrscheinlichkeit, mangelhafte Qualität zu erleben, leider auch höher.

Ich kenne viele Menschen, die Experten in ihrer Fachdomäne sind und dann freigestellt werden zum Testen. Sie bekommen ein (fast immer zu geringes) Zeitkontingent und sollen dann ganz vergeblich die Qualität in die Software oder die Systeme hineintesten, die leider vorher schon nicht enthalten ist.

Was lange Jahre allenfalls eine nebensächliche Aufgabe war, ist schon seit ein paar Jahren ein Beruf geworden: das Softwaretesten. Gleichzeitig ist die Anerkennung der Fachanwender in ihrer zusätzlichen Rolle als Tester und als Unterstützer der Entwicklungsabteilungen in Sachen Qualität ebenfalls deutlich gestiegen. Es gibt glücklicherweise zunehmend mehr Manager, die ihre Mitarbeiter schulen lassen, und zwar sehr häufig nach den Lehrplänen des International Software Testing Qualifications Board (ISTQB).

Dieses Buch orientiert sich eng an diesen Lehrplänen. Es soll aber nicht nur als Lernbegleiter auf dem Weg zur Prüfung dienen, sondern vor allem auch als Wegbegleiter in Ihrer täglichen Praxis. Daher finden Sie hier viele Beispiele und Anregungen, die Ihnen den Transfer der Buchinhalte in Ihr Projekt erleichtern sollen.

Über dieses Buch

Im International Software Testing Qualifications Board (ISTQB) und in den nationalen Boards (zum Beispiel im German Testing Board) ist man sich sicher, dass

die Klärung einer Reihe von Begrifflichkeiten,

ein grundlegendes gemeinsames Verständnis vom Umfang des Testens,

ein allgemein definierter Testprozess und

eine prinzipielle Vorgehensweise

die Grundlagen für erfolgreiches Testen sind.

Und tatsächlich habe ich es in den letzten fünfzehn Jahren zunehmend erlebt, dass sich Tester und Testmanager, die aus unterschiedlichen Unternehmen und Projekten stammen, sehr viel schneller in einem neuen Projekt zusammenfinden. Sie meinen das Gleiche, wenn sie den gleichen Begriff nutzen, und das wiederum vermeidet viele Missverständnisse. Zudem wird die Qualität des Testens zunehmend dadurch besser, dass schon seit den Siebzigerjahren bekannte Testtechniken eine deutlich höhere Verbreitung gefunden haben.

Lesen Sie aktuelle Stellenanzeigen, so werden Sie immer häufiger die Forderung nach den Certified Tester-Zertifikaten finden, mit denen eine minimale Fachkenntnis nachgewiesen werden soll.

Softwaretesten nach ISTQB für Dummies ist kein wissenschaftliches Buch; daher enthält es wenig Literaturhinweise, keine Fußnoten und nur wenig komplizierte Begriffe, Formeln oder komplexe Beispiele. Wenn sinnvoll, habe ich den Lehrplan oder das Glossar direkt zitiert. Manchmal ist das Originalzitat einfach besser als jede noch so gekonnte Umformulierung, besonders dann, wenn es später in einer Prüfung abgefragt werden könnte.

In den Beispielen habe ich mich darum bemüht, abwechselnd die Testmanagerin und den Testmanager, die Entwicklerin und den Entwickler auftreten zu lassen. Die nur scheinbar geschlechtsneutrale männliche Form ärgert mich in meinem beruflichen Alltag auch immer mal wieder (vor allem wenn der Testmanager dann auch »Mannstunden« als Aufwand schätzt statt Personenstunden) und das Binnen-I und sonstige Formen lesen sich doch holprig. Ich bin gespannt, wie diese Variante bei Ihnen ankommt.

Vieles in diesem Buch habe ich aus meiner über dreißigjährigen Berufspraxis entlehnt; keine der Situationen war ganz genauso wie geschildert, aber es ist auch keine frei erfunden. Sollten Sie mich persönlich kennen und sich in einer Geschichte wiedererkennen, dann seien Sie unbesorgt: Es gibt sicherlich einige weitere Personen, denen es ähnlich geht, und alle Situationen sind so verfremdet und anonymisiert, dass niemand mehr das Original erkennt.

Was Sie nicht lesen müssen

Sie können das Buch von vorn bis hinten lesen, aber Sie müssen es nicht. Die einzelnen Kapitel sind weitestgehend voneinander unabhängig. Wenn Sie sich also beispielsweise erst einmal nur für Testverfahren auf Basis von Anforderungen interessieren, dann steigen Sie doch direkt in Kapitel 7 ein. Oder ist das risikoorientierte Testen ein Begriff, den Sie endlich mal besser verstehen wollen? Dann beginnen Sie ruhig mit Kapitel 14.

Wenn Sie es eilig haben, dann können Sie zudem über jeden Kasten hinwegspringen.

Extras

In einem solchen Kasten finden Sie ergänzende Informationen und Beispiele, die Ihnen das Gelesene auf eine andere Art verdeutlichen sollen. Wenn Sie es eilig haben, müssen Sie das nicht lesen. Zum Verständnis des Buchs oder zum Bestehen der Prüfung sind sie nicht notwendig.

Der aktuelle Lehrplan von 2023 verzichtet ganz auf Beispiele, für die Programmierwissen (zumindest in geringem Maße) notwendig wäre. Deshalb finden Sie auch die Exkurse für Programmierer jeweils in einem solchen Kasten. Dabei handelt es sich meist um einfache Codebeispiele für die Anwendung einzelner Testverfahren.

Wenn es noch schneller gehen soll, dann können Sie auch alle Informationen, die mit dem Wegweiser-Symbol gekennzeichnet sind, einfach ignorieren – hier geht es um eine Reflexion Ihres beruflichen Alltags. Die Informationen sind nicht »direkt« prüfungsrelevant. Machen Sie allerdings diese Aufgaben, dann gewinnen Sie tiefere Einsichten und nachhaltigeres Wissen – und oft genug werden Sie damit beim eigenen Testen Ihre Arbeitsergebnisse verbessern.

Und natürlich können Sie auch darauf verzichten, überhaupt eine der Übungen zu machen – dann allerdings ist die Wahrscheinlichkeit, die jeweilige Technik wirklich verinnerlicht zu haben, deutlich geringer. Für die Prüfung reicht es dann vielleicht nicht mehr, für ein grundlegendes Verständnis der Sachverhalte dagegen schon.

Törichte Annahmen über die Leser

Beim Schreiben dieses Buchs habe ich mir eine kleine Gruppe sehr unterschiedlicher Personen vorgestellt, für die ich schreibe. Es sind keineswegs dumme Menschen, die etwas über das Testen erlernen oder gar eine Prüfung zum Certified Tester Foundation Level ISTQB® bestehen wollen! Welche habe ich also im Kopf gehabt?

Da ist die Mitarbeiterin eines Fachbereichs, die aufgrund Ihrer Fachkenntnis im Anwendungsbereich der Software öfters für den Test abgestellt wird.

Da ist der Informatikstudent, der einen lockereren Zugang zum Thema Testen sucht, als es Vorlesungsskripte vermitteln.

Da ist die Programmiererin, die bessere Software entwickeln möchte.

Da ist der Tester, der sich nach einer neuen Stelle umsieht und in der Bewerbung ein Zertifikat vorzeigen möchte.

Da ist die Testmanagerin, die ihr Team besser anleiten möchte, damit die Zeit zum Testen optimal genutzt wird.

Da ist der Projektleiter, der verstehen möchte, was das Testprojekt eigentlich macht.

Ich gehe davon aus, dass Sie

nicht unbedingt Vollzeittester sind oder gar Testmanager,

sich bewusst sind, dass das Testen ebenso wichtig ist wie das Entwickeln der Systeme,

professionell Ihre Testaufgaben erledigen möchten, ohne gleich ein Perfektionist zu sein (falls doch, blättern Sie mal ans Ende zu den Buchtipps),

sich über eine kleinschrittige Anleitung freuen oder einfach flott darüber hinweglesen,

verstehen, dass ein Zertifikat zwar bedeutet, dass Sie genügend Multiple-Choice-Fragen der Prüfung richtig beantwortet haben, aber nicht, dass Sie das Erlernte auch automatisch korrekt anwenden. Dazu bedarf es der Übung und der Anwendung in der Praxis.

Fühlen Sie sich angesprochen? Wunderbar, dann freue ich mich sehr auf Sie. Falls nicht, dann blättern Sie mal in das Buch rein – vielleicht passt es ja dennoch.

Wie Sie dieses Buch nutzen

Wenn Sie parallel zu diesem Buch auch den Lehrplan lesen möchten, empfehle ich Ihnen, erst das Thema im Buch zu erarbeiten und den Lehrplan als Zusammenfassung des jeweiligen Inhalts zu nutzen.

Die Reihenfolge der Kapitel im Buch ist etwas anders als im Lehrplan. Das liegt unter anderem daran, dass der Lehrplan keine Rücksicht darauf nimmt, welche Begriffe und Konzepte Sie bereits kennen. So werden Begriffe manchmal einige Zeit genutzt, bevor sie dann endlich erläutert werden. Hoffentlich ist mir das mit der veränderten Reihenfolge besser gelungen.

Sie nutzen also am geschicktesten das Inhaltsverzeichnis und das Stichwortverzeichnis des Buchs und des Lehrplans, um Dinge nachzuschlagen. Außerdem ist das Glossar des ISTQB sehr hilfreich.

Wenn Sie dieses Buch zum Selbststudium nutzen und anschließend die Prüfung machen möchten, dann empfehle ich Ihnen, es von Anfang bis Ende zu lesen und nach jedem Abschnitt innezuhalten und das Gelesene zu reflektieren. Stellen Sie sich folgende Fragen oder Aufgaben:

Welche zentralen Begriffe wurden neu definiert oder detaillierter ausgeführt? Erläutern Sie diese mit Ihren eigenen Worten.

Versuchen Sie, Grafiken auswendig zu zeichnen.

Welche Begriffe werden in meiner Praxis benutzt? Wie unterscheiden sich diese von den im Buch und im Glossar definierten? Denken Sie daran, dass zumindest bis nach der bestandenen Prüfung das Glossar der Maßstab ist.

Lesen Sie das zugehörige Lernziel aus dem Lehrplan und versuchen Sie (mit zugeklapptem Buch), die Forderung des Lernziels zu erfüllen.

Beispiel 1: Das Lehrziel lautet »Der Lernende kann … FL-1.2.3 (K2) zwischen Grundursache, Fehlhandlung, Fehlerzustand und Fehlerwirkung unterscheiden« (CTFL-Lehrplan Seite 15). Können Sie eine kleine Skizze erstellen und daran die Unterschiede erklären? Oder eine beispielhafte Geschichte erzählen?

Beispiel 2: Das Lehrziel lautet »Der Lernende kann … FL-4.2.3 (K3) Entscheidungstabellentest zur Ableitung von Testfällen anwenden«. Können Sie aus einer beliebigen Spezifikation oder zu einer Funktionalität einer Software, die Sie kennen, Entscheidungstabellen erstellen und daraus Testfälle ableiten?

Falls ja, dann ist dieses Lehrziel erfüllt, und Sie können davon ausgehen, dass die Prüfung in diesem Teil für Sie kein Problem darstellen wird.

Egal, ob Sie eine Prüfung machen oder nicht, fragen Sie sich immer auch:

Wie kann ich das Erlernte in meinem Alltag umsetzen?

Was kann ich oder könnten wir im Unternehmen besser machen?

Wenn die Prüfung für Sie nicht so wichtig ist, dann lesen Sie das Buch in der Reihenfolge, die Ihnen am meisten zusagt. Vielleicht beginnen Sie also einfach mit dem Kapitel, das Sie am meisten interessiert. Wenn Sie nicht so recht wissen, welches das sein könnte, dann fangen Sie doch mit den Kapiteln 1 und 2 an, so erhalten Sie erst einmal einen Überblick und können danach weiter auswählen.

Nicht alle Begriffe werden immer wieder erläutert, also nutzen Sie am besten das Stichwortverzeichnis, um die jeweilige Erläuterung schneller zu finden. Manches wiederhole ich auch. Wenn Sie für die Prüfung lernen, kann das sehr nützlich sein – so bleibt der Inhalt noch besser im Gedächtnis, oder?

Wie dieses Buch aufgebaut ist

Dieses Buch besteht aus mehreren Teilen, die zusammengenommen das Basiswissen für das Testen von Systemen und Software abdecken und auf der Grundlage des CTFL-Lehrplans erstellt wurden. Ab und zu gehen die Inhalte ein wenig darüber hinaus, wenn es für Ihre Praxis hilfreich oder einfach wissenswert ist.

Teil I: Testen ist mehr als die Summe seiner Teile

Das Testen von Systemen und Software umfasst viel mehr als häufig angenommen wird, daher gibt Teil I – und dort vor allem Kapitel 1 – einen ersten Überblick über viele typische Begriffe und Aktivitäten im Testen. Der allgemeine Testprozess dient Ihnen als Orientierungshilfe zu den vielfältigen Aufgaben und Dokumenten im Testen. Die Grundsätze des Testens und die ethischen Grundlagen sollen Ihnen als Richtschnur Ihres Handelns dienen. Das Testen muss an unterschiedliche Softwareentwicklungsmodelle angepasst werden. Dazu gehört dann auch die Definition von Teststufen und prinzipiellen Vorgehensweisen.

Teil II: Statisches und Dynamisches Testen

Getestet wird nicht nur das ausführbare Programm, sondern auch schon »statisch« in Dokumenten. Dieser Teil enthält eine große Bandbreite an Verfahren für statische und dynamische Tests. Dazu zählen statische Analyse und Reviews, das »Black-Box-Testen« von Anwendungen auf Basis von Spezifikationen und das »White-Box-Testen« des Codes und anderer Strukturen. Der Teil beschreibt, wie Sie Ihre Erfahrung im Testen systematisch zur Verbesserung des Testens einbringen können. Neben den Funktionen überprüfen Sie auch andere Aspekte wie die Performanz, die Benutzerfreundlichkeit oder die Sicherheit.

Teil III: Das Testen managen

Auch wenn Sie nicht selbst Testmanager sind, so gibt es doch einiges, was Sie als Tester zu einer guten Testplanung und -durchführung beitragen können. Dieser Teil enthält das grundlegende Handwerkszeug für zentrale Aktivitäten des Testmanagements und beschreibt mögliche Maßnahmen, die Sie ergreifen oder unterstützen können, wenn es nicht so klappt wie gedacht. Außerdem erfahren Sie hier, wieso ein gutes Risikomanagement nicht nur das Testprojekt erfolgreicher macht, sondern auch eine gute Grundlage für die Auswahl von Tests darstellt.

Teil IV: Unterstützendes

Entwickler sind anders, Tester auch. Und ein gutes System erhalten Sie zumindest leichter, wenn alle gut zusammenarbeiten. Dazu enthält dieser Teil ein paar psychologische Grundlagen des Miteinanders und erläutert, was Sie als Tester tun können, damit die Kommunikation gut funktioniert. Außerdem werden die wichtigsten Unterstützungsprozesse wie Konfigurationsmanagement und Fehlermanagement mit ihrer Bedeutung für das Testen vorgestellt. Den Abschluss dieses Teils bildet eine Übersicht über typische Werkzeuge im Test und gibt Hinweise zur Auswahl und Einführung.

Teil V: Der Top-Ten-Teil

Jeweils zehn wertvolle Tipps für agiles Testen und zu Büchern, die Sie im Anschluss oder auch mal zwischendurch lesen können.

Konventionen und Symbole, die in diesem Buch verwendet werden

Dieses Buch enthält gelegentlich kurze Codeteile, die dann als Listing formatiert sind. Sie sind in den meisten Fällen Teil der Exkurse für Programmierer und stehen dann zusammen mit der Erklärung in einem Kasten.

Dort, wo ein Begriff das erste Mal genutzt wird oder besonders wichtig ist, ist er kursiv gedruckt.

Hier finden Sie Tipps und Tricks für die Umsetzung des Gelernten in Ihre Praxis.

Achtung – hier werden typische Missverständnisse und vermeidbare Probleme in der Praxis beschrieben.

Neben dem Wegweiser-Symbol stehen Fragen, die Sie zum Nachdenken anregen sollen, damit Sie das Gelesene besser in die Praxis umsetzen können, aber auch zum Vertiefen und Wiederholen des gerade Erlernten. Betrachten Sie diese Anregungen als Stupser Ihres persönlichen Coaches, neue Dinge auszuprobieren und Ihr jetziges Projektumfeld zu hinterfragen.

Diese Übungen sollten Sie in jedem Fall dann durchführen, wenn Sie eine Prüfung zum ISTQB® Certified Tester Foundation Level anstreben. Musterlösungen dazu finden Sie am Ende des Buchs.

Mit diesem Symbol erhalten Sie Hinweise, wo Sie weitere Informationen finden können.

Hier werden besonders wichtige oder schwierige Begriffe aus dem ISTQB-Glossar und wichtige Stellen aus den Lehrplänen zitiert. Die Zitate stammen aus den aktuellen Versionen zur Zeit der Drucklegung:

Lehrplan Certified Tester Foundation Level, Version 4.0.1, 2023, ISTQB, deutschsprachige Ausgabe. Herausgegeben durch Austrian Testing Board, German Testing Board e.V. & Swiss Testing Board (Übersetzung des englischsprachigen Lehrplans des International Software Testing Qualifications Board (ISTQB), Originaltitel: Certified Tester, Foundation Level Syllabus, Version 4.0, 2023) im Folgenden nur noch kurz CTFL-LehrplanISTQB Glossar, Version V4.2.1

Begriffe können Sie unter https://glossary.istqb.org/de_DE/search in der aktuellsten Version nachschlagen.

Teil I

Testen ist mehr als die Summe seiner Teile

IN DIESEM TEIL …

Wie Sie Tests stufenweise durchführenWas Testen bedeutet und was dabei herauskommtAus welchen Aktivitäten der Testprozess bestehtWelche Ergebnisse Sie im Testen erstellen

Kapitel 1

Mal eben schnell was testen?!

IN DIESEM KAPITEL

Von Menschen und ihren SoftwareproblemenMehr als nur Fehler findenSchnelldurchlauf durch das Testen von SoftwareUnterstützung durch Werkzeuge

Vor mehr als 20 Jahren bekam ich von einem Projektleiter den Vorwurf zu hören, dass mein Team und ich »schuld sind, dass das Projekt den Meilenstein nicht halten kann, weil zu viele Fehler gefunden wurden« und die klare Anweisung »nicht mehr so intensiv zu testen, damit das Projekt nicht weiter in Zeitverzug gerät«. Es handelte sich um eines der vielen Projekte, die nie beendet, sondern nach etlichen herausgeworfenen Geldern und Hunderttausenden von Arbeitsstunden gestoppt wurden. Die Firma existierte wenige Jahre darauf nicht mehr.

Damals haben wir getestet, um die Kunden und Endnutzer des Systems vor allzu gravierenden Fehlern in der Software zu bewahren, und in der Hoffnung, dass das Projekt zu einem guten Abschluss kommt. Die Kunden und Geldgeber verlangten einen Nachweis einer ausreichenden Qualität und machten die Bezahlung zu den jeweiligen Meilenstein-Terminen von den Ergebnissen bestimmter Tests abhängig. Letztlich wollten die Kunden sichergestellt wissen, dass das Produkt möglichst keine Fehler enthält, den Anforderungen genügt und seinen Zweck erfüllt.

Warum getestet wird

Neben den Kunden und Endnutzern beziehungsweise den Geldgebern verlangen auch andere ausreichende Qualität, die durch Tests nachgewiesen werden muss. Das Projektteam möchte möglichst frühzeitig wissen, wie gut und vollständig Anforderungen und Design in dem System umgesetzt wurden – ein Testziel ist häufig neben der Abdeckung der Anforderungen auch die Überprüfung von Arbeitsergebnissen des Teams. Behörden fordern den Nachweis der Einhaltung von Vorschriften, Verordnungen, Gesetzen oder anderen Regularien sowie von Normen und Standards wie den folgenden:

Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Verordnung – BITV 2.0)

Markets in Financial Instruments Directive (MiFID II) für Banken

EU-Medizinprodukteverordnung/Medical Device Regulation (MDR) in der Medizintechnik

Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS)

ISO 26262 Road vehicles – Functional safety für Automobilbau

Diese Liste könnten Sie sicher mit den für Ihren Bereich geltenden Normen, Standards und Gesetzen noch ergänzen.

Testen beinhaltet die Verifikation der spezifischen Anforderungen an das getestete System und die Validation, ob alles so funktioniert, wie es von den Endanwendern und anderen Stakeholdern erwartet wird. Das Testteam nutzt verschiedenste Techniken, um entsprechende Fehler zu provozieren und somit das Risiko einer ungenügenden Qualität des Systems zu reduzieren.

Beispielsweise können Tester verifizieren, ob die Software gemäß den Anforderungen in der Testbasis korrekterweise ein Skonto von 4 % auf Artikel gewährt, die innerhalb von drei Tagen bezahlt werden. Sie können aber auch validieren, ob zu jedem Bezahlvorgang sichtbar ist, ob ein Skonto in Anspruch genommen wurde. Dass diese Information direkt ermittelbar ist, dass für die Anzeige beispielsweise eine eigene Zeile auf einer Bildschirmseite existiert und dass eindeutig klar ist, dass es sich hier um ein Skonto und nicht um einen anderen Rabatt handelt, sind Erwartungen, die häufig nicht dokumentiert werden. Andererseits kann die Software unbrauchbar sein, wenn diese Informationen nicht sichtbar sind – der Wert für den Kunden ist dann gering, obwohl die Software korrekt rechnet.

Verifikation: Bestätigung durch Bereitstellung eines objektiven Nachweises, dass festgelegte Anforderungen erfüllt worden sind.

Validierung: Bestätigung durch Überprüfung, dass ein Arbeitsergebnis den Bedürfnissen eines Stakeholders entspricht.

Quelle: ISTQB-Glossar

Weitere wichtige Testziele sind die Vermeidung von (Folge-)Fehlern und das Schaffen von Vertrauen in das getestete System. Wie in der Geschichte oben sollen zudem Stakeholder ausreichende Informationen für ihre Entscheidungen erhalten.

Abhängig von dem Kontext, in dem Sie arbeiten und testen, von der Anwendungsdomäne und auch von dem Zeitpunkt der Entwicklung beziehungsweise der Teststufe ändern sich die Testziele. Je später in der Entwicklung des Systems der Test durchgeführt wird und je eher mehr Kunden oder Endanwender in den Test einbezogen werden, desto weniger geht es um das Entdecken von Fehlern und umso mehr geht es darum, Vertrauen in das System aufzubauen. Beta-Tester sind häufig ausgewählte Kunden, die ein System vor allen anderen möglichen Kunden testen dürfen und dafür beispielsweise nichts oder einen geringeren Kaufpreis zahlen und andere Vergünstigungen wie einen besseren Support erhalten. Im Gegenzug erhofft sich der Hersteller des Systems positive Berichte in den Medien. Sollten doch noch Fehler vorhanden sein (und das ist meistens der Fall), dann werden diese besser früh bei wohlgesonnenen Kunden gefunden. Zudem wird bei solchen Tests überprüft, wie gut das getestete System zu den Konfigurationen und realen Systemumgebungen des Kunden passt.

Beim Testen von einzelnen Software-Komponenten liegt der Fokus dagegen auf dem Auffinden und Beseitigen von Fehlern und dem Nachweis, dass die Anforderungen umgesetzt wurden und das Design zweckmäßig ist. Genau wie man die vollständige Umsetzung von Anforderungen häufig als Testziel definiert, gibt es hier vergleichbare Überdeckungen der einzelnen Testobjekte.

Das Testen gehört zur Qualitätssteuerung, auch analytische Qualitätssicherung genannt, und prüft »im Nachhinein«, wie gut die Qualität des Produkts ist. Das gewünschte Qualitätsniveau kann mithilfe der Qualitätssteuerung durch anschließend erfolgte Korrekturen erreicht werden. Neben dem Testen zählen formale Methoden (wie Prüfung von Modellen und Korrektheitsbeweise), das Ermitteln von Kennzahlen, Simulationen und Prototyping zur Qualitätssteuerung.

Der Begriff Qualitätssicherung beinhaltet die Erwartung, dass mit der Einhaltung von Prozessen auch ausgereifte Produkte hoher Qualität entstehen. Es geht hierbei um das Vorbeugen mangelhafter Qualität durch die Definition von Dokumentvorlagen, Handlungsanleitungen und der Vorgabe von Prozessschritten. Damit wird versucht, Qualität in ein Produkt zu konstruieren (daher auch konstruktive Qualitätssicherung genannt). Testergebnisse können dabei helfen, zu erkennen, wo und mit welchen Methoden diese Prozesse verbessert werden müssen, um Qualität »von Anfang an« zu ermöglichen.

Und wer ist für die Qualität verantwortlich? Mein erster Arbeitgeber verteilte damals einen Gegenstand, auf dessen Vorderseite diese Frage gedruckt war – und auf dessen Rückseite sich ein Spiegel befand.

Ein Unternehmen gilt als umso reifer,

je weniger das Testen mit dem bloßen Ziel der Suche nach Fehlern im System durchgeführt wird,

je mehr Testen als Möglichkeit gesehen wird, die Effektivität der Maßnahmen der konstruktiven Qualitätssicherung nachzuweisen und

je systematischer Grundursachen von Fehlern ermittelt werden, um Fehler dauerhaft zu vermeiden und insgesamt die Prozesse kontinuierlich zu verbessern.

Warum testen Sie?

Was haben Sie an Regularien, Gesetzen oder Normen zu beachten?

Wo sind die Testziele dokumentiert?

Was beim Testen an Fehlern & Co. herauskommt

Haben Sie schon einmal erlebt, dass Entwicklerinnen oder Entwickler empfindlich auf das Wort »Fehler« oder »Bug« reagiert haben? Es kann an Ihrem Auftreten und an Ihrem Tonfall liegen und natürlich an der jeweiligen Person, aber es liegt häufig daran, dass zum Zeitpunkt des Testens oft noch gar nicht feststeht, ob es sich wirklich um einen Fehler handelt oder um etwas anderes, wie beispielsweise einen Änderungswunsch oder einen Irrtum des Testers.

Rund um das Testen gibt es viele Fehlerbegriffe, die im Rahmen des ISTQB® Certified Tester definiert wurden, um ein einheitliches Verständnis zu schaffen. Alles beginnt mit einer Fehlhandlung (error), also damit, dass

jemand etwas Falsches macht, zum Beispiel eine widersprüchliche oder unrealistische Anforderung definiert oder eine Codezeile fehlerhaft programmiert,

oder dass jemand etwas nicht tut, zum Beispiel eine Anforderung nicht im Design berücksichtigt und diese damit dann auch im Code fehlt oder

dass jemand etwas zu viel macht, zum Beispiel zusätzliche Funktionalitäten programmiert, die vom Kunden gar nicht gewünscht sind.

Kurz gesagt: Durch eine Fehlhandlung werden Fehlerzustände (Bugs oder Ungeziefer) in den Code eingefügt (siehe Abbildung 1.1).

Abbildung 1.1: Fehlhandlung – Fehlerzustand – Fehlerwirkung

Die Fehlhandlung führt zu einem Fehlerzustand (defect)in einem Arbeitsergebnis, zum Beispiel in den Anforderungen, in einem Designdokument, in Codezeilen oder in einem Testfall. In Abbildung 1.1 handelt es sich sogar um drei Fehlerzustände, wobei der Tester rechts außen offensichtlich nur eine Fehlerwirkung (failure) (ein angefressenes Blatt) sieht. Manchmal werden keine oder nicht alle Fehlerwirkungen sichtbar. Dies kann aus mehreren Gründen passieren:

weil der Fehlerzustand zwar noch im Dokument (beispielsweise den Anforderungen) enthalten ist, aber in einem Folgedokument (beispielsweise dem Design und dem Code) keinen Folge-Fehlerzustand erzeugt hat (vielleicht weil jemand gut aufgepasst hat)

weil es keinen Test gab, der dazu geeignet war, die Fehlerwirkung zu provozieren

weil ein weiterer Fehlerzustand den anderen Fehlerzustand maskiert, die Fehlerwirkung also unsichtbar macht

Beispielsweise könnte eine fehlerhafte Berechnung maskiert sein, sodass aufgrund eines anderen Fehlerzustands die Ergebnisse gar nicht angezeigt werden. Schlimmstenfalls fällt die fehlende Anzeige dem Tester nicht auf.

Testen Sie, dann finden Sie erst mal Abweichungen zwischen dem von Ihnen erwarteten Soll-Verhalten des Systems und dem tatsächlichen Ist-Verhalten. Das erwartete Soll-Verhalten ist das sogenannte erwartete Ergebnis, also das Verhalten des Getesteten, das Sie zum Beispiel auf Basis einer Spezifikation vorhergesagt haben. Außer der Spezifikation können Sie auch ein anderes System für Vorhersagen nutzen, zum Beispiel ein abzulösendes Altsystem oder das Produkt eines Mitbewerbers. Sie nutzen dazu vielleicht auch ein Nutzungshandbuch oder die Ergebnisse aus Interviews mit Experten oder Ihre eigene Erfahrung. Bei diesen Informationsquellen handelt es sich um Testorakel. Das denkbar schlechteste Testorakel für den Test von Code ist der Code selbst – die Wahrscheinlichkeit, dennoch Fehlerwirkungen aufzudecken, ist eher gering und sollte daher nicht genutzt werden.

Vermutlich müssen Sie gar nicht lange suchen, um einen »Fehler« in Software zu finden. Vielleicht ist auch, während Sie dieses lesen, gerade wieder etwas ganz aktuell in den Medien. Versuchen Sie doch mal, die Nachricht mithilfe der oben genannten Begriffe nachzuerzählen. Wie viel erfahren Sie von dem tatsächlichen Fehlerzustand in den Medien? Wie ist das in Ihrem Unternehmen?

Wie Testen funktioniert

Wenn Sie schon seit vielen Jahren als Testerin oder Tester arbeiten, kann es natürlich sein, dass Sie Software vorgelegt bekommen, sofort ein paar Eingaben machen und gleich auch ein paar Fehlerwirkungen feststellen, die schon ausreichend sind, um das Ganze wieder an das Entwicklungsteam zurückzugeben. Das Testen war damit erfolgreich, das Projekt wohl weniger.

In den allermeisten Fällen funktioniert das Testen aber geplant und mit verschiedenen einzelnen Aktivitäten:

Testplanung

Testüberwachung und -steuerung

Testanalyse

Testentwurf

Testrealisierung

Testdurchführung

Testabschluss

Diese Aktivitäten können überlappend oder auch parallel durchgeführt werden und sind je nach dem jeweiligen Projekt und der jeweiligen Anwendungsdomäne unterschiedlich formal. In den nachfolgenden Abschnitten erhalten Sie eine erste Übersicht über die einzelnen Aktivitäten.

Testplanung

Häufig ist es das Qualitäts- oder Testmanagement, das die Testplanung(und Teststeuerung) durchführt. Dabei wird dokumentiert,

wer testet (Rollen, Verantwortlichkeiten) sowie

was (Testziele, Testobjekte),

wann (zeitliche Planung),

womit (Testumgebung, Werkzeuge, sonstige Hilfsmittel, räumliche, personelle, finanzielle Ressourcen) und

mit welcher Vorgehensweise (strategische Überlegungen, Voraussetzungen für das Testen, Grundlagen des Testens, Methodiken) getestet wird.

In Abbildung 1.2 ist dies die erste Aktivität. Sie wird vom Testmanager ausgeführt.

Abbildung 1.2: Aktivitäten im Testprozess

Die Ergebnisse dieser Planungen werden in einem Testkonzept zusammengefasst. Ähnlich wie im Projektmanagement enthält es alle Informationen zur Planung des Testprojekts und berücksichtigt dabei Budget-, Personal- und Zeitvorgaben sowie die spezifischen Risiken des Testprojekts. Ein Testkonzept wird durch das Testmanagement in Absprache mit allen Stakeholdern erstellt und von der Entwicklungs- oder Projektleitung unterschrieben. Damit entsteht eine Art Vertrag, in der alle Seiten vereinbaren, was wer zum Testen beiträgt.

Das Testkonzept ist damit wie in Abbildung 1.2 gezeigt das zentrale Dokument, das als Grundlage (gestrichelte Pfeile) für alle anderen Aktivitäten im Testprozess dient. Der Übersichtlichkeit halber sind allerdings nur die wichtigsten dargestellt.

Meistens orientieren sich die Vorgaben der Unternehmen an Standards: häufig noch an dem mittlerweile veralteten IEEE-Standard for Software and System Test Documentation IEEE Std 829™-1998, aber immer öfter an dem aktuellen ISO/IEC/IEEE 29119, der in diesem Buch genutzt wird. In der agilen Softwareentwicklung (siehe Abschnitt »Testen im agilen Kontext« in Kapitel 3) ist dagegen eher ein kurzer Abriss mit den wichtigsten offenen und vereinbarten Punkten zu sehen, oft genug gibt es kein explizites Testplanungsdokument.

Verwechseln Sie das Testkonzept nicht mit dem Testplan. Der Testplan (engl. test schedule) enthält die zeitliche Planung und gegebenenfalls noch Zuordnungen von Personen zu Arbeitspaketen und Aufgaben. Der Testausführungsplan beinhaltet wiederum nur die zeitliche Planung der Testdurchführung. Das Testkonzept (engl. test plan) ist dagegen ein umfassendes Dokument, das den Testplan beinhalten kann. Werden häufiger zu ändernde Teile wie beispielsweise Testplan und das Risikomanagement in andere Dokumente ausgelagert, ist das Testkonzept ein sehr stabiles Dokument.

Falls Sie in einem Unternehmen arbeiten, das für das Testkonzept (und natürlich auch alle anderen nachfolgend genannten Dokumente) andere Begriffe benutzt, erstellen Sie sich am besten ein persönliches Glossar mit den passenden »Übersetzungen«. Notieren Sie dann auch, wo es für diese Dokumente Unterschiede zu den hier benutzten Definitionen gibt.

Zur Testplanung gehört die Berücksichtigung vieler einzelner Aspekte, über die Sie sich im Abschnitt »Wer beim Planen scheitert« in Kapitel 12 detailliert informieren können.

Testüberwachung und -steuerung

Wenn eine Testmanagerin den Testprozess beobachtet und mit ihrer ursprünglichen Planung vergleicht, bedeutet es, dass sie eine Reihe von Kennzahlen erfasst oder dass Sie als Tester diese bereitstellen. Solche Kennzahlen sind beispielsweise die Anzahl der geplanten Testfälle und der durchgeführten Testfälle. Alle Kennzahlen werden von ihr ausgewertet und entsprechend zur Testüberwachung und -steuerung genutzt. Außerdem wird sie immer wieder genau hinsehen, um drohende Probleme frühzeitig zu erkennen und entsprechend zu handeln (also Risiken zu managen). Tut sie das nicht, dann wird die Testmanagerin von den Problemen gemanagt und kann nur noch Feuerlöscher spielen. Eine gute Testmanagerin wird Sie als Tester optimal einbinden. Sie sind also nicht nur Lieferant von Kennzahlen, sondern werden die Analyseergebnisse mit interpretieren, Sie werden auf Risiken hinweisen und diese aktiv durch Ihre Testaufgaben vermeiden oder zumindest den möglichen Schaden reduzieren, indem Sie beispielsweise Workarounds vorschlagen.

Die Testüberwachung und -steuerung wird, wie in Abbildung 1.2 gezeigt, während des gesamten Testprozesses über alle anderen Aktivitäten hinweg durchgeführt.

Testanalyse

Der Begriff kann leider in die Irre leiten: Nicht der Test wird analysiert, sondern die Testbasis – die Aktivität Testanalysebestimmt also, »was zu testen ist«.

Testbasis: Alle Informationen, die als Basis für die Testanalyse und den Testentwurf verwendet werden können.

Quelle: ISTQB-Glossar

Beispiele für die Testbasis sind:

Dokumente mit Anforderungsspezifikationen

Funktionale und nicht-funktionale Anforderungen, wie beispielsweise die Performanz (mehr dazu in

Kapitel 11

)

Epics und User Storys (siehe Abschnitt »Testen im agilen Kontext« in

Kapitel 3

)

Anwendungsfälle (Use Cases), Geschäftsvorfälle, Business-Modelle

Verträge, Normen, Standards, Gesetze und andere Regularien

System- oder Softwarearchitekturdokumente

Architekturdiagramme/-dokumente

Spezifikationen an Entwurf und Komponenten (zum Beispiel Diagramme der Unified Modeling Language (UML) oder Entity-Relationship-Diagramme)

Spezifikationen an Schnittstellen

Erstellte Module oder Systemteile sowie das ganze System

Code

Benutzerschnittstellen (Masken, Bedienoberflächen)

Datenbank-Metadaten

Datenbankabfragen (Queries) und Berichte

Schnittstellen zu anderen Systemteilen oder Systemen

Marketingdokumente

Flyer und andere dokumentierte Marketing-Versprechen

(Messe-)Prototypen

Projektmanagementergebnisse

Projektanträge (also die Versprechen der Projektleitung an das Management)

Risikoanalysen (vor allem soweit sie funktionale und nicht-funktionale Aspekte des Produkts betreffen)

Gute Tester nutzen die Testbasis nicht einfach, sondern bewerten sie auch hinsichtlich ihrer Qualität (siehe Kapitel 5).

Das Testkonzept unterstützt – wie in Abbildung 1.2 gezeigt – diese Aufgabe, in dem es unter anderem die Vorgehensweise und die anzuwendenden Testverfahren darstellt. Das Ergebnis der Testanalyse sind die Testbedingungen für jedes Testobjekt.

Wenn Sie jetzt raten, was eine Testbedingung ist, liegen Sie vermutlich nicht richtig – tut mir leid. Eine Testbedingung ist nämlich nicht die Vorbedingung für den Test (obwohl es ganz ähnlich klingt), sondern beispielsweise eine zu testende Funktion (Beispiele sind »Benutzer anlegen«, »Rechnung bezahlen« oder »Position abfragen«) oder ein zu prüfendes Qualitätsmerkmal (Beispiele sind »Korrektheit« oder »Performanz«). Die Testbedingung wird in Abbildung 1.2 als Dokument mit einem großen Q dargestellt. Nur sehr selten handelt es sich aber um separate Dokumente, meist sind es Auflistungen der zu testenden Merkmale oder auch einfach die ersten Entwürfe der Testfälle. Dann stellen die Kurzbeschreibungen der Testfälle die Testbedingungen dar und müssen später mit der genauen Beschreibung, den erwarteten Ergebnissen und weiteren Details ergänzt werden.

Testbedingung: Ein testbarer Aspekt einer Komponente oder eines Systems, der als Grundlage für das Testen identifiziert wurde.

Testobjekt: Das zu testende Arbeitsergebnis.

Quelle: ISTQB-Glossar

Halten Sie doch mal einen Moment inne und überlegen Sie, welche Dokumente in Ihrem Projekt oder Ihrem Unternehmen als Testbasis geeignet wären. Was würden Sie sich wünschen? Worauf haben Sie (keinen) Zugriff? Was ist zwar vorhanden, aber für Sie noch nicht gut genug? Was fehlt noch?

Überlegen Sie, was Sie daran ändern könnten.

Kennen Sie schon Testtechniken (wie im Kapitel 7 beschrieben)? Was würde Ihnen helfen, um die Testbasis für diese Testtechniken zu verbessern?

Testentwurf

Im Testentwurfnutzen Sie die Testbedingungen je Testobjekt und die detaillierten Testverfahren und erzeugen abstrakte Testfälle, das heißt solche, in denen die genutzten Testdaten beschrieben, aber noch nicht genau genannt werden. Beispielsweise notieren Sie im abstrakten Testfall, dass eine Person erwachsen sein soll, der Testwert wird im abstrakten Testfall also »> 17« lauten. Mehr dazu erfahren Sie in Kapitel 6.

Testfall: Eine Menge von Vorbedingungen, Eingaben, Aktionen (falls anwendbar), erwarteten Ergebnissen und Nachbedingungen, die auf Basis von Testbedingungen entwickelt wurden.

abstrakter Testfall: Ein Testfall mit abstrakten Vorbedingungen, Eingabedaten, erwarteten Ergebnissen, Nachbedingungen und Aktionen (falls anwendbar).

Quelle: ISTQB-Glossar

Die erzeugten Testfälle werden priorisiert und zusammengestellt. Dabei werden, wie auch schon bei der Testanalyse, häufig weitere Probleme in der Testbasis entdeckt, die dann frühzeitig behoben werden können.

Abbildung 1.2 zeigt, dass hierbei erste Kennzahlen ermittelt und zumeist in einer Datenbank gesammelt werden wie beispielsweise die Anzahl von Testfällen, sodass das Testmanagement den Fortschritt bei der Erstellung beurteilen kann.

Testrealisierung

Jetzt wird es konkret: Die abstrakten Testfälle werden mit den genauen Daten gefüllt und zu konkreten Testfällen. Beispielsweise wählen Sie im konkreten Testfall für einen Testwert »> 17« nun den Wert »25«. Zur Testrealisierunggehört auch das Erzeugen von Testskripten, die dann automatisiert ausgeführt werden. In Abbildung 1.2 erkennen Sie, dass auch die Testrealisierung Kennzahlen erzeugt, wie beispielsweise der Anteil der automatisierten zu den manuellen Tests.

Ob manuell oder automatisiert: Tests werden entsprechend ihrer Priorisierung und einer sinnvollen zeitlichen Abfolge zusammengestellt. Diese sogenannten Testsuiten sorgen vor allem dann für eine reibungslosere Testdurchführung, wenn sie abhängig von der Analyse der jeweiligen Risiken (siehe Kapitel 14) erarbeitet wurden. Wenn es nicht so klappt wie optimistisch von dem Projektmanagement oder dem Testmanagement geplant, werden durch die risikoorientierte Priorisierung die kritischsten Tests zuerst durchgeführt und die weniger kritischen zur Not fallen gelassen.

konkreter Testfall: Ein Testfall mit konkreten Werten für Vorbedingungen, Eingaben, erwartete Ergebnisse und Nachbedingungen sowie eine detaillierte Beschreibung der Aktionen (falls anwendbar).

Testsuite: Eine Menge von Testskripten oder Testabläufen, die in einem bestimmten Testlauf ausgeführt werden sollen.

Quelle: ISTQB-Glossar

Testdurchführung

Je nachdem, in welchem Umfeld Sie testen, werden Sie während der Testdurchführungmehr oder weniger protokollieren. Dazu gehören möglicherweise das Erzeugen von Nachweisen (evidence), meist Bildschirm-Ausdrucke, die das tatsächliche Testen belegen, und darüber hinaus auch das Erzeugen von Kennzahlen. Außerdem werden Sie beim Testen alle Auffälligkeiten und Abweichungen des erwarteten zum tatsächlichen Ergebnis dokumentieren und alle Informationen notieren, die den Test nachvollziehbar, reproduzierbar und damit den Fehlerzustand auffindbar und behebbar machen.

In Abbildung 1.2 sehen Sie, wie der Testmanager nach der Durchführung der Tests sowohl die Kennzahlen als auch direkt Fehlerberichte und Testprotokolle nutzt, um damit Entscheidungen über die Fortführung der Tests treffen zu können.

Testergebnis: Das Ergebnis und die Konsequenz der Durchführung eines Tests.

erwartetes Ergebnis: Das beobachtbare vorausgesagte Verhalten eines Testelements unter bestimmten Bedingungen, basierend auf seiner Testbasis.

Istergebnis: Im Test beobachtetes/erzeugtes Verhalten einer Komponente oder eines Systems unter festgelegten Bedingungen.

Quelle: ISTQB-Glossar

Testabschluss

Im Testabschlusswerden die Ergebnisse des Testens an die Stakeholder berichtet und – wie beim Abschluss des gesamten Projekts – alle benötigten Materialien (Testwerkzeuge, Testfälle, Testprotokolle und andere Testdokumente) entweder archiviert oder für die erneute Nutzung in einem nächsten Release aufbereitet. Wie in Abbildung 1.2 zu sehen, ist dies wieder eine Aufgabe der Testmanagerin.

Zudem sollten die gemachten Erfahrungen gesammelt und aufbereitet werden, sodass das nächste Testprojekt oder Software-Release davon profitieren kann.

Wie Werkzeuge das Testen unterstützen

In allen Testphasen können Sie unterschiedlich spezialisierte Werkzeuge nutzen. Immer noch sehr häufig setzen Unternehmen eine Textverarbeitung für das Testkonzept und alle Berichte ein sowie eine Tabellenkalkulation zur Ermittlung von Testfällen und zur Dokumentation der Testdurchführung. Wesentlich weniger aufwendig, weniger fehleranfällig und auch angenehmer in der Nutzung sind spezielle Testmanagementtools, die die Eingabe über unterschiedliche Formular-Ansichten ermöglichen und ausgefeilte Berichtsmöglichkeiten bieten. Solche Tools gibt es als freie Software und auch von namhaften Firmen in den unteren Preisklassen. Zur automatisierten Testdurchführung und für verschiedene Testmethoden vor allem nicht-funktionaler Tests gibt es Spezialwerkzeuge. Eine detaillierte Übersicht über Testwerkzeuge finden Sie in Kapitel 18, »Werkzeuge des Testens«.

Kapitel 2

Grundlegendes Handwerkszeug

IN DIESEM KAPITEL

Was alles zum Testen dazu gehörtGrundsätze des TestensDie Moral der Tester

Eine zentrale Idee hinter dem Lehrplan zum Certified Tester ist es, dass alle einen einheitlichen Test-Wortschatz nutzen, der überall auf der Welt genutzt wird. Dies betrifft Begriffe rund um das Testen, aber auch ein gleichartiges Verständnis der Aktivitäten und Prozesse im Test, einiger Grundsätze des Testens und das Einverständnis mit den ethischen Grundlagen. Stand Ende 2017 gibt es laut ISTQB 82 Länder, die von einem der nationalen Boards betreut werden, und 120 Länder, in denen sich Tester zertifizieren ließen – Sie können sich also mit einem Certified-Tester-Foundation-Level-Zertifikat tatsächlich weltweit bewerben.

Fehlverhalten erzeugt Fehlerzustände

Wenn Sie zwischen Fehlerzustand und Fehlerwirkung nicht unterscheiden (wollen), werden Sie allgemeiner von einem Fehler sprechen. Das wohl ebenso häufig gebrauchte Wort »Bug« rührt daher, dass einer der ersten dokumentierten Fehler in einem Computer tatsächlich eine Motte war.

Fehlerzustände entfernen

Das Debuggensoll die Motten aus dem System entfernen: Damit steht Debuggen für das Lokalisieren, Analysieren und Entfernen der Ursache von Fehlerwirkungen, also den Fehlerzuständen (im Code).

Der Debugger kann zwar auch als Testwerkzeug genutzt werden (siehe Kapitel 18, »Werkzeuge des Testens«), die Tätigkeit des Debuggens sollten Sie dennoch nicht mit der Tätigkeit des Testens verwechseln. Debuggen gehört mit dem Entwickeln zu den konstruktiven Aktivitäten bezogen auf das Testobjekt. Testen wird mit der Absicht, das Testobjekt zu »zerstören« (als destruktive Aktivität) durchgeführt – das aber erfordert meist sehr viel Kreativität bei der »Konstruktion« der Testfälle. Sie sehen, das ist ein wenig Wortklauberei: Sie als Tester sind sicher kein »destruktiver Mensch«.

Vielleicht kennen Sie noch die Aussage, dass Entwickler nicht testen können oder dass sie von »Testen« sprechen, aber eigentlich »debuggen« meinen. Das mag bei manchen immer noch so sein, kommt aber zunehmend seltener vor, und in einem »echten« agilen Kontext testen Entwickler tatsächlich intensiv.

Stellen Sie sich vor, Sie sollten eine Webanwendung für einen Shop testen. Als Tester entdecken Sie, dass grundsätzlich alle Artikel in Ihrem Warenkorb eine ausgewiesene Mehrwertsteuer von 19 % haben, obwohl sich zum Beispiel auch Bücher darin befinden. Also haben Sie eine Fehlerwirkung entdeckt und dokumentieren dies in einem Fehlerbericht.

Die zuständige Entwicklerin bekommt diesen Fehlerbericht und analysiert nun ihr Programm. Sie weiß, dass sie die Mehrwertsteuer berücksichtigt und eine Funktionalität Ermittle_MwSt implementiert hatte. Warum nur funktioniert das offensichtlich nicht? Sie reproduziert die Fehlerwirkung. Dazu nutzt sie einen Debugger und stellt fest, dass eine falsche Abfrage dafür sorgt, dass Ermittle_MwSt immer mit dem gleichen Parameter und nicht mit den Artikelnummern aus dem Warenkorb versorgt wird. Sie hat den Fehlerzustand gefunden.

Sie erinnert sich, dass sie während der Codierung versuchsweise einen festen Wert übergeben und vergessen hatte, das wieder rückgängig zu machen. Sie hatte also eine Fehlhandlung begangen. Als gute Entwicklerin überlegt sie nun, wo sie diese Änderung noch vorgenommen hatte und korrigieren muss. Auch fällt ihr auf, dass eine weitere Auswirkung dieses Fehlerzustands möglicherweise korrupte Daten sind, also prüft und korrigiert sie auch einige Inhalte einer Datenbanktabelle.

Anschließend gibt sie die Anwendung für einen Fehlernachtest zurück an das Testteam.

Wenn Sie neu in einem Projekt oder einem Unternehmen sind, dann erkundigen Sie sich früh danach, welche Begrifflichkeiten für »Fehler« genutzt werden und welche eher verpönt sind. Zunehmend häufiger werden scheinbar neutraler wirkende Begriffe wie »Abweichung« oder »Issue« genutzt. Das bedeutet meist, dass noch nicht klassifiziert wurde, ob es sich um eine »Fehlerwirkung« oder einen »Fehlerzustand« handelt oder zum Beispiel um einen »Verbesserungsvorschlag« oder einen »Änderungswunsch«. Beide Begriffe werden typischerweise genutzt, bevor das System in Betrieb geht.

In manchen Branchen gibt es außerdem die Unterscheidung zwischen »Incident« und »Problem«, die aus dem IT-Service-Management und dem De-facto-Standard der Information Technology Infrastructure Library (ITIL) rühren. Incidents sind alle Arten von Störungen im Betrieb (und damit nach dem Release) der Software, die behoben werden müssen. Manche dieser Incidents basieren auf Problemen, haben also tiefergehende Ursachen wie zum Beispiel Fehlerzustände im Code, die dann in nachfolgenden Versionen behoben werden.

Fehler analysieren

Die Analyse einer Fehlerwirkung führt zum Auffinden eines oder mehrerer Fehlerzustände. Untersuchen Sie die Fehlerzustände genauer, können Sie die Grundursachen herausfinden, also was ursächlich zum Fehlerzustand führte. Damit eröffnet sich Ihnen die Chance, den Fehlerzustand künftig zu vermeiden oder zumindest sicherer als Fehlerzustand oder als Fehlerwirkung zu entdecken, indem Sie Ihre Vorgehensweise beim Testen entsprechend anpassen und geeignete Testarten nutzen.

Testart: Eine Gruppe von Testaktivitäten basierend auf bestimmten Testzielen mit dem Zweck, eine Komponente oder ein System auf spezifische Merkmale zu prüfen.

Quelle: CTFL-Glossar

Funktionale Tests prüfen, ob das Testobjekt das tut, was es tun soll, vor allem, ob alle funktionalen Anforderungen vollständig erfüllt sind, ob es korrekt arbeitet und ob die funktionale Angemessenheit gegeben ist, also das Testobjekt die damit verbundene Arbeitsaufgabe – meist des Nutzenden – adäquat erfüllt.

Nicht-funktionale Tests prüfen, wie gut das Testobjekt die nicht-funktionalen Anforderungen erfüllt, beispielsweise wie gut die Gebrauchstauglichkeit (Usability), die Nutzung von Ressourcen (beispielsweise Speicher) ist oder wie schnell das System auf Eingaben antwortet. Die ISO/IEC 25010 enthält eine Klassifikation solcher Qualitätsmerkmale wie

Performanz

Kompatibilität

Gebrauchstauglichkeit

Zuverlässigkeit

IT-Sicherheit

Wartbarkeit

Übertragbarkeit

Planen Sie nicht-funktionale Tests so früh wie möglich ein. Meist verwenden Sie dafür von funktionalen Tests abgeleitete Testfälle, die dann auf einen nicht-funktionalen Aspekt abzielen. Werden nicht-funktionale Tests erst spät im Lebenszyklus einer Software durchgeführt, müssen unter Umständen weitreichende Änderungen an der Architektur oder an der Oberfläche durchgeführt werden, die dann sehr aufwändig und damit teuer werden.

Auch wenn die Gebrauchstauglichkeit möglicherweise erst spät durchgeführt werden kann, ist das frühe Einplanen wichtig, um beispielsweise Gebrauchstauglichkeitslabore (Usability-Labore) frühzeitig reservieren zu können.

Der Black-Box-Test (basierend auf Spezifikationen) und der White-Box-Test (basierend auf der Implementierung oder der internen Struktur eines Systems) sind weitere Testarten.

Mehr erfahren Sie dazu in Kapitel 7, »Black-Box-Verfahren«, Kapitel 8, »White-Box-Verfahren« und Kapitel 9, »Mehr als bloße Intuition«.

Nachdem der Fehlerzustand behoben wurde, werden Sie einen Fehlernachtest durchführen, um zu prüfen, ob die Korrektur erfolgreich war. Zudem hilft die Analyse der Auswirkungen, Folgefehler zu erkennen und den Umfang der Tests zu optimieren, die Sie erneut durchführen, um eventuelle ungewollte Seiteneffekte durch die Korrektur des Fehlerzustands zu erkennen (Regressionstests).

Fragen Sie sich immer wieder »Was noch? Warum? Wo auch?«, um den eigentlichen Problemen auf den Grund zu gehen und diese ein für alle Mal zu beseitigen.

Falsch positiv und falsch negativ

Falsch positive Testergebnisse sind solche, bei denen sich im Nachhinein herausstellt, dass der Testfall das Vorhandensein eines Fehlerzustands anzeigt, obwohl es diesen Fehlerzustand nicht im Testobjekt gibt. Solche Testergebnisse kosten unnötigen Aufwand – vor allem in der Entwicklung, daher sollten Sie Testergebnisse immer prüfen.

Nehmen Sie an, Sie hätten einen Testfall, mit dem Sie die Kundin »Marianne Ostermeier« aus der Datenbank löschen und anschließend über die Suchfunktion prüfen sollen, dass diese Kundin nicht mehr vorhanden ist. Sie stellen aber fest, dass eine Kundin mit diesem Namen auch nach dem Löschen noch gefunden wird, und melden dies als Fehler. Nach einer Analyse stellt die Entwicklerin dann fest, dass es in der Datenbank zwei Kundinnen mit dem gleichen Namen gab – der Testfall war vermutlich zu ungenau, und Sie hatten daher ein falsch positives Testergebnis.

Falsch negative Testergebnisse sind solche, die keinen Fehlerzustand anzeigen, obwohl das Testobjekt einen (oder sogar mehrere) hat. Diese Testergebnisse sorgen für eine schlechtere Qualität. Sie werden – wenn überhaupt – nur dann erkannt, wenn nachfolgende Tests oder die Nutzung des Systems eine entsprechende Fehlerwirkung aufzeigen und Sie analysieren, warum das nicht bereits in früheren Tests gefunden wurde.