Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
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.
Es gibt unterschiedliche Testmethoden, die sich zudem jeweils auf unterschiedliche Aspekte des Produkts konzentrieren. So gibt es Testmethoden, die sich eher auf die Technologie beziehen, und der Sicherheit des Teams dienen (z.B. automatische Unit Tests). Oder es gibt andere Methoden, die sich eher auf das Produkt beziehen, und den Nutzer im Blick haben (z.B. Usability Tests).
Je nach Anwendungsgebiet nutzt man unterschiedliche Testtechnologien. Viele davon sind repetitiv, und sie können grundsätzlich automatisiert werden. Um zum Beispiel sicherzustellen, daß die freigegebenen Backlog Items kein Unheil in dem bereits existierenden Produkt anrichten, verwendet man Regressionstests, die immer dann loslaufen, wenn die Software geändert wird. Aufgrund der Menge dieser Tests, die notwendig ist, um eine Anwendung zu prüfen, bietet es sich an, solche Tests weitgehend zu automatisieren. Oder, um sicherzustellen, daß die Entwicklungsobjekte keine Programmierstandards verletzen, verwendet man statische Tests, die das Coding genauer analysieren, und feststellen, wenn die Entwickler Sprachkonstruktionen verwenden, die zu Fehler führen können.
Das explorative Testen ist demgegenüber eine Testmethode, die die Fähigkeiten und die Intelligenz der Menschen ausnutzt. Man testet mit dieser Methode die gesamte Anwendung, indem man jeden funktionellen Teil aufruft, Daten eingibt, Abläufe durchführt, etc, um so zum Beispiel höherwertige Qualitätsmängel zu finden, bei denen es auf logisches Denken ankommt (z.B Brüche, fehlerhaftes Systemverhalten, unlogische Abläufe, fehlende Funktionen, etc…).
Das explorative Testen eignet sich deshalb als Gesamtaufgabe für das gesamte Team (inclusive Produktowner), und sollte regelmäßig wiederholt werden. Um das explorative Testen regelmäßig verwenden zu können, sind einige organisatorische Themen zu bedenken. U.a gilt es, eine Lösung für folgende Probleme zu finden:
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 explorative Test Session eine definierte Testtour, die zu den anderen Touren passt, und sie hat einen definierten Inhalt. Beispiele sind:
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.
Eine bestimmte Testtour, die FedEx Tour, werde ich weiter unten genauer eingehen. 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. Diese wird formal durch folgende Inhalte definiert und beschrieben:
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.
James Whittakers hat in seinem Buch Exploratory Software Tours die wesentlichsten Touren beschrieben. Davon will ich einige Touren im diesem Kapitel kurz zusammenfassen.
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.
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.
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.
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:
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.
Ziel der 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.
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.
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.
Eine dieser Methoden, die geradezu die Mitwirkung des Productowners verlangt, ist das explorative Testen, das ich oben im Überblick besprochen habe. Die FedEx Tour ist eine besondere Methode, wie der Productowner und Team diese Tests organisieren können.
Für die Methode der FedEx Tour gibt es mehrere Definitionen, und Vorgehensweise. Google versteht darunter z.B. (siehe → The FedEx Tour aus dem Google Testing Blog):
„Traditionally, the strategy is simple, focus on the end user interaction, and verify the expected outputs from the system under test. Tours (at least for me) change this formula. They force the tester to focus on what the software does, isolating the different moving parts of software in execution, and isolating the different parts of the software at the component (and composition) level.“
Eine verwandte Definition ist, daß man das gesamte Testobjekt in unterschiedliche Teile und Routen einteilt, die man dann über unterschiedliche Wege und mit unterschiedlichen Zielen abfährt. Dort gibt es zum Beispiel eine Tour, die dem FedEx Mitarbeiter ähnelt, der eine Tour durch ein Wohngebiet abfährt, und an verschiedenen Stationen anhält, um Pakete abzugeben. Oder es gibt eine Tour bei dem der Abholer zu einer Adresse fährt, um dort sehr viele Pakte auf ein mal zu liefern, bzw abzuholen.
Die zweite Definition gefällt mir besser, weil sie auf die eigentlichen Probleme adressiert. Daher empfehle ich Ihnen diese Definition.
Um eine solche Teststruktur einzuführen sollten Sie sich/das Team insgesamt sich die Funktionalität geeignet einteilen, und jede Tour entsprechend dokumentieren (Testfallbeschreibung), damit jedes Teammitglied den Test durchführen kann. Ein Beispiel für eine solche Einteilung ist:
Normalerweise ist neben dem Test auch das Reporting über die Testaktivitäten wichtig. So erfordern es zum Beispiel die Produkthaftungsgesetze, daß Sie nachweisen können, wie Sie welches Backlog Item getestet haben. Daher sollten Sie paralell zu den Tests eine passende Reportingstruktur aufbauen, die Sie zudem immer wieder verwenden können. Dort reicht es dann fast schon, neben Tour und Testdatum, das Resultat und die gefundenen Fehler zu dokumentieren.
Um diese Tests richtig abzuarbeiten, sollten Sie dem Scrum Team, dem Sie zuarbeiten, Backlogitems vorbereiten, unter dem das Team einzelne Testtasks, und Touren planen und buchen kann. Wie oben erwähnt sollten Sie als Productowner für sich Touren vorsehen, bei denen Sie das Hauptaugenmerk auf die funktionalen Bereiche legen, und Sie sollten aktiv an den Testaktivitäten teilnehmen.
Bei dieser Organisationsaufgabe hilft eine definierte Methode, an denen man sich entlang hangeln kann. Sollten Sie vorher noch weitere Informationen zu den Testtechnologien und -methoden benötigen, lege ich Ihnen die Informationen nahe, die Sie über das →“International Software Testing Qualifications Board“ (ISTQB) erhalten.
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
