Mob testing is a specific form of group testing where testing is done so that the group shares the input computers. I wrote an article on this for the Testing Planet and thought people might have questions, comment and own things to share after reading it. So this would be a good place to have that discussion.
The article: https://dojo.ministryoftesting.com/lessons/mob-testing-an-introduction-experience-report
Q1 received by email: How do Introverts survive in mobs? This sounds terrifying. “I’m an introvert and need quiet and focus to get in the zone and having to do something like this regularly would be incredibly draining.”
Q2 received by email: what about contracting environment? The customers would never pay for the whole team to work on a single thing. “In a consulting environment, where people are not necessarily invested in the team as a whole and are compensated per hour worked on the project rather than on growth value, do you even see a chance of a practice such as mobbing to take hold? Unless you get a team exceptionally motivated to learn new methods AND comfortable with working this way, or maybe an environment particularly suited to this sort of cooperation (a lot to learn for everyone or almost everyone on the team), I don’t believe either the developers or the management would pounce on this method.”
Q1 reply:
There’s a very nice article on mobbing for introverts that might answer some of your question by an introvert, Aaron Griffin who has now years of experience showing up into a mob on a daily basis. My discussions with him has lead me to realize that while it can be really draining at first, there’s a significant upside. Introverts often feel their ideas don’t get heard, and a considerate established mob can turn that experience around. Also, stepping out of rotation and reflecting, and even stepping out completely when you feel you need to recharge is encouraged. The work does not stop for one person leaving the mob. But Aaron has a lot more to say: https://www.agilealliance.org/resources/experience-reports/mob-programming-for-the-introverted/
Q2 reply
I work with teams in a product company, and in my current place of work getting people to mob (even pair) is extremely difficult. There’s strong ideas of how they learn best and that involving others in any way isn’t their thing. Forcing people isn’t my thing. But some groups volunteer to try things out, usually the ones that are no so established, over team limits. We have tens of teams here, and I work directly with many.
I’ve seen mobbing in use in contracting environments too, but for learning often it requires the idea of “we don’t invoice for these hours”. Some teams do their contracting work in a mob, with enlightened customers willing to pay as they see the deliveries being faster and more to the point. The main obstacle is always people. Not just customers and managers, but also the developers and testers. They “know” this won’t work without ever trying it and surely it does not work when you don’t do it.
I’m getting better at convincing managers. Developers still give me hard time. So I use other developers who have stuff to teach as my minions in taking this forward. For example, Llewellyn Falco is a developer who commands a lot of respect from other developers. Bringing him in to mob with us makes people show up to learn from him.
I have also a side job of consulting, although I do that very little. I do most of my teaching nowadays in mob format. So I show up at companies doing a two hour session with them. When we test together and they find problems on their own applications they were completely blind to, it changes things. I spent a day mobbing with a team I was considering joining (I did not - decided that they had much to learn from me and I had less to gain with that choice at that time) and we broke their “working” system in ways they never thought, and I could do this with them on day 1 without ever having seen or used their application (energy invoicing) before.
So, just get some group together and test together. Talk about what you learned and what you contributed. Celebrate both to enforce trying again.
What would you suggest for trying to encourage mobbing in the workplace, when they are reluctant to even pair up, and wouldn’t mobbing as a means to get the best out of a group of people, but taking up everyone’s time when normally only one or two people would have done it?
I love the idea and have read your leanpub book, but work in an environment which is reluctant to try new things, and prefers to do what they have tried before. Success with anything new is seen as an anomaly, and failures merely prove that they were right.
I have tried many things, having an environment with reluctance.
I really like the idea of mob testing and I would definitely give it a go.
How does the business see this from a resource perspective if 3 or 4 team members are working on a single body of work for 2-3 hours. Depending on team members but that could be $2500 + in billable hours. Did you find the Mob Testing findings resulted in the business saving more than the initial investment of the teams billable hours?
I have not learned to log on to this platform, and now that I did, I realize I left you waiting for quite a while.
I hear the cost aspect a lot. But it costs a lot to keep people working individually and not learning and collaborating too. I find that sometimes with mobs the thing we think takes a lot of time becomes minimal with the right brains working together.
At my previous place of work, two of our best developers made estimates of a new feature we were asked to deliver. They said it would take them three months to implement. So, a day of mobbing with the whole team of 9 people was nothing compared to it. We spent 2 hours with the whole team, 2 more hours with half of the team. This was on a Thursday, and we did mobbing only for learning purposes. The feature was ready on Monday afternoon. The business folks thought we had lied about how big of an effort it was. But we had not. We were careful with estimates, obviously. But we also did not realize how much technical assets (ready code we could use) we would find when we had the whole team working on it. Nor did we realize how the quality could be in place from getting started when the tester would also be in the mob.
I think personally that in this industry, we cannot afford not to pay for learning. I often speak of the idea that if we would get 1% better every day by investing 1 hour into learning, the cumulative nature of learning would make us outperform our past self in 28 days. Comparing ourselves today and in a year with the same 1% better every day, we could use as much as 6/8 working hours on learning to be on par with ourselves in a year.
Long story short: it is about the work going smaller with smart minds collaborating, and us getting better through learning that makes it worthwhile.
That sounds amazing… was there scope change during that process from what your 2 original devs estimated to what the entire team of 9 delivered?
Not really sure what you mean by mobbing for learning purposes possibly its similar to grooming as a team where there is knowledge transfer for everyone. This is so everyone knows what is happening and dependant on skill set (the devs may need to pair) anyone can pick up the work. With testing all AC are written up with any additional information ie environment set up, accounts etc. Is that what happened during the sessions?
Agree with the learning anyone who actually wants to stay in this game needs to personally invest in up or cross skill their own professional development and not hang around hoping their company might pay for it.
The rule (that is currently being challenged within certain fields but I feel still applies to tech today) is 10,000 hours of deliberate practice is needed to master a skill.
Maaret you may possibly hear my groaning now into my first few double digit hours of learning Ruby 
There was no scope change. I love this quote: “Features don’t creep, understanding grows”. And in this case, growing understanding of what we could reuse because we found it having everyone in the mob was really really valuable.
With mobbing for learning purposes, I mean doing activities that are not really trying to take day to day work forward but place solely the idea of mobbing on “let’s learn together”. It could be exercises that illustrate techniques, or it could be working on some of your own work stuff together but emphasizing just learning over being productive.
With grooming (story refinement as I insist on calling it), we talk about stuff. With mobbing, we do that stuff. And work unfolds differently in doing than talking. Then again, where I’m at we don’t do ACs. So that did not happen during the sessions.
I hope your learning Ruby has moved fro groaning to joy and groaning. 
good points and really interesting what your team is doing.
yes its turned to joy and groaning… actually more fascination with curiosity being filled + groaning. I never thought I would be doing this 
you really caught my interest when you wrote… “where I’m at we don’t do ACs.” now that Maaret is a conversation definitely worth having