Do you test areas with high risk, high complexity, or anything that generally requires extra attention? If so, mob-testing is definitely a concept worth recommending.
What is mob-testing/mob-programming?
First of all, they are two sides of the same coin — but I’ll return to that later. So what is it? Hopefully you’ll find out as you make your way through this blog post. As with many other newer trends and initiatives within software development, it’s about being able to deliver the right product with the right quality to the customer — while continuously improving the way we work, the way we communicate, and how we create a shared understanding across our different backgrounds, approaches, roles, etc.
Mob-programming/mob-testing has its roots in pair programming, so let’s pause for a moment and look at what pair programming actually is.
Definition of pair programming
Pair programming is a discipline within Extreme Programming (XP) and one of the practices XP is built on. According to extremeprogramming.org[1], pair programming can be described as follows (freely interpreted by yours truly):
Two people (a driver — the one with the mouse and keyboard — and a navigator — the one “reviewing” and coming up with good ideas) sit side by side at one screen with one keyboard and one mouse. They take turns controlling the keyboard and mouse. The benefit is that two people can solve problems faster than one; working together increases focus, both gain a better overall understanding and create shared ownership. The outcome is a higher-quality product.
Mob-programming
Mob-programming is “next level pair programming.” Here it’s not just two people, but an entire “mob” sitting together around one screen, one keyboard, and one mouse.
But what is a “mob”? According to the Cambridge Dictionary[2], a “mob” can be one of three things:
- a large, angry crowd, especially one that could easily become violent
- an organization of criminals
- a group of people who are friends or who are similar in some way
“Mob-programming, just like pair programming, aims to create a higher-quality product.”
Since mob-programming — just like pair programming — aims to create a higher-quality (and more correct) product, the first two definitions are probably not the right ones. The third definition, “a group of people who are similar in some way,” sounds much more relevant. So who is this “group of people who are similar in some way,” and how did mob-programming come about?
The story behind mob-programming
Mob-programming was “created” by Woody Zuill [3] almost 10 years ago — or perhaps more accurately, “discovered.” Woody was hired by a company to help them, and one of the things he emphasized strongly was that the team he was supporting should grow and learn new things. His idea was that instead of each person sitting alone reading a book, listening to podcasts, watching videos, and so on, the entire team would sit together to learn — and learn by doing. This had several advantages: they could help each other learn, the atmosphere was more relaxed than being under pressure to deliver something specific by a certain deadline, and it generally created better group dynamics.
They started by meeting every Friday and sitting together to learn by doing some “code experiments.” As with pair programming, there is a driver and a navigator — but here there is also a group of observers. The navigator instructs the driver on what to do, while the rest of the group follows along. After about 5 minutes, they rotate roles so everyone goes through all three roles.
They did this every Friday for about half a year and, during that period, collectively became better at writing cleaner code, solved problems much faster, found smarter solutions, etc. The result was significantly better software than before.
A side effect was also that the team members became much better at expressing themselves clearly and unambiguously, so the driver knew exactly what code needed to be written to solve the problem. One day they were about to start a larger project and more people were added to the team. The challenge was that many were not entirely sure how the product should be developed or how the code should be written. They began with a traditional meeting where they talked about the challenges and distributed tasks.
But during that meeting — where they also tried out some coding ideas — the pattern they had developed in their learning sessions suddenly became visible: people naturally slipped into the roles of driver, navigator, and observer. The difference was that now the observers were no longer passive, but actively contributed to problem solving and simplifying the code being produced.
This is how mob-programming was discovered: from being a weekly learning method, it evolved into a team process where they sat together and developed the product collaboratively. This is also where the testing angle entered the picture, because they suddenly had questions about the product they couldn’t answer: should it work this way or that way? They were missing some people in the team. A business expert joined who could answer those questions.
“It’s very much about creating shared understanding, examining challenges from as many angles as possible, solving problems the right way, and ultimately ending up with the right product at the right quality.”
Based on the idea of the three amigos (developer, tester, business), it therefore makes good sense to include testing as part of the team. It’s very much about creating shared understanding, examining challenges from as many angles as possible, solving problems the right way, and ultimately ending up with the right product at the right quality.
Does it always make sense to do it? Probably not. But if there are uncertainties, high complexity, strict compliance requirements, or other areas that require a lot of attention, it is definitely a concept worth recommending.
In the beginning, it will definitely reduce your productivity — suddenly the whole team has to relate to a new way of working. In addition, during the start-up phase there will likely be many challenges related to finding the right room, setting up the right physical environment, getting the right people involved, and getting those people to contribute positively to the process. Very few are as lucky as Woody Zuill — but in the long run, it will certainly create value for quality.
Mob-testing
Although mob-programming and mob-testing should be synonyms, mob-testing can also be used as a separate discipline: a form of exploratory testing in a larger forum. Just like mob-programming, a larger group participates, with one screen, one keyboard, and one mouse — but here the focus is exclusively on testing. When several people — again with different perspectives (the three amigos) — sit together, new ideas and new approaches often emerge, perspectives you might never have come up with on your own.
How to get started with mob programming / mob-testing
As with so many other things: start small — perhaps like Woody and his team, by using it as a learning approach first. Fortunately, there are many great resources if you want to get started with mob-programming / mob-testing. We would definitely recommend taking a closer look at these sites:
https://woodyzuill.com/ – the person who started it all
https://maaretp.com/ – has written many blog posts about the topic and wrote the book Mob Programming Guidebook
https://www.lisihocke.com/ – practices mob-programming, speaks and runs seminars at conferences about the topic
Need help?
If you need help getting started with mob-testing or would like to learn more about the topic, feel free to contact us at +45 44 979 979 or via e-mail at info@testhuset.dk. We are, of course, always ready to help you.