Verteiltes Arbeiten – Ein Erfahrungsbericht zur praktischen Anwendung von Remote Mob Testing

Innerhalb von ZEISS Digital Innovation (ZDI) gibt es in regelmäßigen Abständen eine interne Weiterbildungsveranstaltung – den sogenannten ZDI Campus. Dabei präsentieren wir als Mitarbeiterinnen und Mitarbeiter Softwareentwicklungsthemen mittels Vorträgen, Workshops oder Diskussionsrunden. 

Katharina hatte beim vergangenen ZDI Campus schon einmal über kollaborative Testmethoden berichtet und auch Blogartikel bezüglich Remote Pair Testing sowie Remote Mob Testing veröffentlicht. Daher wollten wir das Thema gern auf dem nächsten ZDI Campus weiterführen und einen Workshop aus der Themenwelt kollaborativer Testmethoden anbieten. Aufgrund der Covid-19-Pandemie musste der nächste Campus jedoch online stattfinden. Dennoch wollten wir mehreren Teilnehmerinnen und Teilnehmern die Möglichkeit bieten, eine Testmethode am praktischen Beispiel anzuwenden und haben uns daher für einen remote Mob Testing Workshop entschieden.  

Doch es gab eine Herausforderung: Wir hatten noch nie mit so vielen Personen im Mob remote gearbeitet! 

Aufbau des Workshops 

Wie in dem Blogbeitrag über Remote Mob Testing beschrieben ist es sinnvoller, kleine Gruppen aus vier bis sechs Personen zu betreuen. Durch das verteilte Arbeiten kann es sonst häufiger zu Verzögerungen durch technische Probleme (z. B. schlechte Verbindung, schlechte Tonqualität) kommen, was die Einsatzzeit des jeweils aktuellen Navigators verkürzen könnte. Auch kann man als Facilitator bei kleineren Gruppen besser den Überblick behalten und die Teilnehmenden können die Rolle des Navigators oder Drivers häufiger einnehmen.
(Zur Erläuterung der verschiedenen Rollen siehe ebenfalls Blogbeitrag Remote Mob Testing) 

Unser Setting sah wie folgt aus:

• Microsoft Teams als Kommunikationsplattform  
• Leicht verständliches Testobjekt (Website)
• 3 Facilitators  
• 39 Teilnehmerinnen und Teilnehmer aus den Bereichen QA, Entwicklung und Business Analyse 
• Zeitlicher Rahmen: 1,5 h  

Weil wir allen die Möglichkeit geben wollten, das Mob Testing selbst an einem praktischen Beispiel kennenzulernen, haben wir im Vorfeld des Workshops keine Teilnehmerbegrenzung festgelegt. Schlussendlich hatten alle drei Facilitators über 12 Teilnehmerinnen und Teilnehmer. 

Als Testobjekt haben wir eine einfache Website gewählt, damit sich alle auf das Vermitteln bzw. Kennenlernen der Testmethode konzentrieren konnten und sich nicht noch zusätzlich Wissen über die Anwendung aneignen mussten. 

Feedback 

Schon während der Durchführung des Workshops fiel uns auf, dass die Wartezeiten, bis eine aktive Rolle (Driver oder Navigator) eingenommen wird, als unangenehm empfunden werden könnte.   

Dies wurde auch in der Feedbackrunde angesprochen. Daher empfehlen wir, dass der Mob bei Testideen mit unterstützt. Es bedeutet nämlich nicht, dass man sich als Mob-Mitglied zurücklehnen und mit den Gedanken abschweifen kann. Das vermeidet auch doppeltes Testen oder sich die Blöße geben zu müssen, nicht aufgepasst zu haben.  

Teilweise fiel es einigen Teilnehmenden am Anfang schwer, sich bei der Rolle des Drivers darauf zu konzentrieren, nur die Anweisungen des Navigators auszuführen und eigene Testideen zurückzuhalten. Durch entsprechende Hinweise des Facilitators gewöhnten sich die Teilnehmerinnen und Teilnehmer jedoch nach einiger Zeit daran. Dieser Aspekt des Mob Testings wurde als sehr positiv empfunden, weil alle in der Rolle des Navigators zu Wort kommen und eigene Testideen einbringen können.  

Dennoch kam die Frage auf, warum die Rollen Navigator und Driver nicht zusammengefasst werden können. Dazu lässt sich Folgendes sagen: Es fördert den Lernprozess, wenn ein Mitglied Schritt für Schritt artikuliert, was es vorhat. So bindet man mehr Teilnehmerinnen und Teilnehmer in diese aktive Rolle ein. Durch das Mitteilen des Ziels wird es den Teilnehmenden erleichtert, den Ideen des Navigators zu folgen. Andernfalls kann es passieren, dass einige Schritte zu schnell und mit zu wenig Erklärung durchgeführt werden. Dadurch ginge die Nachvollziehbarkeit verloren und dem Mob würde es erschwert, sich aktiv einzubringen.  

Weiteres positives Feedback gab es zur Rolleneinteilung und dem gesamten Vorgehen. Den Aussagen der Befragten nach erhalte man die Testansätze zum Teil durch den Weg, den der vorherige Navigator eingeschlagen hat und betrachtet daher das Testobjekt aus den unterschiedlichsten Blickwinkeln. Aus diesem Grund ist es immer sinnvoll – je nach Zweck der Mob Testing Session – Teilnehmerinnen und Teilnehmer mit unterschiedlichen Kenntnissen einzuladen. Das erhöht den Lernprozess und die Anzahl der Testfälle. Das einfache Beispiel-Testobjekt habe zudem geholfen, sich auf die Methode zu konzentrieren und sie zu verinnerlichen. 

Sehr positiv hervorgehoben wurde das kollaborative Arbeiten beim Mob Testing. Dadurch wird der agile Gedanke gelebt.  

Lösungsansatz für eine große Teilnehmerzahl 

Das Problem einer zu hohen Teilnehmeranzahl könnte man lösen, indem man im Vorfeld die Gruppengröße begrenzt oder aber eine neue Rolle einführt: die Rolle des Zuschauers. Dabei würde dann eine Trennung zwischen aktiven Teilnehmern und Teilnehmerinnen einerseits sowie Zuschauerinnen und Zuschauern andererseits vollzogen. Die Teilnehmenden würden das oben beschriebene Vorgehen durchführen und sich an die Rollenverteilung (Navigator, Driver, Mob) sowie den Rollenwechsel halten. Die Zuschauerinnen und Zuschauer würden nur beobachten und nicht teilnehmen. Auch Kommentare von ihnen wären nicht erlaubt, weil das bei einer hohen Zuschauerzahl die aktiven Teilnehmenden stören könnte. 

Fazit 

Alles in Allem ist der Workshop auf der Campus-Veranstaltung sehr gut angekommen und hat gezeigt, dass es sehr gut möglich ist, Mob Testing auch remote und somit für das verteilte Arbeiten anzuwenden. Durch diese Möglichkeit kann das Zusammenarbeiten beibehalten werden, auch wenn es nicht immer möglich ist, sich vor Ort zu treffen.  

Dieser Beitrag wurde verfasst von:

Dieser Beitrag wurde verfasst von: