FedEx-Tour
In dem Modell der agilen Softwareentwicklung haben Teams eine andere Rolle, als in einer Softwareentwicklung, die nach dem “Wasserfallprinzip” arbeitet. Während in dem Wasserfallprinzip die Entwicklungsarbeit zwischen verschiedenen Abteilungen aufgeteilt ist, sind agile Teams für den kompletten Lieferumfang ihrer Backlog Items verantwortlich. Ein wichtiger Teil der Aufgaben ist hierbei, daß die Teams die Verantwortung für die Qualität der abgelieferten Backlog Items übernehmen.
Es gibt verschiedene Qualitätssicherungsmethoden, die ein Scrum Team anwenden kann, um die Qualität der Entwicklungen festzustellen. Manche Methoden betreffen eher die Entwickler (z.B. das Erstellen von automatischen Tests, oder die Methode des Test-Driven-Developments), bei anderen Methoden kann und soll auch der Productowner mitwirken.
Eine dieser Methoden, die geradezu die Mitwirkung des Productowners verlangt, ist das explorative Testen. Die FedEx Tour ist eine besondere Methode, wie der Productowner und Team diese Tests organisieren können.
Exploratives Testen
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:
- Wenn mehrere Teammitglieder unabhängig voneinander testen, sollte man sicherstellen, daß jedes Teammitglied unterschiedliche Bereiche testet. Dies dient dazu, die Testabdeckung zu verbessern.
- Eine Anwendung kann sehr groß werden, und ein kompletter Test damit zu einem umfangreichen Vorhaben werden. Man sollte daher sicherstellen, daß man die Tests in kleinere, in sich abgeschlossene Einheiten zerteilt, wobei keines der Elemente vergessen wird (Usability, Funktionalität, etc). Dies dient dazu, daß man sich in die Lage versetzt, ohne großen Aufwand regelmäßig zu testen.
Bei dieser Organisationsaufgabe hilft die Methode der FedEx Tour, um die es im, nächsten Kapitel gehen wird. 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.
FedEx Tour
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.
Organisation
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:
- Tour A: Oberflächen der Hauptanwendung
- Tour B: APIs (Application Programming Interfaces)
- Tour C: Usability der Reports…
- Tour X: Funktionale Abdeckung des Geschäftsprozesses,..
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.
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, Quality, Werkzeuge | 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.
