What
Two people (such as a developer and a test specialist) working together (at one desk or in a call) to perform exploratory testing (not just verification of requirements) on a code change together before the developer picks up a new ticket.
Why
- Removes waste in the test-fix-retest cycle
- Uncovers implicit requirements more quickly
- Reduces context switching
- Creates developer-tester understanding and rapport
- Spreads test techniques & thinking
- Knowledge sharing on the development process
- Knowledge sharing on the product
How
Once a code change is ready to be reviewed (and it even pays to do this before code reviews or during coding), the developer should invite a test or product specialist to join them in a call or at their desk. Then the developer (the Driver) demos the change and the test specialist (the Navigator) offers test scenarios and asks questions. The developer executes the tests. Together they fix and retest, with the developer typing and the test specialist guiding.
The Driver and Navigator roles can be switched regularly on a timer. I don't say should, because when teams deliver small chunks of work that can be reviewed in quick sessions, you may not need role switches. You should, as ever, fit your approach to what works for your context.
Traditional pairing
The Driver is on the keyboard.
The Driver generates test ideas.
The Navigator reviews and asks questions.
Strong-style pairing
The Driver is on the keyboard.
The Navigator generates test ideas.
The Navigator reviews and asks questions.
When in doubt, try strong-style pairing. In most cases that will give you more alert and productive sessions.
Practical example
Developer on Slack: "hey man :) want to look at my changes?"
Tester on Slack: (opens a call with the developer)
Developer on Zoom: "As you can see here, if you select service X and press Connect you go into a connection flow through Y."
Tester on Zoom: "What if I already connected X through Y?"
Developer on Zoom: "Then the Connect button should be disabled."
Tester on Zoom: "Should it not change to a Disconnect button?"
Developer on Zoom: "When no service is selected yet, we don't know which service to disconnect."
Tester on Zoom: "But when we select a service, could we not show a Disconnect button for that service?"
Developer on Zoom: "That's possible."
This potentially leads to a brief calling in of a Product Owner or UX specialist, and to further tests and learning. Just the short fictional exchange above might already have been several rounds of playing Jira ticket tennis, perhaps for several days, if it wasn't done through pair testing.