Mob testing is all about a group of testers coming together and collaborating. No, it’s nothing involving big clubs. No, it’s not about mobile applications. It’s working together on a testing task on one computer to get the best out of each one of us. Everyone contributes, and whoever is taking their turn on the keyboard is just an intelligent input device. Decisions come from the group, with everyone speaking up about the testing that is about to happen.
A lot of the testing knowledge is tacit—it’s in our heads, built from our years of experience. With the combined experience of everyone in the group, we get the best possible approaches to the testing task at hand.
From Mob Programming to Mob Testing
A few years ago I was organizing a conference, and we invited Woody Zuill, the discoverer of mob programming, as our keynote speaker. I listened in deep distrust as he introduced the concept of mob programming: “All the brilliant people working on the same thing, at the same time, in the same space, on the same computer.” It sounded wasteful to me, yet I was intrigued. I took the idea back to my organization, where I was the single nonprogramming tester among ten programmers.
The first experience mob programming as a nonprogrammer was intimidating, and it isn’t something I would have volunteered myself for unless I had a firm belief that my discomfort was necessary to improve my team’s programmer-to-programmer relations. I took my four-minute turns at the keyboard like everyone else, listening to others tell me letter by letter what to type in order to code. The first round, I just felt like an idiot. The second round, I knew the keyboard shortcuts for the refactorings we were working on. And after that I relaxed and started contributing to the discussion about what is a good name for a method, reflecting on the domain concepts that I knew well as the team’s tester.
I realized that this approach also works well for testing. Mob testing means two things for me: the experiences I had as a tester while working in a programming mob, and focusing on a testing activity as a mob. As a tester in a mob, I turn everything I do into a testing activity, but I can also extend the whole activity to testing, be it exploratory testing or creating various types of test automation.
Mobbing on Testing Activities
Having experienced firsthand the amplified learning environment that the programming mob created for my team, I started experimenting with all-testing mobs. I would lead my programmer team into learning activities about quality through exploratory testing. The exclamations of “Oh, this is what you do to find all the problems!” started us on a journey of significantly better developer testing. It was like the box of secrets I had been handing out as explanations was all of a sudden something the team could digest.
A lot of the testing knowledge that makes us good at finding bugs comes from persistence, curiosity, and past experiences we can reflect on. It is hard to teach the tacit part of testing, and it does not transfer through documentation.
I did not stop with my team. We tried tester-only mobs at open space conferences, and later at regular conferences and trainings. I turned all my testing teaching into a mob format I would facilitate. I would give people a task, then narrow the task down with constraints that would make it easier or introduce techniques that would bring in new perspectives. It turned out to be a powerful way of teaching and learning through doing the tasks in a safe and supported environment.
Over time, I extended the testing tasks from exploratory testing to creating Selenium automation to learning test-driven development and other types of test automation. To understand that, we need to talk about the programming mobs.