Following the post on remote pair testing, now I would like to address the topic of remote mob testing. In many companies, employees work together, but in different locations, even within the project team. If you still want to use the benefits of mob testing, you can use the distributed version.
First of all, you need to understand the concept of mob testing. It is a collaborative and exploratory method that can, for example, be used to share testing know-how among the teams, or to automate testing together with the team, or to use new technologies.
Roles in mob testing
Mob testing has four different roles:
- The driver is responsible for implementing the test ideas. They follow the navigator’s specifications, and they must not interfere with the test idea.
- The navigator, on the other hand, is the person who has the test idea and provides the specifications in this respect. They explain to the driver how and, most importantly, why, the driver is to implement the idea.
- The mob members observe what is happening and help the navigator develop the ideas. They can also ask questions.
- The facilitator is the only role that does not rotate. They manage the schedule, record comments and anomalies, and act as moderator and arbitrator. They are responsible for preventing unnecessary discussions and promoting useful conversations.
The roles of driver, navigator and mob member rotate regularly, e.g. when a test idea has been implemented, or alternatively after several minutes. For time-based rotation, the pertinent literature specifies a standard rotation cycle of four minutes. This cycle can be adjusted as necessary. The goal is not to interrupt the current navigator in the middle of a test idea. For remote mob testing, some sources say that remote implementation works better if the rotation time is set to 10 minutes in order to avoid inopportune interruptions.
The remote concept in mob testing
For the remote approach, a smaller group is advisable. Four to six people is a suitable size to ensure a clear structure where constructive discussions are possible. The duration can be set to 1.5 hours.
For meaningful remote mob testing to be possible, you first need to choose a suitable communication tool. MS Teams or Skype, for example, work well in this context. There are different options for executing the rotation, and consequently, for the implementation by the driver.
Practical examples
Below, I am going to present two approaches that have worked well for me. It is advisable to define a sequence for the rotation during the preparation to ensure a smooth rotation. For this purpose, you can number the participants.
Approach #1: Transfer of mouse control
In this case, the facilitator shares their screen, and the driver requests control of the mouse. The mouse control is passed on when it is the next driver’s turn.
This approach works well when you are working on a test object for which you need the previous driver’s state in order to be able to continue working in an expedient manner. Personally, this is my favorite approach because it is uncomplicated and quick.
Approach #2: Transfer of screen transmission
With this approach, each driver shares their screen when it is their turn. However, this method is suitable only if it is possible to implement further ideas on the test object, irrespective of the previous test, because the last state of the previous driver is no longer available for the next screen transmission. Another option in this approach is giving several people access to the object, e.g. a user for all the participants.
Fazit
Mob testing itself is simple to do, and, like pair testing, it is a very lightweight testing method. Likewise, the two approaches that I have presented in this post (transfer of mouse control vs. screen transmission) are uncomplicated and simple to implement. Both methods have worked well and facilitate distributed collaboration.
Furthermore, there are some tools available for frequent use and/or the joint development of automated tests, for example. If you want to explore the test object and perform distributed tests quickly and straightforwardly, the two methods presented above are highly suitable.
This post was written by:
