PM Articles > Alan S. Koch > Agile Testing - Pair Testing, Part 3 of a Series

Agile Testing - Pair Testing, Part 3 of a Series

by Alan S. Koch, PMP

This column is the third in a series.

Part 1 What Is Agile Testing?

Part 2 Agile Testing: No Mini-Waterfalls!

Part 3 Agile Testing - Pair Testing

Part 4 Agile Testing - Technical Excellence

One of the 12 Agile Principles states that everyone "must work together daily throughout the project." This principle about collaboration plays out in many of the practices that are defined by the Agile methods and embraced by many Agile teams.


The ultimate in collaboration is pairing.

Extreme Programming includes a practice called Pair Programming in which two developers work together at one computer doing one programming task. Clearly, when two people are sitting in front of one computer, they can't both be typing; so what is going on? One of them is typing while the other is watching. It is a continuous real-time peer review of sorts.

But the main purpose of Pair Programming is not the typing; although writing code is an important outcome, that can be done more cheaply by one person. Nor is it the watching; although a peer review provides value when defects are found and fixed early, it doesn't have to be done real-time.

The main purpose of Pair Programming is collaboration: two programmers discussing how to do the work, arguing design options, critiquing each other's choices, each ensuring the other follows the team standards, catching each other's mistakes, taking over when the other gets stuck, and ultimately writing better code.

Is Pair Programming really worth it? Organizations that use Pair Programming report that it actually saves programmer time because of the avoided rework. And not just bug fixing. The big win comes from avoiding the refactoring that is necessitated by design defects -- a big win indeed!

Pair Testing?

Pair Testing is a natural extension of Pair Programming. If we can do better coding by pairing, it stands to reason that pairing will result in better testing and a better delivered product. And indeed, this is what the organizations that do Pair Testing report.

But Pair Testing is different from Pair Programming in one key way: Pair Testing works best when using heterogeneous pairing (pairing of unlike people). Specifically, it's best to pair a developer with a tester. How is that a good idea? Let me count the ways!

  1. Developers must test (both unit and functional testing) before they declare done. And this testing needs to be done well because it is foundational. Later testing by testers, the Product Owner, and end users builds on developer testing, and it verifies the basis for continued development in later Sprints.
  2. Many developers have never learned to do good testing, and can benefit from one-on-one interaction with a tester.
  3. Testers are often unaware of the technical complexities that should drive their risk-based testing approaches.
  4. The different backgrounds complement each other. Testers know about testing practices and strategies, and developers know about technical issues.
  5. A single testing activity that includes all of the types of testing that need to be done is more efficient than the back-and-forth of the traditional approach (develop, then test, then bug fix, then re-test).
  6. Each person learns from the other, making both more able team members and increasing the capabilities of the team.

Pair Testing can provide a lot of value. So let's look at how to do it.

Collaborative Test Design

Testing starts with Test Design, so the collaboration must begin there as well. And because of Agile projects' incremental approach to requirements, Test Design must follow the same incremental process. So we will look at how to collaboratively work out the test design incrementally.

Collaborating on the Project Test Design.

As the Agile team produces their Product Backlog at the beginning of the project, and as they maintain it through the project, they have the opportunity to collaborate on test strategy for the overall project. What kinds of testing will need to be done? When should each type of testing be done, and what is the best way to do it? Do we need any special tools or environments for testing? How will testing activities impact the project? Will we need to plan for Stabilization or Hardening Sprints before releases?

The best way to collaborate at this level is for the team to draw one or more graphical representations of the product they are working on, to serve as a basis for discussing the testing implications. The tester should take the lead in these discussions, but input from the developers and Product Owner is key to ensuring that the project's testing needs have been identified.

Some of the agreements coming out of this discussion will be incorporated in the team's definition of "Done." (e.g. Work is not done on a User Story until this or that testing has been completed.)

Collaborating on each Sprint Test Design.

Sprint Planning is when many of the requirements are worked out for the User Stories that will be implemented in that Sprint. Many Agile Teams document Acceptance Criteria for each User Story, which clarify not only what must be developed, but also the testing that is required.

With those additional details, more specific Test Designs can be worked out. As a part of the Sprint Planning meeting, the team should collaborate to decide how their Project Test Design (discussed above) translates into activities in this Sprint.

The primary result of this collaboration is that the team's Sprint Plan includes all of the test preparation and testing activities for the Sprint, and each team member understands how those activities relate to his or her work. The remainder of this article discusses a collaborative approach to the specific activities and responsibilities that should be included in the Sprint Plan.

Collaborating on each User Story Test Design.

The final requirements details for each User Story are generally worked out as the work is progressing during the Sprint, and the Test Designs for those User Stories should be worked out at the same time.

The best collaborative approach for this involves the tester, developer, and Product Owner working together to agree on those final details and the testing that will be necessary to verify and validate them. Based on this, the developer and tester can further collaborate on test design details that are driven by technical implementation issues.

If the team is using Test-Driven Development (also called "Test-First"), then the creation of all of the tests can be done collaboratively as well. This is best done as a true pairing of developer and tester in front of one computer as the automated test scripts are written. (If the team is using Pair Programming, adding a tester to the pair during the test preparation makes sense -- a bit of Triad Programming!)

Collaborative Testing

Ultimately, the developer will write the code for the User Story, and it is common for the tester to be preparing for testing at the same time. Then actual Pair Testing can begin, with the tester and developer sitting in front of one computer doing the testing together.

The developer would start with the more technical unit tests while the tester observes, comments, and makes suggestions. After that basic testing is done, then the two can collaborate on the functional testing. They can trade off the typing and observing roles while doing negative tests and checking special cases, and add tests as each sees fit until both are satisfied that the User Story has been completely tested.

Finally, they would agree together about which of those tests should go into the team's regression test suite, and work together to update the regression test suite. If the regression suite is automated, they would collaborate on coding and testing the automated scripts. If it is manual, they would work together to document the regression tests in the way the team as agreed to document them.

Getting Started with Pair Testing

Pair testing fits neatly into any Agile process, so the only challenge lies in how team members view testing activities and their roles relating to them. We traditionally think of testing as being the domain of the tester. And although we recognize that developers must unit test, we generally don't think of testing as being a significant part of their job.

Moving to a truly collaborative approach to testing means changing how we think about testing. Each member of the team must embrace testing as an important part of his/her job and actively look for ways to collaborate with all other team members on testing. In the best-running Agile teams, the difference between testers and developers is more about the knowledge and expertise they bring to the team, and less about who does the testing.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.