In the past, we talked about how we maximize our engineering velocity here at mabl, but now we're going to speak on a concept that some organizations view as a duplication of effort.

The concept of a code review is well known throughout the software industry. Perhaps less well known is pair programming, in which two developers work together on the same code. The aim is to write considerably higher quality code than what typically results from individual effort. A common approach in pair programming is to have one programmer write code while another programmer reviews the code—as it is being written.

In terms of formal roles, one programmer is the driver and the other is the observer or navigator. Less formally, two programmers can have an elaborate discussion as they analyze a single code base. Either of the duo should be able to write good code, and they both agree to avoid all distractions.

The Dark Side of Pair Programming

Pair programming is fully embraced by some companies—and entirely rejected by others. Since we are all human, there are at least some situations in which nearly all software programmers can benefit from pair programming. To many professionals, however, it seems to be generally an inefficient use of resources. Theoretically, two programmers can separately build different features or functions, which should result in twice the output of a single programmer or pair programmers. In reality, many teams report that their developers produce software that is 95% complete but doesn’t integrate well and is not shippable to customers. This is the reason why pair programming is given serious consideration in many software development organizations.

Extreme Programming

 

Pair testing

Much like pair programming, pair testing involves one person that does the testing—while another person observes, inquires, clarifies, records notes, and spots defects that would otherwise go unnoticed. Pair testing can be especially effective when one programmer sits together with a tester.

Pair testing accomplishes the following:

  • Finds more bugs
  • Saves time
  • Eliminates the communication gap between testers and developers
  • Is an excellent opportunity for very efficient exploratory testing
  • Provides visceral, in-person learning opportunities

Ideally, pair testing should give each participant an opportunity to take the wheel. When the tester is driving, the programmer can gain deeper, more valuable insights on how a tester uses and perceives the software. While the programmer is driving, the tester can gain a deeper understanding of how the software has been built.

Pair testing is especially effective during development. Many problems will be found at such early explorations, and this early identification will likely result in a much easier solution. If possible, invite a business analyst to pair testing sessions, and this upstream triad is sure to reveal any lurking logic, design, usability, or functionality issues. Further downstream in the delivery pipeline, post-development pair testing collaboration can be valuable for improving development and testing practices.

Pair Testing Gone Wrong


How to start with pair testing

Begin by selecting a code base that is modest in size. If it’s too large, the pair may be overwhelmed. If it’s too small, then there won’t be enough to test. Ideally, it’s best if the the tester and the developer have spent time working with each other previously. Prepare a mutually agreeable testing plan, then structure the meeting so that it includes time for each participant to use the software. It may require one or two sessions to get through. Then, reconvene and share feedback. Discuss what works well, what didn’t seem productive, and how pair testing can best into the development pipeline.

Pair testing results

For pair testing to be valuable, you’ve got to produce communicable results. This can be done in various ways:

  • Testing docs — Prepare by writing up a test plan that includes testing ideas that will justify how you will run the test.
  • Defect report — While exploring a problem with a developer, it may become clear that a defect is at the root of the problem. Document this well so that the development team can correct it.
  • Session reports — Each participant should take notes and share it with the rest of the development team and stakeholders.
  • Test automation — This may be a good opportunity to collaborate with the developer and automate a test more efficiently and comprehensively. This test can be added to the regression suite and reduce repetitive manual exploration testing in the future.
  • Knowledge sharing — This is not strictly tangible output, but it is an important outcome of pair testing. Each participant can share insights with each other, and then share with other members of the team.
  • Informing stakeholders — This includes the test plan, testing concepts and ideas, and the session report. For those who take interest, share information on the defects that were discovered and retested.

Pair testing limitations

Pair testing is an excellent complement to regression and automated testing, and may result in significant time savings for smaller teams. It is not, of course, a replacement for other types of essential testing efforts. Some larger companies may find it difficult to integrate pair testing into an established development pipeline. A good approach is to wait for a phase transition—or the beginning of a new project—to introduce pair testing in a specific area.
 

Going forward, together

Pair testing can be the most valuable in teams for which there is at least some tolerance for deeper thinking, exploration, and some creativity. It’s unnecessary to prepare test scripts, nor do you need GUI as a launch point for testing. Find two team members who are critical thinkers. It’s best if one is creative and the other has the capacity for disruption. As in many other aspects of human experience, two minds can be much more productive than one.