Teams that use agile methodologies are well aware of the need for their developers, testers, product owners, and other team members to collaborate. They have meetings at the start of a sprint to analyze and work together to elaborate the user stories that they’ll be working on, and they usually gather each day for a 15-minute standup meeting. But for much of the rest of the time, they are hunched over their own keyboards and screens, working on their own tasks. While many developers work with each other during pair programming and code-review sessions, testers often work on their own.
I recently spoke with Maaret Pyhäjärvi, a Helsinki-based software consultant with a passion for collaborative testing techniques. I asked her about some of the approaches that testers can adopt in order to work together and improve their testing, as well as work better with developers. Here are some of the testing approaches that involve a more social aspect.
Pair testing
Extreme programming, or XP, was originally developed by Kent Beck in the late 1990s. One of the practices included in XP is pair programming, whereby two developers work together on the same computer. One of them will be the "driver" (or pilot), having control of the keyboard and typing code. The other is the "navigator" (or co-pilot), who reviews the code that the driver is writing, challenges the driver, and suggests alternatives and improvements. The roles are switched frequently, so that one doesn’t take over the whole session while the other gets too comfortable in the passenger seat.
A similar approach has emerged around testing. With pair testing, two testers, or perhaps a tester and a developer, will work together around a single keyboard, with one person being the driver and the other the navigator. The driver controls the mouse and keyboard, and the navigator asks questions, suggests new and alternative ideas, and challenges the driver’s assumptions. As with pair programming, the roles are swapped frequently throughout each 60-to-90-minute pair testing session.
When two people work together, they tend to generate more ideas, which makes pair testing great for exploratory testing. But it can be used in automated test design, development, and execution as well, whether in functional testing, performance testing, security testing, or any other type of testing.
As one person explains his ideas and bounces them off the other, each participant understands his own ideas better and seeds new ideas. In the words of the old adage, “If you can’t explain it simply, you don’t understand it well enough.” By working in a pair, each one will drive the other, and it becomes less tempting to be sidetracked with distractions.
Pyhäjärvi notes that pair testing has started to become popular in recent years and that pair testing isn’t limited to testers only; often, pairs will include a developer who is focused on testing during the session. While testing the application, they are also building a relationship and helping to remove any barriers between testers and developers.
Strong style pairing
Agile coach and developer Llewellyn Falco has adopted a style of pairing designed to avoid potential problems with pair testing, such as one person doing all the work while the other watches, or the opposite—fighting over the keyboard.
The thrust of Falco’s style is “For an idea to go from your head into the computer, it must go through someone else's hands.” The navigator cannot sit back and watch the driver type. The contract between the navigator and the driver requires the driver to only type what the navigator directs—much the same as the way the navigator in a car tells the driver when to turn left or right. This style of pairing has been referred to as strong-style pairing.
Learn more about pair testing
Some useful resources:
- Cem Kaner and James Bach’s early paper on Exploratory Testing in Pairs
- Rama K’s detailed description of Testing Techniques in Agile – Pair Testing
- Katrina Clokie’s case study of Benefits of cross-team pair testing in agile
- Llewellyn Falco’s explanation of Strong Style Pairing
Mob testing
Mob programming takes XP-style pairing to the next level. First documented by Woody Zuill, Mob programming extends the collaboration between a pair to the whole team that is working on developing a feature. As with pairing, one person controls the keyboard, but the rest of the team sits in the same room, taking the role of navigator. After about 15 minutes, roles are switched, and one of the navigators becomes the driver. Testers can also be part of the team doing the navigation, but Pyhäjärvi finds that it is also effective for testers to have their own mob testing sessions modeled on mob programming.
Mob testing sessions typically focus on testing a part of the application and can include exploratory testing and test automation. The technique works well when testing teams have specific testing-oriented tasks. Although mob programming teams typically spend most, if not all, of their working week with the mob, Pyhäjärvi advises that mob testing should be used primarily for training and as relatively short "breakout" sessions from mob programming. If testers are spending most of their working week doing mob testing, then the teams should re-evaluate the relationship between testers and developers.
The mob can help with confidence
A mob testing session is a great way to help introverted team members learn when and how to speak up and contribute and also teaches extroverted testers when to step back and allow other people’s voices to be heard. While becoming more effective testers and knowing their product better, testers learn the skills that they need when they join in mob programming sessions with developers. Mob testing is as much about learning as it is about testing.
How mob testing works
To manage a mob testing session effectively, you’ll need a computer connected to a large display, or a projector. To make sure that the rotation between driver and navigator happens, Pyhäjärvi recommends using a stopwatch, such as on a mobile phone, which should be set to between three and twenty minutes. Inexperienced teams should favor shorter intervals, which will ensure that everyone gets the chance to learn and implement what they’ve learned.
More established teams might want to use a timer on the computer that blanks the screen when it’s time to swap. She also suggests that people use their own chairs when it’s their turn to drive rather than sit in someone else’s chair, which might not be adjusted ergonomically.
Co-location, while desirable, isn’t required. As long as everyone is in similar time zones that allow them to spend enough time together in the session, mob testing can be done using virtual machines and screen-sharing programs, such as ScreenHero or Google Hangouts.
The primary advantages of mob testing are that it provides a learning environment that gets the best results out of everyone. It encourages everyone to actively contribute, and if the session slows down a little, people tend to naturally encourage each other to get back on track. On the downside, there is a learning curve associated with effective mob testing, and some people feel uncomfortable in this kind of social setting. However, the sessions themselves contribute to building trust, consideration, and respect among the participants.
Learn more about mob testing:
Some useful resources:
- Maaret Pyhäjärvi writes extensively about mob testing on her blog, A Seasoned Tester's Crystal Ball
- Watch mobs at work in this video of a day of mob programming
- Read The Mob Programming Guidebook, by Llewellyn Falco and Maaret Pyhäjärvi
Testing in the coffee break
We occasionally forget that testing is about examining software, not about test plans and processes and rules. Sometimes, the simplest approach works well too. When a developer goes off to refill his coffee mug, he can invite a tester to use his development computer to test the software he's working on. And when the developer comes back, they might decide to continue the session as a pairing session.
It’s not an official build, but why wait till the code gets checked in before a tester looks at it? It doesn’t need to be a long session; sometimes just a few seconds of someone else’s eyes looking at the user interface can spot a problem that has the potential to snowball further down the line. While code reviews with another developer usually center on the actual source code, this type of review with a tester focuses on the functionality. Testers too can invite another tester to their machine during a coffee break, even if they’re not formally testing on the same parts of the product.
Value those interactions
Modern software development methodologies value interactions between people. This applies to every aspect of producing software, including testing. The approaches mentioned above all involve social interaction, and joining forces to achieve the group’s objectives. As well as providing opportunities for the team to jell, they can be effective ways of getting the best out of everyone involved in the product’s lifecycle.
Sure, some people are skeptical about pairing and mob testing. Pyhäjärvi herself told me that she initially thought that there’s no way that mob programming could work. But she challenged herself to try it, and has since become a staunch advocate of mob programming and mob testing as effective mechanisms for sharing skills and knowledge.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
