Pair Testing in Software Development

Software development is about cultivating differences in points of view. One of the reasons different roles exist, like product owners, designers, developers, testers, DevOps, and project managers, is to have different points of view during any life cycle. It could be a project life cycle, a product life cycle, a software development life cycle, a software testing life cycle, etc. A product owner will be business oriented. It's all about what we release and its value to the customer. A developer is more implementation driven. It's all about how to implement our features in code. A tester's point of view usually includes technical aspects and business aspects. It's all about constructively critiquing the product and giving valuable feedback to stakeholders.

One way to cultivate differences in points of view is to use pairing activities. Pair programming and pair testing are two of the most popular. This article focuses on pair testing, and I will share experiences on how teams have used pair testing to their advantage.

Pair Testing Per Role

Pair testing can be done between testers, between developers, and between testers and developers. As long as there is a difference in focus and perspective between the people involved, pair testing will be beneficial.

Pair Testing Between Testers

No matter how well-planned and organized testing is, pairing between testers may find missing edge cases. Especially between testers with different levels of expertise, brainstorming cases to test in an exploratory session will help learn more about the system under test. For example, a usability tester pairing with a backend tester may supplement each other in ways that could result in interesting findings. Testers between different development teams have scheduled pair testing sessions each time a new feature is ready for testing. In some cases, pair testing was scheduled before test execution and during test-case design.

Pair Testing Between Developers

A frontend and a backend developer could brainstorm about why things work the way they do in use cases that require tricky implementations. Next, developers between different teams could pair-test for code interdependencies. One team used pair testing for unit tests and integration tests. Other teams tested in pairs all the way from unit and integration testing through API testing. Finally, a development team with no testers used pair testing to broaden their views about their implementations.

Pair Testing Between Testers and Developers

This is usually one of the most effective combinations to pair test. A developer often tests to check that the implemented code works as expected. A tester often tests end-to-end to check that the software system behaves as expected. Most importantly, the tester must also explore any kind of risks and surprises in the system. Pair testing with a developer to work through surprises and risks can be educating for all involved. The tester can learn from the developer why the system behaves that way. The developer can learn new ways to examine the system and use cases resulting in problematic behavior. For example, there was a development team of six that pair-tested altogether before release. The developers had already tested at a unit level and had also performed smoke testing at a UI level. The tester had finished verifying system behavior and exploring. They used a time-boxed session where the entire team participated for a final green light to release. Another team did whole-team pair testing after the release. After all testing activities were finished, and the feature under test was released, the team gathered for a whole-team smoke testing activity. This helped the team to gain confidence that the release caused no unpleasant surprises.

Release Features Faster

In a team that followed a cycle like: develop → code review → QA test → release, pair testing before code reviews and during development helped release features faster. Developers organized pair-testing sessions with testers to demonstrate how their features worked. During pair testing, they examined positive and negative scenarios. Look and feel aspects of the UI were discussed, as well as possible performance bottlenecks. When both were happy with the results from their pair testing, the developer would check the code under test. Code reviews would follow, and then thorough QA testing from the tester. Pair testing would usually catch basic issues. This reduced the development → code review → QA test cycles for fixing bugs or implementing important improvements before releasing. Fewer cycles meant faster releases.

Find More Bugs

Pair testing can be used to find new bugs. No matter how many tests we write, no matter how many cases we execute, we always find more bugs when we think out of the box and when we test the system in new ways. We could have an impressive amount of test cases covering all functional and non-functional requirements available. In time, test suites will catch regression bugs. Although regression bugs are important to find and fix, there could be other important bugs that remain unidentified. Brainstorming during pair testing may bring the creativity required to explore and identify new problems.

Fix Bugs Faster

Showing problems to colleagues in pair testing sessions appears to be more effective than issuing bugs in bug tracking systems and waiting for a colleague to find the time for bug fixing. Bugs must be tracked in bug tracking systems. In remote working environments, however, where people are working in vastly different time zones, bugs identified during pair-testing sessions are more likely to be resolved faster. Communicating and working together through a bug often leads to more effective problem-solving.

Explaining Helps the Explainer Too

Oftentimes, when we explain a phenomenon to the best of our abilities, we tend to understand better the phenomenon we had just explained. Not only did the people listening to us know, but we also understood better. One of the most important values that pair testing brings is that pairing improves both people's understanding. This will often lead to new ideas and solutions to problems since exchanging new ideas can boost creativity. When a developer tries to explain how things work with the new code implemented, she will likely understand things that were not so clear in the first place. As a tester explains the sequence of actions followed to reproduce a sporadic problem, hidden details of the problem may become apparent to him.

Wrapping Up

Pair testing can be done between any roles in a software development group. Between product owners, designers, developers, and testers and between colleagues with the same role. To get the most out of pairing, we need diversity in points of view. Diversity can lead to creativity. As long as diversity also leads to constructive feedback, pair testing can effectively improve our confidence in high-quality feature releases.