Explore It! - Wie Softwareentwickler und Tester mit explorativem Testen Risiken reduzieren und Fehler aufdecken

1 Testen und Erforschen

Egal, welche Berufsbezeichnung Sie haben, Sie werden höchstwahrscheinlich regelmäßig bei Ihrer täglichen Arbeit testen. Testen ist ein integraler Bestandteil jedes Schaffensprozesses. Solange, bis Sie die Software testen – also mit der Software oder dem System interagieren, das tatsächliche Verhalten beobachten und mit Ihren Erwartungen vergleichen –, ist alles, was Sie darüber zu wissen glauben, nicht mehr als bloße Spekulation.

Robert Slater erzählt in Portraits in Silicon [Sla89] die Geschichte des Teams, das einen der ersten Computer baute, den ENIAC. Die ersten Computer waren riesig und füllten ganze Räume. Beim Untersuchen des Inneren einer dieser Maschinen sah man Bauteile in Metallgestellen mit großen Kabelbündeln, die sie verbanden. Die Wahl der Kabel wurde also zu einer wichtigen Designentscheidung. Slater erklärt:

»Es gab die latente Gefahr, dass Mäuse die Kabel anfressen würden. Für einen Test wurden einige Mäuse in einen Käfig gesperrt, mussten einige Zeit hungern und wurden dann mit verschiedenen Kabelarten konfrontiert. Als man herausfand, dass die für ENIAC geplanten Kabel von den Mäusen geliebt wurden, entschied man sich für andere Kabel, die den Mäusetest bestanden.«

Beachten Sie, dass die Teammitglieder ein Risiko erkannten und in eine Fragestellung umwandelten, die sie beantworten konnten. Sie haben nicht über die Nahrungsvorlieben von Nagetieren spekuliert, sondern einigen hungrigen Mäusen verschiedene Kabelsorten vorgesetzt. Sie haben die Ergebnisse ihres Experiments genutzt, um ihre Handlungen zu leiten. Das ist der Kern des Testens: Ein Experiment zu gestalten, mit dem man empirische Beweise sammelt, um eine Frage zu einem Risiko zu beantworten.

Verschiedene Testarten beantworten verschiedene Fragestellungen. Wenn Sie wissen wollen, wie gut ein System unter einer bestimmten Gesamtlast läuft, werden Sie einen Performance-Test durchführen. Wenn Sie wissen wollen, ob ein kleines Stück Code sich so verhält, wie es der Programmierer vorgesehen hatte, werden Sie dieses Stück in einer Reihe Unit Tests isolieren. Wenn Sie wissen wollen, ob sich die Anwender ohne Hilfe in der Software zurechtfinden, dann werden Sie einen Usability-Test ansetzen.

Dieses Kapitel erklärt, wie sich exploratives Testen von anderen Testtechniken unterscheidet und wie es in die allgemeine Teststrategie passt.

1.1 Zwei Seiten des Testens

Es ist zwanzig Jahre her, aber ich erinnere mich an das Gespräch, als wenn es gestern gewesen wäre. Marchell, eine meiner Kolleginnen, zeigte auf einen zentimeterdicken Stapel Papier auf ihrem Schreibtisch: Testfälle, die gerade mal einen kleinen Teil des Softwarepakets abdeckten, das wir gerade testeten.

»Es ist so frustrierend«, stöhnte sie. »Egal, wie viele Tests wir schreiben oder wie viele Fälle wir durchführen, wir finden die schlimmsten Fehler immer erst dann, wenn wir vom Skript abweichen.«

Zu der Zeit kannte ich den Begriff exploratives Testen noch nicht, obwohl ihn Cem Kaner bereits 1988 in seinem Buch Testing Computer Software [Kan88] geprägt hatte. Ich wusste nur, dass Marchell Recht hatte. Egal, wie viele Testfälle wir zu unserer Sammlung hinzufügten, wir fanden immer Überraschungen, wenn wir vom Skript abwichen.

In den zwei Jahrzehnten seit dieser Unterhaltung habe ich dieses Muster immer wieder gesehen: Egal, wie viele geplante Testfälle ein Team durchführt, es gibt scheinbar immer noch Überraschungen zu finden.

Wenn eine Firma die Software auf dem freien Markt veröffentlicht, können die Überraschungen sogar noch schlimmer sein.

Nutzer tun die absurdesten Dinge. Produktivdaten haben die gemeine Tendenz, sich von erdachten Beispielen zu unterscheiden. Echte Konfigurationen sind selten so gepflegt und kontrollierbar wie Testsysteme.

Die echte Welt ist ein chaotischer Ort.

Es ist frustrierend, aber nicht abzustreiten: Sie können nicht alle Tests im Voraus planen, um jeden Fall abzudecken. Es gibt zu viele Variationen der Daten, Konfigurationen, Interaktionen, Abfolgen und Zeitabläufe. Wenn Sie versuchen, eine vollständige Testsammlung für jede Eventualität zu erstellen, werden Sie all Ihre Zeit darauf verwenden, Tests zu schreiben, und haben keine Zeit mehr, sie auszuführen.

Was Sie brauchen, ist nicht die perfekte vollständige Testsammlung. Stattdessen benötigen Sie eine Teststrategie, die zwei grundlegende Fragen beantwortet:

1. Verhält sich die Software wie geplant unter den Bedingungen, die sie abdecken sollte?

2. Gibt es weitere Risiken?

1.1.1 Checking (dt.: Prüfen)

Sie können die erste Frage mit Tests beantworten, die Sie im Voraus erstellen, um zu überprüfen, ob sich die Implementierung mit den unterstützten Konfigurationen und unter bestimmten Bedingungen wie vorgesehen verhält.

Sie können sich diese Prüfungen wie ein Netz aus Stolperdrähten vorstellen, das immer dann ausgelöst wird, wenn sich das Verhalten der Software nicht mit den Erwartungen an sie deckt, wie in Abbildung 1–1 zu sehen. Je besser die Abdeckung durch die Prüfungen ist, desto feiner ist das Netz gewebt.

Abb. 1–1 Tests kann man sich als Netz vorstellen.

Auch wenn Sie ein feines Netz gewebt haben, werden Sie immer noch die zweite Frage beantworten müssen. Und das ist der Zeitpunkt, an dem das Forschen ins Spiel kommt.

1.1.2 Erforschen

Mit explorativem Testen können Sie auch die Bereiche erkunden, die das Netz nicht abdeckt. Sie interagieren mit der Implementation, erstellen kleine Experimente und führen diese in kurzer Abfolge durch, während Sie die Ergebnisse eines Experiments nutzen, um das nächste zu gestalten.

Während Sie potenzielle Risiken erkennen, gehen Sie tiefer ins Detail. Sie nutzen Ihre Beobachtungs- und Analysefähigkeiten, um Ihre Untersuchungen unterwegs anzupassen. Ihre Experimente liefern Ihnen empirische Hinweise über die Möglichkeiten und Grenzen Ihrer Software. Entlang des Weges entdecken Sie neue Fragen, die einer Antwort harren, und planen neue Testarten ein.

Bei einer Erkundung kann man sich durch die unendlich vielen Möglichkeiten der Varianten bewegen und in Richtung der Risiken steuern. Ihre vorher geplanten Tests können das so nicht. Um weitere Überraschungen zu entdecken, wird Ihnen nicht Wiederholbarkeit helfen, sondern Variation.

Die zwei Fragen stellen also die beiden Facetten des Testens dar: prüfen, dass die Software Erwartungen erfüllt, und Risiken erforschen. Weder Prüfen noch Erforschen reichen ohne das jeweils andere aus.

1.1.3 Getestet = geprüft und erforscht

Sie sind mit dem Testen nicht fertig, bis Sie geprüft haben, dass die Software die Erwartungen erfüllt, und erforscht haben, ob es weitere Risiken gibt. Eine umfassende Teststrategie vereinigt beide Ansätze.

Beim Lesen dieses Buches sollten Sie im Hinterkopf behalten, dass es nur die explorative Seite der Gleichung behandelt. Dieses Buch ist ein Leitfaden für Techniken, um Überraschungen zu entdecken, und keine vollständige Behandlung aller Aspekte des Softwaretestens.

1.2 Hauptbestandteile von explorativem Testen

Eine der am häufigsten zitierten Definitionen des explorativen Testens stammt aus der von James Bach 2003 herausgebrachten Veröffentlichung Exploratory Testing Explained [Bac03]. James schrieb: »Exploratives Testen ist Lernen, Testfallerstellung und Testausführung gleichzeitig.«

Dieser Teststil benötigt jederzeit Ihre volle Aufmerksamkeit. Das ist in Cem Kaners Definition des Begriffs offensichtlich:

»Exploratives Softwaretesten ist ein Stil des Softwaretestens, der die persönliche Freiheit und Verantwortlichkeit des einzelnen Testers hervorhebt, um kontinuierlich den Wert der eigenen Arbeit zu steigern, indem testbezogenes Lernen, Testdesign, Testausführung und Interpretation des Testergebnisses als sich gegenseitig unterstützende Tätigkeiten aufgefasst werden, die während des ganzen Projektes parallel laufen.«1

Ich nutze gern eine Abwandlung von James’ Definition, um die Praktik zu erklären, indem ich eine Sache ergänze. Die Definition von explorativem Testen, die ich verwende, lautet:

Gleichzeitiges Erstellen und Durchführen von Tests, um über das System zu lernen, indem Erkenntnisse aus dem letzten Experiment genutzt werden, um das nächste anzuregen.

Jeder Teil dieser Definition ist wichtig: Tests erstellen, Tests durchführen, lernen und steuern. Lassen Sie uns einen Blick auf jeden dieser Aspekte im Detail werfen.

1.2.1 Tests erstellen

Bei der Testerstellung werden Sie Interessantes erkennen, das Sie variieren können, und auch Wege finden, es zu variieren. Es gibt bereits ein reiches Literaturangebot zu diesem Thema, u.a. die Klassiker wie Glenford Myers The Art of Software Testing [Mye79] und Boris Beizers Software Testing Techniques [Bei90] sowie Lee Copelands neueren und umfassenden Überblick A Practitioner’s Guide to Software Test Design [Cop04]....