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.
Being a Tester in a Programming Mob
While mob testing on testing activities is a great learning exercise that transfers tacit knowledge from one tester to another, mob testing as a tester in a programming mob is an activity that transforms the team’s capabilities.
My team started a weekly learning mob. The first one was on refactoring code, and I already contributed good names through deep understanding of domain concepts. The second was about sharing knowledge of Selenium automation a developer had been maintaining alone, and in addition to most of the team now being able to add Selenium scripts (including me), I could see I contributed better ideas of what and how to test.
The two sessions that gave me the most confidence about mobbing were ones where we worked on adding new features. I could clearly see my contributions:
- Correcting mistakes without ego in play: Recognizing what would have been expensive mistakes saved us weeks of work with immediate feedback, and instead of one person finding the error and one person being to blame, all of us found and fixed the problems together.
- Deliberate thinking: My slowness while learning to write code under instruction made the developers think carefully about what to tell me, and they realized it resulted in better choices.
- Stealth exploration: We had more features ready after mobbing because I would interject testing ideas during development: “Could we change that to another user?” “Can we run it in IE9 for a change?”
- Being a quality conscience: With everyone in the room, we cared about cleaning up the code, and we cared about finishing the work, including exploratory testing. There were times someone would look at me and say, “You’d want us to do this, right?”
- Transferring testing skills: The secret recipe of what makes me great in finding problems was out. The developers caught onto the basics of testing, and I had a foundation to build even deeper skills.
In a mob, a common rule to remember is “Learning or contributing.” If everyone is doing one of those two things, it’s an effective mob. We all have our strong moments and skills areas and our weaker ones. When we work in a mob, everyone contributes their best into the work we do. It might not be the most we get out of each individual, but in software development, avoiding rework and amplifying learning makes a difference in the bottom line of what comes out.