Within ZEISS Digital Innovation (ZDI) there is an internal training event at regular intervals – the so-called ZDI Campus Event. As employees, we present software development topics by means of lectures, workshops or discussion rounds.
Katharina had already reported on collaborative testing methods at the last ZDI Campus, and also published blog articles about Remote Pair Testing and Remote Mob Testing. Therefore, we wanted to continue the topic at the next ZDI Campus and offer a workshop on the topic of collaborative testing methods. However, due to the Covid-19 pandemic, the next campus had to be held online. Nevertheless, we wanted to offer several participants the opportunity to apply a test method using a practical example, and therefore decided to hold a remote Mob-Testing Workshop.
But there was a challenge: We had never worked with so many people in the mob remotely!
Structure of the workshop
As described in the blog post about Remote Mob Testing, it makes more sense to supervise small groups of four to six people. Distributed work may otherwise lead to more frequent delays due to technical problems (e. g. poor connection, poor sound quality), which could reduce the time required for the current navigator. As a facilitator, you can also keep an overview of smaller groups and the participants can take on the role of navigator or driver more often.
(Zur Erläuterung der verschiedenen Rollen siehe ebenfalls Blogbeitrag Remote Mob Testing)
Our setting looked like this:
- Microsoft Teams as a communication platform
- Easy to understand test object (website)
- 3 Facilitators
- 39 participants from the fields of QA, Development and Business Analysis
- Timeframe: 1.5 hours
Because we wanted to give everyone the opportunity to get to know the Mob-Testing themselves by means of a practical example, we did not set a limit on participants in the run-up to the workshop. In the end, all three facilitators had more than 12 participants.
As a test object, we chose a simple website so that everyone could concentrate on communicating or getting to know the test method and not have to acquire additional knowledge about the application.
Feedback
Already during the course of the workshop, we noticed that waiting times for an active role (Driver or Navigator) could be perceived as unpleasant.
This was also mentioned in the feedback round. Therefore, we recommend that the mob assists with test ideas, because it doesn’t mean that you can sit back and wander with your thoughts as a mob member. This also avoids double testing or having to admit that you were not paying attention.
In some cases, it was difficult for some participants to focus purely on the role of the driver – executing the instructions of the navigator, and holding back on their own test ideas. However, the participants got used to it after some remarks by the facilitator. This aspect of Mob-Testing was considered to be very positive, because everyone in the role of the navigator can speak and contribute their own test ideas.
However, the question arose as to why the roles Navigator and Driver could not be combined. The following can be said: It promotes the learning process when a member articulates step-by-step what he or she intends to do. In this way, more participants are involved in this active role. Communicating the destination makes it easier for the participants to follow the ideas of the navigator. Otherwise, some steps may be carried out too quickly, and with too little explanation. This would lose traceability and make it difficult for the mob to get actively involved.
There was other positive feedback on the division of roles and the whole process. According to the respondents, the test approaches are partly obtained by the path taken by the previous navigator, and therefore viewed the test object from a variety of angles. For this reason, it is always useful to invite participants with different skills, depending on the purpose of the Mob-Testing session. This increases the learning process, and the number of test cases. The simple sample test object also helped to focus on the method and to internalize it.
The collaborative work in Mob-Testing was highlighted very positively. This is how the agile thought is experienced.
Solution approach for a large number of participants
The problem of too many participants could be solved by limiting the size of the group in advance or by introducing a new role: the role of spectator. A separation would then be made between active participants on the one hand and spectators on the other. Participants would follow the procedure described above, and follow the roles distribution (navigator, driver, mob) and the role change. The spectators would only observe and not participate. Comments by them would not be allowed either, because this could disturb the active participants with a large number of spectators.
Conclusion
All in all, the workshop was very well received at the Campus event, and showed that it is very possible to use Mob-Testing remotely, and therefore for distributed work. This means that cooperation can be maintained, even if it is not always possible to meet on site.
This post was written by:
Maria Petzold has been working at ZEISS Digital Innovation since 2010. As a test manager, her focus is on software quality assurance. She was able to gain her test experience especially in medical software projects.
This post was written by:
