Elisabeth Hendrickson Übersetzerin: Meike Mertsch

Transkript

1

2 Elisabeth Hendrickson arbeitet als Testerin, Entwicklerin und»agile-enabler«. Im Jahr 1980 schrieb sie ihre erste Codezeile und fand sofort ihre ersten Fehler gewann sie den renommierten Gordon Pask Award von der Agile Alliance. Sie ist bekannt für ihren Google Tech Talk über Agile Testing sowie ihre beliebten Testheuristiken-Spickzettel. Sie teilt ihre Zeit auf zwischen lehren, vortragen, schreiben, programmieren und der Arbeit in agilen Teams, die ihr Engagement beim Testen sehr schätzen. Übersetzerin: Meike Mertsch arbeitet als begeisterte Testerin für Magine AB in Stockholm, Schweden. Sie hat einen Hintergrund als agiler Entwickler und Coach und ein Faible für leichtgewichtige Methoden wie Kanban und Personal Kanban sowie agiles Entwickeln und Testen. In ihrer Freizeit läuft und skatet sie durch Stockholm oder macht die Kletterhallen und Felsen in der Nähe unsicher. Zu diesem Buch sowie zu vielen weiteren dpunkt.büchern können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus + :

3 Elisabeth Hendrickson Explore It! Wie Softwareentwickler und Tester mit explorativem Testen Risiken reduzieren und Fehler aufdecken Aus dem Amerikanischen übersetzt von Meike Mertsch

4 Elisabeth Hendrickson Übersetzung: Meike Mertsch, Stockholm Lektorat: Christa Preisendanz Copy-Editing: Ursula Zimpfer, Herrenberg Satz: Petra Strauch, just in print, Bonn Herstellung: Birgit Bäuerlein Umschlaggestaltung: Helmut Kraus, Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. ISBN: Buch PDF epub Auflage, Translation Copyright für die deutschsprachige Ausgabe 2014 dpunkt.verlag GmbH Wieblinger Weg Heidelberg Copyright der amerikanischen Originalausgabe 2013 The Pragmatic Programmers, LLC. Title of American original: Explore It! Reduce Risk and Increase Confidence with Exploratory Testing Pragmatic Bookshelf, The Pragmatic Programmers, LLC, Dallas, Texas, Raleigh, North Carolina ISBN-13: 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 v Geleitwort Eine kleine Gruppe von Menschen kann das Denken und Handeln von vielen beeinflussen, indem sie unzählige Entscheidungen in ein logisches Artefakt zusammenfasst, das wir»computerprogramm«nennen. Der volle Umfang dieses Einflusses lässt sich nicht im Voraus abschätzen. Für die Entwickler bleibt die spannende Frage offen: Gibt es noch etwas, das wir ändern wollen? Es gibt die philosophische Frage, woher wir wissen, was wir wissen? Es gibt die ökonomische Frage, wann wir genug wissen, um mit Zuversicht weiterzumachen? Es gibt die psychologische Frage, wie wir uns gegenseitig überzeugen, dass noch eine weitere Änderung nötig ist oder auch nicht? Elisabeth Hendrickson zeigt uns, wie wir diese Fragen durch methodische Nachforschungen beantworten können; wir nennen es exploratives Testen. Elisabeth vermittelt ihr Wissen mit der Autorität einer erfolgreichen Fachfrau und einer erfahrenen Lehrerin. Sie hat mit explorativem Testen in agilen Entwicklungen Pionierarbeit geleistet, und das über die ganze Zeit, in der sich diese Methoden in der Praxis etablierten. Und sie ist ein teilnahmsvoller Mensch, der erfolgreich mit diesem Buch vermittelt hat, welch Freuden sowohl die gemeinsame Zusammenarbeit als auch Entdeckungen bereiten, die andere Leute wertschätzen. Exploratives Testen ist wichtig. Obwohl sich der Ansatz in jeder Art Entwicklung bewährt, ist er besonders im agilen Umfeld geeignet, wo schnelle (Entwicklungs-)Zyklen und plötzliche Änderungen normal sind. Die Entwicklungs- und Testmethoden teilen viele Gemeinsamkeiten. Beide bevorzugen gut durchdachtes handwerkliches Können. Beide erkennen an, dass Entscheidungen selbst dann in einem Geschäftskontext stehen, wenn sie sehr technisch und sogar unklar sind. Exploratives Testen kann man lernen. Exploratives Testen bietet neue Ansätze für traditionelle Probleme. Elisabeth weicht alten Kämpfen aus, indem sie bestätigt, was sich nicht geändert hat: Risi-

6 vi Geleitwort ken und die Zuversicht, die daher rührt, dass man diese im Auge behält. Dann arbeitet sie sich als Geschichtenerzählerin von den Grundlagen bis zu einer klaren Beschreibung jeder Praktik mit einer Sammlung an Tipps für besseres Arbeiten vor. Jedes Kapitel schließt mit Praxisübungen, die Sie sofort in Ihrem eigenen Umfeld anwenden können. Exploratives Testen begeistert. Ohne den Wert vieler spezieller Testmethoden schmälern zu wollen, zeigt sich exploratives Testen als der am vielseitigsten anwendbare und eindeutigsten gemeinschaftliche Prozess, den ein Team nutzen kann, um Einsichten über das eigene Produkt zu gewinnen und darüber, wie andere es erleben werden. Es belohnt Neugier mit Informationen, die sowohl begeistern als auch immensen Geschäftswert liefern können. Ward Cunningham Portland, Oregon

7 vii Geleitwort zur deutschen Ausgabe Die Geschichte des explorativen Testens ist eine Geschichte voller Missverständnisse. Worte und Begriffe wie»freies Testen«,»erfahrungsbasiert«und»unstrukturiert«werden von Leuten im deutschen Sprachraum meistens zuerst mit explorativem Testen assoziiert. Das ist mehr als schade. Vor ein paar Jahren bekam ich eine Anfrage von einem Anbieter im Mobilfunkbereich. Ich hatte bereits eine eintägige Schulung zu agilem Testen dort gegeben. Neben Testautomatisierung und ATDD (Acceptance Test-Driven Development) bin ich auch auf exploratives Testen eingegangen. Darum sollte es jetzt konkret gehen. Drei Teams wollten ihren alten Verbundtest klassisch geprägt durch Testpläne und traditionelle Testfalldokumente 6 Wochen vor der Auslieferung ersetzen ein Szenario, das für agile Teams nicht unüblich ist. Mit jedem zusätzlichen Sprint wächst schließlich der Regressionsbedarf in der Software stetig weiter an und damit auch der Aufwand, den ein traditionell orientierter Test benötigt. Ich verbrachte mit jedem Team jeweils einen Tag. Wir trafen uns morgens, verschafften uns einen Überblick über die anstehende Arbeit für einen Verbundtest, schrieben Test-Charter und teilten uns über den Tag verteilt in Paare auf. Am Ende des Tages gab ich noch ein paar Tipps für das weitere Vorgehen beim kurz bevorstehenden Verbundtest. Das Nächste, was ich von den Teams hörte, war, dass die neue Vorgehensweise beim Verbundtest allen Beteiligten mehr Freude bereitete. Angefangen bei den Teammitgliedern, die jetzt stark in die Testplanung involviert waren, über die Testmanager, die jetzt mehr Zeit zur Verfügung hatten, um ihren leitenden Tätigkeiten nachzukommen, bis hin zu den Programmierern und Product Owners, die jetzt einen echten Einblick in die Tätigkeiten der Tester bekommen konnten. Die Teams hatten es geschafft, den traditionell-orientierten, 6 Wochen dauernden Verbundtest durch einen Test in einem Sprint von zwei Wochen mithilfe von explorativem Testen zu ersetzen. Diese Ergebnisse sind kein Einzelfall. Als Beispiel kann noch die Testing Community of Practice einer Firma mit mehr als 40 Scrum-Teams angeführt werden. Obwohl die Tester große Zuversicht in ihre Software hatten, haben wir an

8 viii Geleitwort zur deutschen Ausgabe einem Tag mit nur 16 Leuten noch einige Fehler finden können, die zum Teil kritisch für die Auslieferung waren. Ein weiteres Beispiel ist die Firma mit ihren sieben Scrum-Teams, bei denen die Tester immer in Angstschweiß ausbrachen, wenn sich etwas am Billing- Backend änderte. Dort haben wir in nur zwei Stunden mit ein wenig Vorbereitung die Wissensverteilung unter den Testern durch gezieltes Testen in Paaren anstoßen können. Natürlich war exploratives Testen dafür das Mittel der Wahl. Exploratives Testen ist weit mehr als unstrukturiertes, erfahrungsbasiertes, freies Testen. Die Teilnehmer in meinen Kursen sind immer wieder von den sehr guten Ergebnissen überrascht, nachdem wir sessionbasiertes Testmanagement mit Test-Chartern und Debriefings erklärt und ausprobiert haben. Über all die Jahre habe ich immer verzweifelt nach einer Referenz für Teilnehmer an meinen Kursen zu explorativem Testen gesucht. Als ich Mitte 2012 davon erfuhr, dass Elisabeth Hendrickson an einem Buch zu explorativem Testen schrieb, wusste ich, dass ich es so früh wie möglich lesen muss. Umso mehr freut es mich jetzt, dass es nun eine deutsche Übersetzung gibt. Längst verwende ich die Vorlage für gute Test-Charter. Auch die Diskussionen zu mehr oder weniger offensichtlichen Variablen sind mittlerweile ein fester Bestandteil meiner Arbeit. Und auch, als ich die Übersetzung durchgelesen habe, sind mir immer wieder neue Feinheiten aufgefallen, die ich so noch nicht bedacht hatte. Ein gutes Buch, habe ich einmal gelernt, kann man mehrmals lesen, und man wird immer wieder einen neuen Gedanken finden, den man so bisher noch nicht hatte. Explore IT! ist genau so ein Buch, das Sie mehrmals lesen sollten, und auf Ihren Forschungsreisen werden Sie immer wieder neue Nuancen entdecken, die Sie nachdenklich machen werden. Von meinem Vater habe ich mal gelernt, dass das Lernen nach der Berufsausbildung gerade erst anfängt. So verhält es sich auch mit diesem Buch. Wenn Sie es durchgelesen haben, sind Sie erst am Anfang Ihrer Forschungsreisen. Dieses Buch ist der erste Schritt. Viel Erfolg bei diesem ersten Schritt! Markus Gärtner Lage (Lippe) im Februar 2014

9 ix Vorwort Um irgendetwas wirklich zu verstehen, müssen Sie es erforschen 1. Das gilt zum Beispiel für Städte. Wenn ich reise, dann plane ich immer ein wenig Zeit ein, um in den kleinen Gassen umherzuschlendern und versteckte Kostbarkeiten zu finden. Ich meide Touristenbereiche, um die Restaurants zu finden, in die nur die Einheimischen gehen, und die Geschäfte, die alltägliche Dinge führen. Auf diesen verschlungenen Pfaden lerne ich die örtliche Kultur kennen und mache mich mit dem wahren Charakter des Ortes vertraut. Das gilt auch für Software. Wenn Sie mehr über die wahre Leistungsfähigkeit und Pfade Ihrer Software lernen möchten, müssen Sie sich abseits der ausgetretenen Wege bewegen. Es gibt aber einen Unterschied zwischen ziellosem Umherschlendern und wahrem Erforschen, wie Jessica Hagy so gewandt in ihrem Webcomic»Indexed«mit dem Titel»Field Notes«(dt.: Feldnotizen, Aufzeichnungen) festhielt 2. erforschen Erkenntnis verirren Zeit beim Umherschlendern Jessicas Comic kommuniziert eine wichtige Warnung: Wenn Sie ohne Richtung oder Zweck umherlaufen, werden Sie viel Zeit mit Schlendern für herzlich wenig Erkenntnisse verbringen: Sie werden sich verirren. 1.»Forschen«(engl. to explore) klingt im Deutschen in Bezug auf Software zunächst etwas fremd. Da exploratives Testen von Software sich aber von anderen Testarten unterscheidet, bei denen gezielt die Software geprüft und untersucht wird, kann man hier durchaus davon sprechen, in der Software zu forschen bzw. die Software zu erforschen. 2. Comic von Jessica Hagy, mit freundlicher Genehmigung (

10 x Vorwort Dieses Buch handelt davon, wie man erfolgreich forscht. Auf diesen Seiten werden sie die grundlegenden Fähigkeiten und Techniken eines guten Forschers entdecken. Für wen ist dieses Buch? Da dieses Buch vom Softwaretesten handelt, könnten Sie denken, dass es für Tester geschrieben wurde. Ist es auch, aber nicht nur. Ich habe dieses Buch für jeden geschrieben, der daran interessiert ist, verlässliche und robuste Software zu schreiben. Das schließt Programmierer, Business-Analysten, Produktmanager und sogar solche Leute mit ein, die Software normalerweise erst dann zu Gesicht bekommen, wenn sie fast fertig ist: den Support. Wenn Sie Tester mit fundiertem Wissen über Testdesigntechniken wie Zustandsanalysen sind, werden Sie lernen, wie Sie diese Fähigkeiten anwenden können, um Tests während des Erkundens der Software»on-the-fly«zu entwerfen. Wenn Sie Programmierer mit einem tiefen Verständnis für die grundlegende Technologie sind, werden Sie die Software aus verschiedenen Blickwinkeln betrachten und lernen, sie aus unterschiedlichen Perspektiven zu untersuchen. Wenn Sie Business-Analyst oder Produktmanager sind, werden Sie lernen, wie Sie Ihr Zusammenspiel mit der Software variieren, um sicherzustellen, dass die Software auch unter unterschiedlichsten Bedingungen das tut, was Sie beabsichtigt haben. Wenn Sie zum Support gehören, dann werden Sie erkennen, wie Sie Ihr Verständnis der Software vertiefen, für die Sie Hilfe anbieten. Sie werden auch ein paar Tricks kennenlernen, wie man schwer reproduzierbare Kundenprobleme nachstellen kann. Kurzum, wenn Sie im weiteren Sinne zur Softwareentwicklung gehören, spezifizieren, programmieren, verifizieren oder Support anbieten, ist dieses Buch für Sie. Es macht auch keinen Unterschied, an welcher Art von Software Sie arbeiten. Die Techniken in diesem Buch lassen sich auf einem weiten Gebiet technischer Umgebungen von Webapplikationen, Desktop-Anwendungen, mobilen Applikationen über Embedded-Echtzeitsoftware bis hin zu APIs und Webservices anwenden. Wie dieses Buch aufgebaut ist Dieses Buch besteht aus drei Teilen: Teil 1, Grundlagen schaffen, führt grundlegende Bausteine für Fähigkeiten im Untersuchen ein. In diesem Abschnitt werden Sie lernen, Testcharter zu erstellen, um Ihre Untersuchungen zu leiten, wie Sie beobachten können, was wirklich passiert (Hinweis: Das ist schwieriger, als es klingt), wie Sie interessante

11 Vorwort xi Variationen erkennen und wie Sie feststellen, welches Verhalten zu erwarten ist, wenn Software auf eine Art und Weise benutzt wird, über die vorher noch niemand nachgedacht hat. Teil 2, Weitere Möglichkeiten ins Spiel bringen, baut auf diesen Grundlagen auf. Sie werden lernen, wie Sie Software untersuchen, indem Sie Interaktionen, Sequenzen, Daten, Zeitabläufe und Konfigurationen ändern. Auf dem Weg werden Sie erfahren, wozu Analysetechniken wie Zustandsmodelle, Datenmodelle und Kontextdiagramme beim Untersuchen nützlich sein können. Teil 3, Zusammenhänge herstellen, überträgt diese Techniken in das Umfeld eines Softwareprojekts. Sie werden lernen, wie Sie die Ideen aus Teil 1 und 2 in verschiedenen Situationen nutzen können, beispielsweise um bereits bestehende (Legacy-)Applikationen oder Software zu erforschen, die kein User Interface besitzt. Sie werden erfahren, wie Sie Ihre Funde mitteilen können und wie Sie die Untersuchung schon ganz am Anfang des Entwicklungszyklus einsetzen können. Obwohl Sie die Kapitel in jeder beliebigen Reihenfolge lesen können, ziehen Sie den größten Erkenntnisgewinn aus jedem Teil, wenn Sie die Konzepte in den jeweils vorangehenden Teilen verinnerlicht haben. Praxis ist unerlässlich für den Aufbau Ihrer Fähigkeiten im explorativen Testen. Um Ihnen dabei zu helfen, endet jedes Kapitel mit einem Praxisabschnitt. Damit können Sie das Wissen um die Konzepte festigen und Ideen generieren, wie Sie die Konzepte des Kapitels direkt anwenden können. Im gesamten Buch werden Sie spezielle Techniken oder Heuristiken finden. Jede Heuristik hat einen Namen, wie»einige, keine, alle«oder»anfang, Mitte, Ende«. Namen von Heuristiken werden in Anführungszeichen geschrieben und Sie finden die komplette Liste in Anhang 2, Testheuristiken-Spickzettel. Onlinequellen Wie alle Titel von Pragmatic Bookshelf hat dieses Buch eine Webseite. Wenn Sie besuchen, können Sie an Diskussionen mit anderen Lesern und mir teilnehmen. Außerdem können Sie Fehler melden (wenn Sie welche finden, hoffe ich sehr, dass Sie sich die Zeit nehmen und mir davon berichten). Viel Spaß beim Forschen! Elisabeth Hendrickson elisabeth@testobsessed.com Februar 2013

12

13 xiii Danksagungen Wenn Sie sich einen Autor bei der Arbeit vorstellen, denken Sie vielleicht an eine einzelne Person, die sich über eine Tastatur beugt. Die Wahrheit sieht ein wenig anders aus: Es braucht in Wirklichkeit eine ganze Menge Leute, um ein Buch zu erstellen. Zuerst geht mein tief empfundener Dank an meine Lektorin Jackie Carter. Jackie hat mich durch den ganzen Prozess geleitet. Es hat Zeiten gegeben, in denen ich ohne sie hoffnungslos verloren gewesen wäre. Und noch wichtiger ist, dass Jackie es versteht, die richtigen Fragen zu stellen, um Details hervorzulocken, die nur in meinem Kopf sind, und mich daran zu erinnern, dass ich diese Details aufschreiben muss. Dadurch ist das Buch wesentlich umfassender, abgerundeter und lesbarer geworden. Wenn Sie das Buch als ein zusammenhängendes Werk ansehen, dann danken Sie Jackie (wenn nicht, dann schreiben Sie es mir zu). Ich bin auch dem Pragmatic Bookshelf und den Verlegern Andy Hunt und Dave Thomas dankbar dafür, dass sie mich als neue Autorin genommen haben und dass sie dieses Buch verlegt haben. Außerdem bin ich dankbar, dass sie umfangreiche Hilfsmittel bereitgestellt haben, die wirklich toll zu nutzen waren. Danke auch an Molly McBeath für ihre Detailgenauigkeit beim Copyediting. Ich bin äußerst dankbar für die vielen Rezensenten und Leute, die auf der Webseite Fehler zusammengetragen haben. Ich schätze die Zeit und Aufmerksamkeit sehr, die sie alle dem Manuskript gewidmet haben. Dieses Buch wäre ein blasser Schatten dessen geworden, was es heute ist, wenn sie nicht ihre Erkenntnisse mitgeteilt hätten. Danke also an Anna Baik, Matthew Barcomb, David Christiansen, Simon Crutchley, Ian Dees, George Dinwiddie, Svein Håvard Djupvik, Yves Hanoulle, Paddy Healy, Harry Heckel, Glen Ivey, Amy Lightholder, Rickard Lindberg, Erik Petersen, Dave Rooney, Craig Smith, Pradeep Soundararajan, John Stevenson, Joe Strazzere, Bill Wake, Jo Webb und Adam Yuret. Vielen Dank an Erik G. H. Meade für die Einführung in die Galactic Modeling Language (GML). GML hat viele Diagramme in diesem Buch sehr vereinfacht.

14 xiv Danksagungen Es gibt einige Leute, die mein Denken tief geprägt haben. Dale Emery hat mir geholfen, die Aussagekraft von Konzepten wie Variablen zu verstehen, die ich vorher für selbstverständlich erachtet habe. James Lindsay hat mich angetrieben, hinter die traditionellen Testdesignansätze zu sehen und einen noch stärker untersuchenden Ansatz zu wählen. James Bach hat mich auf andere Weise herausgefordert und ließ mich im Ergebnis schärfer denken. Jon Bach hat mich in einem anderen Stil hinterfragt und hat mein Denken sogar noch mehr gefördert. Cem Kaner hat mir unglaublich viel beigebracht. Darüber hinaus hat Cem den Los Altos Workshop on Software Testing (LAWST) gegründet, ein Diskussionsforum von Gleichgesinnten zum Untersuchen von Erfahrungen und Ideen. Ich bin dankbar, dass ich die Möglichkeit hatte, in einer Zeit bei LAWST teilzunehmen, in der ich dringend eine»community of Practice«benötigte. Alle LAWST-Teilnehmer prägten irgendwie mein Denken. Und schlussendlich war Jerry Weinberg mein Mentor und Freund, der mir eine ganze Menge über das Testen und Geschichtenerzählen beigebracht hat. Ein Buch zu schreiben ist ein zeitaufwendiges Unterfangen und ich bin meinem Mann Kirk Hendrickson unendlich dankbar für seine Liebe und Unterstützung und meinen Töchtern Emily und Anna für ihre Geduld mit mir. Schließlich danke ich der breiten Gemeinschaft der Fachleute, die ihre Erfahrungen als Forscher teilen, indem sie reden und schreiben. Ihr seid meine Inspiration.

15 xv Inhaltsverzeichnis Teil 1 Grundlagen schaffen 1 1 Testen und Erforschen Zwei Seiten des Testens Checking (dt.: Prüfen) Erforschen Getestet = geprüft und erforscht Hauptbestandteile von explorativem Testen Tests erstellen Durchführen Lernen Steuern In zeitbeschränkten Sessions arbeiten Für die Praxis Ihre Forschungen chartern Die Expedition chartern Eine einfache Chartervorlage Gute Charter Charter erstellen Anforderungen Implizite Erwartungen Charter koordinieren Ziele Die Fragen der Stakeholder Bestehende Artefakte Neue Erkenntnisse und Entdeckungen

16 xvi Inhaltsverzeichnis 2.5 Das Spiel mit Horrorschlagzeilen Schritt 1: Voraussetzungen schaffen Schritt 2: Sammeln Sie Schlagzeilen Schritt 3: Suchen Sie sich ein großes Risiko zum Arbeiten aus Schritt 4: Beteiligte Ursachen finden Schritt 5: Ursachen zu Charter weiterentwickeln Charter planen Für die Praxis Details beobachten Aber haben Sie auch den tanzenden Bären gesehen? Tiefer graben Die tiefer gehende Frage stellen Rechnen Sie mit unterschwelligen Hinweisen Ein unerwartetes Geräusch Testbarkeit und Unsichtbares sichtbar machen Konsolen und Logs Für die Praxis Interessante Variationen finden Variablen sind Dinge, die sich verändern Offensichtliche Variablen Weniger offensichtliche Variablen Indirekt zugängliche Variablen Weniger offensichtliche Variablen und große Katastrophen Der Therac-25-Fall Die Ariane Die Marssonde Variablen erkennen Dinge, die Sie zählen können Relative Position Dateien und Speicher Geografische Lage Formate Größe

17 Inhaltsverzeichnis xvii Tiefe Timing, Frequenzen, Dauer Eingaben und Navigation Variablen! Sie sind überall! Für die Praxis Testergebnisse beurteilen Nie und immer Kernfähigkeiten Qualitätsfaktoren Risiken Weitere Quellen Interne Konsistenz Standards Vergleichsprodukte Näherungen Mit einem Wertebereich bewerten Eigenschaften untersuchen Das Ergebnis umkehren Voraussetzungen festlegen Für die Praxis Teil 2 Weitere Möglichkeiten ins Spiel bringen 61 6 Handlungsabläufe und Interaktionen abwandeln Substantive und Verben Zufällige Navigation Personas Für die Praxis Entitäten und ihre Beziehungen erforschen Entitäten, Merkmale und Abhängigkeiten erkennen Nicht offensichtliche Entitäten finden Beziehungen ausarbeiten

18 xviii Inhaltsverzeichnis 7.2 CRUD: Create, Read, Update, Delete CRUD mit Datenvariationen Alle Wege zu CRUD Abhängigkeiten zwischen CRUD und»null, eins, viele« Den Daten folgen Für die Praxis Zustände und Übergänge entdecken Zustände und Ereignisse erkennen Zustände sind Verhaltensformen Ereignisse lösen Zustandsübergänge aus Ein Zustandsmodell erstellen Beschränken Sie Ihren Fokus Erkennen Sie verschiedene Perspektiven Ändern Sie die Abstraktionsebene Mit Zustandsmodellen forschen Alle Wege Unterbrechen Zurück zu den Variablen Die Darstellung ändern: Zustandstabellen Für die Praxis Das Ökosystem untersuchen Das Ökosystem grafisch darstellen Schritt 1: Die Schnittstellen bezeichnen Schritt 2: Externe Abhängigkeiten aufzeichnen Schritt 3: Die Interna ausfüllen Vermeiden Sie die Analyse-Paralyse Vertrauensgrenzen Was wenn...? Netzwerkverbindungen Dateien Den Daten folgen Für die Praxis

19 Inhaltsverzeichnis xix Teil 3 Zusammenhänge herstellen Ohne Benutzeroberfläche forschen Eine API untersuchen Eine Programmiersprache erforschen Einen Webservice untersuchen Fehler beschreiben Für die Praxis Ein existierendes System erforschen Mit einer Aufklärungssession beginnen Beobachtungen gemeinsam machen Stakeholder befragen, um Problemstellungen zu sammeln Techniken auswählen Ihre Ergebnisse festhalten Was ist mit den gefürchteten nicht reproduzierbaren Fehlern? Sammeln Sie Hinweise Listen Sie Variablen auf, die dazu beitragen können Nutzen Sie Zustandsdiagramme, um Zeitzusammenhänge zu verstehen Arbeiten Sie zusammen Für die Praxis Anforderungen untersuchen In das Anforderungsmeeting hineinkommen Wenn man außen vor gelassen wird Missverständnisse aus Einzeldiskussionen Eine Testbesprechung wird zum Anforderungsmeeting Im Anforderungsmeeting Zentrale Werte bestimmen Fragen Sie»Was wenn...?« Erwartungen schärfen Charter in Anforderungsdiskussionen

20 xx Inhaltsverzeichnis 12.4 Aktives Lesen Das Papier befragen In kleinere Stücke aufteilen Ein Modell aufstellen Für die Praxis Forschungen in den gesamten Entwicklungsprozess einbinden Forschungen als Teil Ihrer Teststrategie Beispiele aus dem wahren Leben Prüfen und Forschen in die Entwicklung einbeziehen Früh und oft forschen Aufwände für Forschungen einplanen Forschen in Paaren Systemische Problemquellen finden Forschungen abschätzen Wann haben Sie genug geforscht? Nachbesprechungen mit Stakeholdern Im Daily Standup berichten Nachbesprechung mit Entscheidern Nützliche Lebensweisheiten erfassen Für die Praxis Anhang 155 A.1 Bewerbungsgespräche zu Fähigkeiten in explorativem Testen 157 A.1.1 Exploratives Testen im Paar als Teil eines Bewerbungsgesprächs 158 Vorbereitung Start Den Kandidaten beobachten Nachbereitung Steuern A.1.2 Kandidaten einschätzen