To start, a little bit about MobProgramming….

This week(Monday 16th Feb 2015) i attended the XP Programming London Meetup (#xprolo). Benji Webber(@benjiweber) gave a talk about how Unruly have introduced “MobProgramming” into their teams. For those who aren’t familiar with the term Benji defined it as:

“Whole Team focused on same problem using one workstation”

Benji also referenced one of the well known advocates of MobProgramming, Woody Zuill (@WoodyZuill), who’s website has lots of extensive information around the concept if you want to research further –

As the term suggests, “MobProgramming” is primarily focused around the activity of programming. This generally means a group of developers, designing and writing code into a Development IDE, as a group such as in the image below:


On a practical level the team congregate around the screen at an agreed time and start working. The individuals in the group rotate operation of the keyboard around every 10-15 minutes so that everyone contributes code to the solution. The time spent “mobbing” can vary, Uruly have spent whole days doing it but found it can be quite draining working in a whole team activity all day.

The Benefits

Unruly have been doing “MobProgramming” for about 4 months and these are some of the benefits they have observed:

– Its fun!
– More emergent design – Team can design collaboratively as they progress
– Less synchronisation needed as the whole team are present
– Latency is reduced
– Reduction in emails and other offline communication

They have found that some problems don’t support “mobbing” for example things that fall into the Obvious domain in Cynefin. The team discuss and agree when they feel it is sensible to “Mob”. I’d like to think over the time the teams will identify some heuristics on when to “Mob” or use a model as a guide.


Thinking about how “Mobbing” could apply to other activities, it could work well for testing. Lets call this “MobTesting”

The same definition would still be valid:

“Whole Team focused on same problem using one workstation”

Most of the practicalities would also be the same, a big screen, one keyboard, whole team, white board nearby etc. Many of the benefits seen in “MobProgramming” would also be seen.

I do feel there are a couple of subtle differences between “MobTesting” and “MobProgramming”.

Testing is an “explorative” activity.

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.”

We are searching for useful information that we can provide the team and stakeholders to make an informed decision about the quality of a product. “MobTesting” allows us to benefit from having a whole team involved in two ways: Shared Responsibilities and Varied Perspectives.

Actors in the Mob

Firstly looking at Shared responsibilities. In “MobTesting” I see the following actors within the “Mob”:

1. The Driver – The person with the fingers on the keyboard/mouse moving through the application. elderly-driver_2164765b
2. The Note Taker – The person capturing the session. Testing and note taking is incredibly hard to do simultaneously. One of the benefits is that someone can focus on this such as producing a mind map or recording questions. notetaking
3. The Orienteer – The person helping us keep on track and to our charter. Often it’s easy to get side tracked when testing alone so having the benefit of someone to keep the mob focused may help. Antique Compass
4. The Observer – Stands back and observes what’s taking place. Often getting into the detail you can get temporary blindness. Simply observing can help see issues the driver may miss or skip past. Buyer-as-observer-300pxl-96dpi1-215x300
5. The Runner – Synomous with the TV industry. You could use this person to get the refreshments or better, if the Mob has questions for people such as the Product Owner “Is this what you expect?” They can run to the person and get quick feedback. making-tea
6. The Local Expert – Someone who knows the product, domain or technical detail of the Product. This helps if any questions arise from the mob. This person could drop in and out of the session or maybe pulled in at various points by “The Runner” Snip20150212_2

As per Benjis example in “MobProgramning” the individuals doing these roles should rotate every 10-15minutes allowing everyone to keep engaged in the activity. It also provides a good opportunity to practice skills of observation and note taking which can be applied when working alone.

Varied Perspectives

Another great benefit of bringing the whole team together to “Mob” is the varied perspectives on offer, especially if you can include those outside the immediate development team such as customers. If you already have a varied “cross functional” skill set within the Mob this will naturally bring a varied and rich perspective. If not, you can apply critical thinking techniques within the group to ensure a more varied perpsecitve. For example each person in the group could be assigned the ‘persona of a valued person’ such as a customer. You could also apply critical thinking techniques such as Edward De Bono’s “Six Thinking Hats”

“MobTesting” is not a “BugBash”

“MobTesting” shouldn’t be confused with a “BugBash”. I’m sure many testers have been involved in large group bug hunting sessions where the objective is to find bugs. “MobTesting” is different because we are exploring the product as a whole team with the intention of uncovering information, one piece of information could be a bug, but there are plenty more pieces of information that could be found.


If you can do “MobProgramming” and “MobTesting” surely you can just “Mob” anything! I’m not so sure. I think there are certain activities that make sense not to be done in large groups. Things that spring to mind are writing documentation, creating release notes and other similar activities that often fall into the Cynefin “Simple Domain”.

In addition to “MobProgramming” and “MobTesting” another activity that would be interesting is “MobDrawing”. This is where the whole team gather to draw out a design for a new product. In this case the pen could be swapped around the group every 5-10mins.

Watch out for the Mob

It’s important to watch out for bad behaviours when “Mobbing”. These include:

– Bike Shed Effect (’s_law_of_triviality) – Unable to agree on trivial things “such as the colour of the bike shed”

– Dominant Personalities in the group such as “Watch the Master” effect which can often be seen within Pairing

– Group Think – Where people agree for the harmony of the group in order to avoid disagreements

With regards specifically to “MobTesting” you should probably watch out for “Phased Mobbing” For example: Monday = “MobPrototyping”, Tuesday = “MobProgramming”, Wednesday = “MobTesting”

“MobTesting” can be done at any point in the life of a product, in fact you don’t even need a line of code to have been written. You could do “MobTesting” on a paper prototype or a set of wireframes. Testing can also be done in “MobProgramming” and Programming can be done in “MobTesting”. The main difference is that in “MobTesting” we specifically want to focus on a testing problem.

The value of “Whole Team”

Wether we stick “Mob” on the front of an activity or not isn’t really the important thing here. “MobProgramming” and “MobTesting” simply amplify the benefits that can be found when whole teams work together on one problem rather then separately. To exaggerate the point, there is even some evidence that working as a whole team can lead to solutions faster than if people worked apart or in pairs.

You can read more about the Unruly Mob here:

Practical tips for pairing with a developer to test


Pairing is seen to be a popular way of working with software. The two common types of pairing are “pair programming” and “pair testing”. In both examples I think of the words “programming” and “testing” to refer to activities rather than roles. This means anyone can take part in these pairs. In my experience pair testing works well with two testers but also with a tester and a developer.

James Bach and Cem Kaner explain pair testing as:

“Pair testing is different from many other kinds of pair work because testing is an *idea generation activity* rather than a plan implementation activity. Testing is a heuristic search of an open-ended and multi- dimensional space. Pairing has the effect of forcing each tester to explain ideas and react to ideas. When one tester must phrase his thoughts to another tester, that simple process of phrasing seems to bring the ideas into better focus and naturally triggers more ideas. If faithfully performed, we believe this will result in more and better ideas that inform the tests.”[1]

Pairing with a developer to test is a great way to learn about a product, resolve bugs quickly, generate test ideas and a great opportunity to increase testability.

When originally working in cross functional agile teams I found it difficult to identify how to approach pairing with developers. All too often, developers and testers worked in silos waiting for the code to be moved to the “Ready for Testing” column on the Task board[2]. On the occasions i attempted to work more closely with developers it was hard to keep the conversation going more than a few minutes.

One “tool” I’ve found incredibly useful to aid pair testing sessions with developers is the debugger built into most development IDE’s such as Visual Studio[3] or Eclipse[4].

When coding a feature developers will use the debug capability to do just that, debug their code to check its doing what they expect and track any exceptions that may occur.

When it comes to pair testing with a developer our context will be slightly different. We are less concerned with “debugging” the code and more concerned with using the “debugger” as a tool to support testing. It is a great way to observe and control the application during testing.

The benefit of using this tool is that it facilitates the discussion between the developer and the tester. Ask the developer to “step through the code” using the debugger and explain as he goes. Don’t worry if you can’t code, the objective here, as I said earlier, is not to debug the code but to test. As the developer is talking through the code, ask questions, observe patterns within the code, and listen carefully to what he says and how he says it. As the debugger allows you to control the code it’s great for those moments when you ask the question “What If?”, “Can you show me?”, “Hold on a second.” It means as a pair you can explore those questions easily with complete control over the code going back and forth as you please. Don’t expect answers to all your questions and don’t dwell too much on a single point. Take diligent notes and return to these later in the session or in a following pair session.

Having the ability to stop at points in the code also enables the developer to point out important parts of the code. For example parts that directly relate to the Acceptance Criteria of a Story such as a calculation algorithm.

To support this conversation ask about Unit Tests that have been written to check the code. Ask the developer to step into the unit tests and explain what has and also importantly hasn’t been unit tested.

The joy of pairing also means a quick fix and retest process. It’s possible for simple bugs to be fixed there and then with more complex bugs can be recorded ready for the fix to be explored in your next pair session. Getting familiar with the debug process enables you to also debug through the code should you find any bugs. For many issues exceptions will be thrown by the application so you can point these out to the developer should you find an issue. If your comfortable with code, you could even code up a fix and review it with your developer.

Another good output from this pairing session is ideas for exploratory testing sessions. You can ask the developer areas he’s perhaps uncomfortable with and in many cases I’ve found developers more than forthcoming with that information. During your pairing its natural for there to be some areas your not entirely comfortable with and the gut instinct will kick in. As the story matures towards “Done” you may find your pairing sessions move away from the debug tool and become more exploratory in nature.

It’s important to pair throughout the story, not just at the end. Find a balance that works for your team. The developers within my current team are good because they will shout once when they need me and on the flip side are open to me approaching if I want to pair up. Alternative approaches are to schedule calendar reminders at the start/end of each day or after lunch, this might support testers in large development teams. Pairing frequently means that you will gradually take bites of the story rather than being overwhelmed at the end. Bringing questions or bugs you’ve observed in your own testing also helps kick start the next pairing session. Getting access to the application code and being able to run it locally will help you prepare for your next session. It will also help you get more familiar with the capabilities of the development IDE.

Another good benefit of pairing is testability. Explaining how you’d like to control and observe the application allows you to directly influence the design of the code. Maybe you’d like the logging to be improved, maybe a different kind of variable to be used that’s better for automated checks, or maybe you need a method to tear down data. These are examples of Intrinsic Testability and James Bach explains there are other forms of Testability[5]. In my experience many of these are emphasised through pairing:

Intrinsic Testability – “If we hadn’t agreed during our pairing to put in extra logging we may never have noticed it”

Project Related Testability – “Having the developer explain areas he wasn’t too comfortable with and couldn’t Unit Test helped us really focus our exploratory testing charters in those areas.”

Value Related Testability -“Through our pairing we have built a strong rapport and we are comfortable asking each other challenging questions or constructive feedback”

Subjective Testability – “Now I know how to run the application locally I can debug through the code and provide more technical information about where the code might be going wrong. I sometimes even feel comfortable coding a fix.”

So in summary, pairing with a developer is a really effective way of testing. Use the tools available such as the debugger as a way to facilitate the conversation between yourself and the developer. As your relationship grows you’ll find your sessions become more efficient allowing for more time to be spent on the complex and complicated areas.

[1] Exploratory Testing in Pairs –

[2] I’ve found that when teams have “testing” columns on task boards it encourages developers and testers to work in silos. I personally prefer To Do – In Progress – Done.

[3] Debugging in Visual Studio –

[4] Debugging in Eclipse –

[5] Heuristics of Software Testability –