Mob Testing – Manuelles Testen kann auch Spaß machen

12.01.2018
Von: Thomas Garus

In den meisten Fällen wird manuelles testen als eine aufwendige und unangenehme Aufgabe angesehen. Meistens ist keine Struktur zu erkennen und es mangelt an Feedback und Austausch zwischen den Teammitgliedern, jedoch können beide Probleme mit Mob Testing bekämpft werden. Mit dieser Vorgehensweise testet man nicht nur strukturierter und ermöglicht einen besseren Austausch, diese Alternative macht auch noch Spaß. 

Einer der ersten Schritte zum strukturierten Testen ist das Einführen vom „explorativen Testen“. Zu Beginn bringt man dem Team bei einer gemeinsamen Session die Absicht und die Vorteile dieses Ansatzes anhand diverser Test Chartas und Testing Tours näher. Am Ende hat jeder einen Stapel neuer Arbeitspakete, die abgearbeitet werden müssen, um die Qualität der Applikation zu steigern. Aus dieser ersten Session nehmen die Teammitglieder nicht nur jede Menge hilfreiche Informationen mit, sondern integrieren den Ansatz des gemeinsamen explorativen Testens ebenfalls als wichtigen Baustein im Sprint.

Wenn die Testing Sessions zum zentralen Bestandteil der Sprintroutine werden und somit regelmäßig stattfinden, bleibt man bezüglich der Qualität der Applikation auf dem Laufenden und kann gleichzeitig gemeinsam Probleme finden. Nach ein paar Sprints des gemeinsamen Lernens und Testens kann man den nächsten Schritt gehen, um den Erfahrungsaustausch stärker zu fokussieren und weitere Testideen zu sammeln. Nach ein paar Diskussionsrunden setzt man sich gemeinsam Ziele und strukturiert den Ablauf so um, dass diese erreicht werden können. Diese Ziele könnten zum Beispiel so aussehen:

Wissensmanagement im Team

Absichern des „Done“-Status eines Tickets

Mehraugenprinzip beim Testen

Zeiteffizienteres Testen

Mit diesen Anforderungen im Hinterkopf bereitet man dann die erste „Mob-Testing-Session“ vor. Um zu erproben, ob der Ansatz funktioniert oder ob er gegebenenfalls noch angepasst werden muss, kann man eine Testing Tour wählen, mit der man möglichst den Datenfluss der gesamten Anwendung nachvollziehen kann. Setzt man nun noch die Teilnehmer aus Testern, Front- und Backendentwicklern sowie Repräsentanten vom PO Team und dem Kunden zusammen, so deckt man ein breites Spektrum an Erfahrungen und Funktionen ab. Ein Setup könnte so aussehen:

Ein Raum, ein Bildschirm, eine Instanz der Anwendung

Ein Driver (Diese Rolle kann auch regelmäßig gewechselt werden)

Ein Navigator (Gruppe bestehend aus fünf Personen)

Ein Moderator

Dadurch, dass man voneinander lernt und sich auf Bereiche konzentriert, die sonst größtenteils vernachlässigt werden, macht das Testen mehr Spaß. Außerdem kann man an dem Fachwissen der Kollegen teilhaben und das eigene Wissen weitergeben. Die Rolle des Drivers ist dabei gleichzeitig die schwerste und die einfachste Rolle in dem Setup. Er soll nicht eigenständig denken, sondern nur die Schritte ausführen, die er von den Navigatoren genannt bekommt und „dagegen ankämpfen“ die Anwendung so zu bedienen, wie er es gewohnt ist. Nach einer Weile gewöhnt man sich aber an diese Art des Testens.

Ein möglicher Grund für die Einführung von Mob Testing ist, dass man sich unsicher ist, ob der „Done“-Status eines Tickets gerechtfertigt ist, obwohl es im Rahmen einer explorativen Testsession abgenommen wurde. Teilweise ist es so, dass die Aufgabe zwar laut Status abgeschlossen ist, allerdings bleibt oftmals das Gefühl, dass nicht alle zu dem Ticket gehörenden Bereiche getestet wurden. Mit Hilfe des Mob-Testing-Ansatzes kann das ganze Team entscheiden, wann genug getestet wurde und ob der „Done“-Status verliehen wird. Wenn während einer Testing Session Zweifel aufkommen, wird abgestimmt und im Zweifelsfall lieber ein bisschen mehr Zeit in das Ticket investiert. Folglich können einzelne Teammitglieder nun sicherer sein, dass der Status auch wirklich passt.

Jede Mob-Testing-Session endet mit einer Retrospektive, die das Vorgehen in den folgenden Sessions verbessern soll. Ein Resultat der Retrospektive könnte sein, dass dieses Vorgehen so hilfreich ist, dass es das „normale“ explorative Testen in der Sprintroutine ablöst. Da jede Projektrolle im Testen eingebunden ist, kann man gut Expertenwissen teilen und gemeinsam Testideen entwickeln, die gleich angewendet werden können. Wenn dieser Ansatz über einen längeren Zeitraum genutzt wird, kann man die Vorgehensweise natürlich kontinuierlich den Bedürfnissen anzupassen.

Zusammenfassend kann man folgende Erkenntnisse feststellen: Es ergibt auf jeden Fall Sinn aus der Testroutine auszubrechen und zu experimentieren. Auch, wenn das Experiment scheitern sollte und ein Ansatz sich als nicht so hilfreich herausstellt wie erhofft, hat man zumindest die Applikation getestet und neue Erkenntnisse erhalten. Außerdem ist es ein guter Weg einem Team zu zeigen, dass es sich lohnt zu experimentieren und so im besten Fall seinen Horizont zu erweitern. 


Kategorie: Quality

INDIVIDUELLE SOFTWARE

KONTAKT | IMPRESSUM | DATENSCHUTZ | AGB