Kollaboratives Testen – Nutzen der Schwarmintelligenz

Qualität ist ein wichtiger Faktor in der Softwareentwicklung. Die Prüfung der Qualität erfolgt meist durch Testexperten. Genauso wichtig ist aber auch der Aspekt, dass in agilen Projekten jeder für alles verantwortlich ist. Da nicht jeder in agilen Projekten ein Testexperte ist, sondern unterschiedliche Expertisen in jedem Team vertreten sind, lohnt es sich, alle Teammitglieder am Test, auf unterschiedlichen Stufen zu beteiligen, um eine gewisse Basis an Qualität zu sichern.
In den meisten agilen Projekten haben sich kollaborative Entwicklungsmethoden, wie Pair Programming schon längst durchgesetzt. Wieso also jetzt nicht den Fokus auf kollaborative Testmethoden setzen? Uns erwartet ein Einblick in die kollaborativen Testmethoden Bug Bash, Pair und Mob Testing. Bevor ich die Methoden einzeln beschreibe, gehe ich darauf ein, was sie gemeinsam haben: das, was sie für Teams leisten.
Im Team testen
Kollaborative Testmethoden zielen auf Teams. Das ist auch ein Grund, wie wir auf die drei Methoden gekommen sind. Wir wollten Methoden finden, die Spaß machen und Menschen jenseits des Produkt- oder Dev-Teams dazu motivieren, mitzutesten. Dadurch verteilt sich das Wissen über den Test auf unterschiedliche Leute und die Testabdeckung wird höher. Wir wollten auch eine geeignete Methode finden, um den Kunden in den Test mit einzubeziehen, um sein Vertrauen in uns zu stärken.
Alle drei Methoden verfolgen einen explorativen Ansatz. Das heißt, dass keine konkreten Testfälle vorbereitet werden. Diese entstehen während der Testsession, inspiriert von den vorherigen Testfällen der Teilnehmer. Das bedeutet nicht, dass man keine Hilfestellung für unerfahrene Tester leisten kann. Oft hat es sich als sinnvoll erwiesen, Testfälle vorzubereiten, um vor allem den unerfahrenen Testern eine Starthilfe mitzugeben. Diese Testfälle können zum Beispiel Use Cases sein.
Alle drei Methoden sind zeitbeschränkt, damit man den Blick für das Wesentliche nicht verliert. Durch die Beschränkung der Zeit sind die Teilnehmer gezwungen, in kurzer Zeit das Beste aus der Situation rauszuholen.
Detailblick: Mob Testing aktiviert Kreativität im Team
Das Prinzip Mob Testing wurde vom Mob Programming abgeleitet, einer von Woody Zuill erfundenen Methode. Er beschreibt die Methode so: "All the brilliant people working on the same thing, at the same time, in the same space, on the same computer." Sein Vorschlag ist es, das Mob Programming regelmäßig durchzuführen, um den bestmöglichen Lernerfolg zu erreichen. Beispielsweise mehrmals die Woche für ein paar Stunden [1].
Das Gute am Mob Testing ist, dass nicht zwingend jeder Teilnehmer über das Testobjekt oder über das Testen grundsätzlich Bescheid wissen muss. Es reicht aus, wenn einige wenige Teilnehmer sich mit diesen Dingen auskennen. Außerdem habe ich festgestellt, dass es Hemmungen abbauen kann, wenn die Mob-Mitglieder wissen, dass sie nicht alleine sind, sondern auch andere Teilnehmer wenig oder kein Wissen über das Testobjekt oder vom Testen haben.
Rollen und Ablauf beim Mob Testing
Beim Mob Testing wechseln die Rollen regelmäßig, um die Konzentration und Motivation der Teilnehmer zu fördern, aber auch um einen Austausch über Kommunikation zu erreichen.
- Der Driver ist verantwortlich für die Eingaben. Er sitzt vor dem Laptop und tippt ein, was ihm der Navigator sagt. Er darf sich nicht an Testideen beteiligen oder sie gar in Frage stellen. Nur, wenn er einen Umsetzungsschritt nicht versteht, kann er nachfragen.
- Der Navigator hingegen hat die Testidee und das "Sagen" über die Umsetzung. Er muss dem Driver Schritt für Schritt erklären, wie er diese umsetzt. Vorteilhaft ist auch, wenn der Navigator den Grund für sein Handeln erklärt. Das schafft ein gleiches Verständnis über den gesamten Teilnehmerkreis. Ist der aktuelle Navigator unerfahren mit dem Testobjekt, darf er die Hilfe des Mobs einfordern. Die Mob-Mitglieder können ihm dann erklären, wie er zu seinem Ziel gelangen kann. Das ist auch das Besondere am Mob Testing. Der Navigator lernt so, weil er quasi ins "kalte Wasser geschubst" wird, bekommt aber Hilfe, weil es immer jemanden im Mob gibt, der sich etwas mit dem Testobjekt auskennt.
- Die Mob-Mitglieder sind alle restlichen Teilnehmer, die nicht Navigator, Driver oder Facilitator sind. Sie überprüfen die Eingaben und Tätigkeiten des Navigators, leisten Hilfestellung, wenn der Navigator nicht weiter weiß und stellen Fragen, wenn sie etwas nicht nachvollziehen können.
- Zusätzlich gibt es den Facilitator. Er ist der Moderator und stellt die Methode vor. Außerdem achtet auf die Regeleinhaltung, z. B., dass die Mob-Mitglieder nicht zu viel diskutieren, weil dadurch der aktuelle Navigator seine Zeit nicht sinnvoll einsetzen kann. Etwas Diskussion ist gut und fördert den Wissensaustausch. Leider hat sich in der Praxis oft gezeigt, dass Diskussionen auch ausarten können und dann keinen Mehrwert mehr bringen. Dies gilt es zu erkennen und zu unterbinden. Er hat die Kontrolle über die Zeit und notiert sich aufgefallene Fehler, die im Nachgang dann vom Projekt bearbeitet werden können [2].
Einer der wichtigsten Bestandteile des Mob Testings ist die Rotation. Sie sorgt dafür, dass die Teilnehmer sich am Geschehen aktiv beteiligen müssen. Die Rollen rotieren alle vier Minuten in eine Richtung. Das ist die vorgegebene Zeit beim Mob Testing. Der Facilitator kann die Zeit aber anpassen, falls er merkt, dass die vier Minuten zu kurz für das sinnvolle Umsetzen einer Testidee sind [2].
In der Praxis ist aufgefallen, dass die Teilnehmer in der ersten Runde oft Schwierigkeiten hatten, sich in die Methode einzufinden. So hat sich beispielsweise der Driver in die Testidee eingemischt oder Diskussionen sind außer Kontrolle geraten, so dass der Navigator nicht zum Umsetzen seiner Idee gekommen ist. Daher lohnt es sich, darauf zu achten, dass jeder jede Rolle mindestens zweimal einnehmen kann. Als sinnvoll hat sich bis jetzt eine Teilnehmeranzahl von sechs bis acht Leuten und eine Dauer von eineinhalb bis zwei Stunden erwiesen.
Meine Tipps!
Besonders gerne verwende ich Mob Testing für die Abnahme oder die Sprint Review Demo. Dabei kann der Fachbereich die neuen Funktionen selbst ausprobieren. Auch finde ich die Methode super, um das ganze Team an Testmethodiken oder die Testautomatisierung heranzuführen. So können die Teammitglieder zusammen mit den Testern lernen, wie der manuelle Test oder die Automatisierung im Projekt funktioniert, damit jeder auch selbst unterstützen kann. Außerdem können dadurch die Tester lernen, wie man den Test-Code verbessern kann.
Pair Testing: Die eigenen Ideen durch die Hände eines anderen umsetzen
Pair Testing kann eine sinnvolle Erweiterung des Testings im Projekt sein. Beim Pair Testing arbeiten zwei Leute zusammen. Diese Methode eignet sich auch super, um sie täglich auszuführen. Dabei ist es keinesfalls ineffizient, zu zweit an einer Aufgabe zu arbeiten. Die Testabdeckung ist dadurch höher und Missverständnisse tauchen weniger häufig auf. Der Effekt über ein positives Gefühl seiner Arbeit gegenüber entsteht und neue Teammitglieder können schneller ins Team integriert werden.
In Studien wurde bewiesen, dass das Pairing die Qualität erhöht und Zeit sparen kann. Ein bekanntes Beispiel ist die Studie von Laurie Ann Williams. Sie ließ mehrere Studenten teilnehmen. Der eine Teil der Studenten sollte in Paaren entwickeln, der andere Teil als einzelne Entwickler. Das Ergebnis war, dass die Paare schneller fertig waren, der Code war kürzer, einfacher zu lesen und es haben deutlich mehr Tests bestanden [3].
Ich verwende es zum Beispiel gerne, um den explorativen Test mit dem fachlichen Review zu verbinden. Dadurch bekomme ich Einblicke in das Verständnis über die Anforderungen und muss mich davor nicht selber fachlich einarbeiten und Missverständnisse aufklären. Zusätzlich muss ich nicht das Bindeglied zwischen Entwickler und Business-Analyst sein und hin und her springen, was enorm viel Zeit spart. Anders herum muss der Business-Analyst sich nicht in die Technik einarbeiten und extra Hilfe beim Setup einfordern, weil der Test ihm da aushelfen kann.
Das Pair Testing stammt, wie das Mob Testing, von einer Programmiertechnik ab. Beim Pair Programming handelt es sich um eine weit verbreitete Methode des Extreme Programmings. Das bedeutet, dass die Aufgaben in kleinen iterativen Tasks abgearbeitet werden. Ein kurzer Einblick in die Prinzipien des Extreme Programmings kann helfen, das Pair Programming und Testing besser zu verstehen.
- Einfachheit (die einfachste Lösung soll gefunden werden),
- Feedback (zeitnahes Feedback fördert den Lernerfolg),
- Kommunikation (durch die Kommunikation soll implizites Wissen zu Explizitem gemacht werden) und
- Mut (für die oben genannten Werte erfordert es Mut, beispielsweise, um zuzugeben, unwissend über die zu erledigende Aufgabe zu sein) [4].
So geht's
Es gibt, wie beim Mob Testing, den Driver und den Navigator. Die Aufgaben der Rollen sehen hierbei aber anders aus als beim Mob Testing:
- Hier hat der Driver die Testidee und tippt sie gleichzeitig ein. Dabei erklärt er dem Navigator, was er umsetzen will und aus welchem Grund. Das hilft dem Navigator, die Idee und mögliche Gedankengänge besser verfolgen zu können.
- Der Navigator hingegen ist im ständigen Review-Modus, stellt Fragen oder gibt Tipps für alternative oder sogar bessere Umsetzungsmöglichkeiten. Durch das Gespräch erfolgt der Wissensaustausch [4].
Auch hier wird eine Rotation der Rollen durchgeführt. Die Rollen wechseln entweder alle paar Minuten oder nach abgeschlossenen Testideen. Das fördert die Konzentration und den Lerneffekt. Dabei müssen beide Partner Rücksicht aufeinander nehmen. Ist einer beispielsweise langsamer in seiner Arbeitsweise oder kennt sich nicht so gut aus wie der andere, muss darauf Rücksicht genommen werden. Das kann zum Beispiel durch Anpassen der Rotationszeit erfolgen oder durch einen Rollenwechsel nach abgeschlossenen Testideen [5].
Tipps
In der Praxis finde ich diese Methode super, um sie täglich anzuwenden, um Wissensinseln abzubauen und das Verständnis über Inhalte des Projekts zu vertiefen. Am besten, wenn auch mal unterschiedliche Rollen im Team miteinander arbeiten. Dadurch bekomme ich einen ganzheitlichen Einblick in das Projekt Und welcher Tester weiß nicht gerne über alles Bescheid? Außerdem ist mir aufgefallen, dass bei hoher Belastung – wie beispielsweise am Sprintende – das Pairing stressmildernd wirken kann, weil man zusammen an Lösungen arbeiten kann. Einfache oder zu kurze Aufgaben können hierbei außerhalb des Parirings erledigt werden. Pairing lohnt sich nur, wenn die Aufgaben groß und anspruchsvoll genug sind, um einen Wissensaustausch erreichen zu können.
Ein zweiter denkbarer Fall für das Pair Testing ist gemeinsames Automatisieren im Testing in einer Paar-Konstellation aus Entwickler und Tester. Da man als Tester oft alleine im Projekt ist, kann es vorkommen, dass der Code nicht so gut ist, wie er sein könnte. Es gibt aber dann keinen anderen Tester im Team, der über den Code schauen kann und Verbesserungen anmerken kann. Deshalb kann man hier von den Entwicklern und ihrem Können, was Programmierung angeht, profitieren. Dadurch ist auch gleich ein Codereview integriert!
Bug Bash: Mit Partystimmung auf Fehlersuche
Die Bug Bash ist eine super Methode, um spontane Testideen und deren Durchführung in der Gruppe zu unterstützen. Das besondere an einer Bug Bash ist der Wettkampf [6]. Die Teilnehmer tun sich in Gruppen zusammen und müssen z. B. so viele Fehler wie möglich finden und das Team mit den meisten Fehlern gewinnt. Zusätzlich können Snacks und Getränke bereitgestellt werden, wodurch das Wohlbefinden der Bug Basher gesteigert wird.
Die lockere "Party"-Stimmung sorgt dafür, dass die Teilnehmer sich ungehemmt über ihre Ideen austauschen und ihre Sichtweise auf das Testobjekt mit einbringen. Außerdem kann jeder bei einer Bug Bash teilnehmen, egal aus welchem Bereich und mit welcher Testerfahrung.
Das Vorgehen kurz und knapp erklärt
Am besten sucht man sich einen geeigneten Raum, in dem Wettkampftische und ein Tisch mit den Snacks aufgestellt werden können.
- Für die Vorbereitung ist die Rolle des Stagers verantwortlich. Sind die Testobjekte und die Bug-Finding-Formulare vorbereitet, kann der Bug Master übernehmen.
- Der Bug Master ist für die Moderation zuständig und erklärt allen Anwesenden das Vorgehen. Aber das ist nicht die einzige Aufgabe des Bug Masters, er muss auch auf die Regeleinhaltung achten, daher ist es wichtig, dass er z. B. Diskussionen unter den Teams verbietet, weil das ansonsten den Wettbewerb verfälschen würde. Er teilt auch die Teilnehmer in Gruppen.
- Sobald diese Gruppen an ihren Tischen sitzen, kann losgetestet werden. Die Teilnehmer, auch Invitees genannt, müssen dann Fehler finden und sie auf den Formularen festhalten. Beispiele für Bugs, denen aufgelauert werden kann, sind der kreativste, der schwerwiegendste oder auch die meisten Fehler.
- Sobald die Invitees fertig mit dem Testen sind – dabei lohnt sich eine zeitliche Beschränkung – bekommt der Note Taker die Formulare und wertet sie aus. Am besten eignet sich als Note Taker eine Person, die sich gut mit dem Testobjekt auskennt, um die Bugs bewerten zu können.
Er bestimmt dann, welches Team gewonnen hat. In dieser Pause können sich alle restlichen Teilnehmer von den Wettkampf-Strapazen mit den Snacks und Getränken stärken! [7]
In meiner Praxiserfahrung haben sich pro Team drei Leute bewährt. Damit ist es kein Pair Testing. Trotzdem ist die Gruppe so klein gehalten, dass dominante Charaktere introvertierte nicht in den Hintergrund stellen können. Auch hat sich eine Dauer von 2 Stunden für eine Bug Bash als sinnvoll erwiesen. Die Invitees haben so 1,5 Stunden Zeit zum Testen, was ein guter Zeitraum ist, um die Konzentration nicht zu sehr zu strapazieren.
Für die Formulare habe ich immer Zettel vorbereitet, auf denen Informationen wie die Reproduzierbarkeit, der Schweregrad und vor allem der Weg zum Bug notiert werden konnten. Es gibt aber auch die Möglichkeit, Tools zu benutzen. Der Vorteil der ausgedruckten Formulare ist aber, dass man die Teilnehmer nicht noch auf ein weiteres Tool vorbereiten muss!
Tipps aus der Praxis:
Die Bug Bash führe ich gerne am Ende eines Projekts oder bei Erreichen eines großen Zieles durch. Das kann dann als Abnahme des Kunden gelten. Außerdem kann nochmal ein letzter großer Test stattfinden, an dem die unterschiedlichsten Leute mit den unterschiedlichsten Sichtweisen mitmachen. Dafür sollte man aber genügend Zeit einplanen, um Fehler, die gefunden wurden und noch unbedingt behoben werden müssen, noch bearbeiten zu können.
Weil diese Methode besonders viel Spaß macht, wird dann das Ende des Projekts als besonders angenehm empfunden und sowohl der Kunde als auch der Dienstleister verlassen das Projekt mit einem guten Gefühl.
Fazit
Sie haben jetzt einen Einblick in die kollaborativen Methoden Mob und Pair Testing, sowie Bug Bash bekommen. Die Methoden haben sich in der Praxis stets als sinnvolle Erweiterung des Projekt-Testings erwiesen. Sie können nicht den kompletten Test ersetzen, aber zum richtigen Zeitpunkt können sie noch einige Fehler aufdecken. Zusätzlich fördern sie den Team-Spirit und verteilen Wissen.
Durch die Effektivität und den gewissen Fun-Faktor sind die Methoden bei allen Teilnehmern – sowohl dem Projekt-Team als auch dem Kunden – stets sehr gut angekommen.
- W. Zuil ; 2014: Getting started with Mob Programming
- M. Pyhäjärvi; 2019: Mob Programming Guidebook
- L.A. Williams; 2000: The Collaborative Software Process
- H. Wolf, S. Roock, & M. Lippert; 2005: eXtreme Programming: Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis. Heidelberg: dpunkt.verlag GmbH.
- R. Pichler & S. Roock; 2011: Agile Entwicklungspraktiken mit Scrum. Heidelberg: dpunkt.verlag GmbH.
- X. Zhou & M. Mäntylä; 2013: Defect Bash - Literature Review
- M. Chang; 2014: Running an Effective Bug Bash
Neuen Kommentar schreiben