Exploratory Testing – Scrum Teams testen wie Touristen
Beim Exploratory Testing (Exploratives Testen) handelt es sich nach James Bach, in → Exploratory Testing Explained, auf Satisfies,Inc um eine informelle Testtechnik, bei der der Tester das Testdesign aktiv kontrolliert, während er diese Tests ausführt.
Bei dieser Methode benutzt der Tester die beim Testen gewonnene Information dazu, um neue und bessere Tests zu entwerfen. Erfahrungsgemäß kommt diese Testmethode im Scrum Team besonders gut an, da sie darüber hinausgeht, die üblichen vorgegebenen Testpläne und Done-Kriterien abzuarbeiten.
Letztendlich ist der Produktowner ja auch für die Qualität verantwortlich. Daher will ich heute kurz auf diese Technik eingehen, und darüberhinaus einige der wichtigsten Testtouren erläutern, die man hierbei anwenden kann, um allseits von denselben Inhalten zu sprechen. Wenn ich heute nicht alle Touren schaffe, können Sie sich schon auf eine Fortsetzung freuen.
Exploratives Testen
Verwendung
Das explorative Testen wird verwendet, um eine Software möglichst umfassend zu überprüfen, und zu testen, ohne, daß man definierte Testfälle vorgibt. Vielmehr läßt man den Testern freie Hand, und verläßt sich auf deren Wissen. Man kann jedoch in einer Exploratory Test Session nicht die gesamte Software testen. Um trotzdem gerichtet vorzugehen, und am Ende das gesamte funktionelle Spektrum der Software abgedeckt zu haben, verfolgt jede Exploratory Test Session eine definierte Testtour, die zu den anderen Touren passt, und sie hat einen definierten Inhalt. Beispiele sind:
- 3 Stunden lang das UI (User Interface)-Testen
- 2 Stunden lang versuchen, einen Dump zu erzeugen, etc
Die Tester wählen eine dieser Touren, und verhalten sich dann wie Touristen: Sie arbeiten Ihre Tour Schritt für Schritt ab, und navigieren anhand der Tourziele.
Definition
Eine bestimmte Testtour, die FedEx Tour, hatte ich in einem früheren Artikel schon einmal erwähnt. In der Praxis gibt es jedoch eine Menge mehr solcher Touren. Bevor ich darauf komme, kurz noch zu der Frage, was eine gute Testtour ausmacht. Eine Testtour wird formal durch folgende Inhalte definiert und beschrieben:
- Sie beschreibt einen Ansatz, um ein Feature zu testen.
- Sie hat einen eigenen Namen, der die Kommunikation erleichtert.
- Ihre Formulierung ist abstrakt genug, um ungeändert auf eine größere Menge von Features angewendet werden zu können.
- Da die Tour tiefergehende Testerfahrungen verkörpert, ist die Wahrscheinlichkeit groß, daß man mit dieser Tour Fehler findet, und wichtige Thesen hiermit überprüfen kann.
Wenn die einzelnen Scrum Teams in einem Unternehmen eine einheitliche Terminologie verwenden, ist es einfach über die verschiedenen Testansätze im Team, und teamübergreifend zu sprechen. Damit ist es wichtig, über eine einheitliche Definition der einzelnen Touren zu verfügen, damit Jeder Jeden versteht.
Test-Touren
James Whittakers hat in seinem Buch Exploratory Software Tours die wesentlichsten Touren beschrieben. Davon will ich einige Touren im diesem Kapitel kurz zusammenfassen.
Back-alley Tour
Die Grundidee dieser Testtour ist es, genau diejenigen Features zu testen, die der Nutzer normalerweise während der täglichen Arbeit nicht nutzen wird. Solche Features können – obwohl sie relativ selten verwendet werden – unter Umständen relativ wichtig sein. Denken Sie zum Beispiel an die Funktionalitäten zum Wiederherstellen eines Systems nach einem Crash. Mit diesem Test konzentriert man sich genau auf diese Features.
Landmark Tour
Mit der Landmark Tour (“Sehenswürdigkeiten”) ist nicht darauf ausgerichtet Ihre Hauptanwendung stupide durchzutesten (dies kann ein automatischer Test viel besser). Vielmehr prüfen Sie hiermit die einzelnen Features in allen möglichen Kombinationen durch, und stellen so sicher, daß die Hauptfeatures Ihrer Anwendung in allen möglichen Kombinationen zusammenarbeiten. Für die Testdurchführung wählen Sie die wichtigsten Features Ihrer Anwendung aus, und führen diese jeweils in unterschiedlichen Reihenfolgen aus.
Money Tour
Mit der Geldtour konzentriert man die Tests genau auf die Features, wegen denen der Kunde die Software kauft. Dabei handelt es sich normalerweise genau um die Features, die intensiv beworben werden. Bei einer Textverarbeitung würden Sie zum Beispiel probieren, ob Sie Texte erfassen können, formatieren, speichern, und ausgeben (als Druckdatei, oder als Druck). Wenn Sie selbst nicht wissen, welche Features wie wichtig sind, laden Sie doch einen Verkäufer ein, Ihnen die Software zu demonstrieren. Oder, laden Sie den Verkäufer ein, mitzutesten.
Intellectual Tour
Die Idee der Gelehrtentour ist es, der Software möglichst kniffelige Aufgaben zu stellen, um sie so herauszufordern. Sie stellen sich also beim Testen u.a. die folgenden Fragen:
- Wie kann ich die Software echt herausfordern, und an die Grenzen bringen?
- Mit welchen Tricks kann ich die Fehlerbehandlung aushebeln?
- Welche Features kann ich bis an ihre Grenze belasten?
Saboteur Tour
In der Saboteur-Tour versuchen Sie, die Software möglichst destruktiv zu testen. Sie versuchen mit Ihrem Test der Applikation sprichwörtlich den “Boden unter den Füßen” wegzuziehen, und beobachten, was passiert. Zum Beispiel können Sie einzelne benötigte Dateien löschen, die Netzwerkverbindung kappen, den verfügbaren Plattenspeicher ganz klein machen, etc.
Fedex Tour
Ziel der bereits erwähnten Fedex Tour ist es, ausgewählten Daten durch die gesamte getestete Software hindurch zu folgen, mit dem Ziel, zu verstehen, was mit diesen Daten passiert. Über die FedEx Tour stellen Sie fest, ob alle Teile der Software vernünftig mit den Daten umgehen.
Prior Version Tour
Mit diesem Test stellen Sie sicher, daß die Tests, die Sie für die Freigabe der Vorgängerversion durchlaufen haben, auch mit der neuen Version funktionieren. Hiermit stellen Sie insbesondere fest, ob, und wenn ja welche Funktionalität ggfs in der neuen Version nicht mehr vorhanden ist.
Guidebook Tour
In der “Handbuch” Tour verwenden Sie die Dokumentation, um sich durch die Software zu hangeln (Onlinedokumentation, aber auch HowTo Guides, oder Trainingsmaterialien). Mit diesem Test stellen Sie sicher, daß die Software so arbeitet wie dokumentiert, und, daß die Dokumentation selbst keine Fehler enthält. Da es in vielen Ländern gesetzliche Anforderungen an die Produktdokumentation gibt, ist dieser Test in seiner Wichtigkeit nicht zu unterschätzen.
Weiterführende Informationen
Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Tags: Agile Development, Buecher, Nutzenversprechen, Rollout | Comments Off
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen mit dem Schwerpunkt globale Standardanwendungen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
