Pair testing with developers: format, timebox, and why it works

A tester finds a bug and writes it up: ten minutes. A developer reads it, cannot reproduce it, writes a question: next day. The tester answers: day three. The developer reproduces it at last, fixes it, and the tester verifies: day four.

Now the same bug, found while the tester and the developer sit at one screen: the developer says "wait, do that again", opens the console, and sees the cause in ninety seconds.

That is pair testing. It is the cheapest collaboration practice in software, and most teams never try it because it sounds like it needs permission. It needs thirty minutes.

Short version

One tester + one developer, one screen, 30–45 minutes, one feature.
The tester drives; the developer watches with tools open.
Bugs get diagnosed at the moment they appear, not days later.
Run it just before a feature is "done" — that is the highest-value moment.
Still write tickets for what you find. Pairing replaces the back-and-forth, not the record.

What pair testing is

Pair testing is a timeboxed session where a tester and a developer test the same feature together at one screen (or one shared screen, remotely).

It is not a demo — the developer showing off the feature. It is not a handover meeting. It is live, exploratory testing with the two mindsets that never normally operate at the same moment:

The tester thinks: what would a user do, and what would break this?
The developer thinks: I know what is fragile in there, and I can see why that just happened.

Each one alone misses what the other sees. The tester does not know the code has a cache that expires at ten minutes. The developer does not think of pasting an emoji into the name field. Together, the coverage multiplies.

The 30-minute format

Before (5 minutes, async): the tester picks the target — usually a feature that is about to be called done — and writes a one-line charter:

Explore the new CSV export, focusing on filters and large projects.

Minutes 0–5 — setup. Developer opens the code and DevTools on one side. Tester has the app, logged in with a realistic account, on the other. Agree the charter out loud.

Minutes 5–25 — test. The tester drives, doing what they always do: real flows, odd inputs, fast clicks, back buttons. The tester narrates: "I'm applying a date filter, then clearing it."

The developer's job is restraint and observation:

Do not defend. "That's not how users would do it" is banned.
Do not grab the keyboard, except to inspect.
Say what you see: "That request just returned an empty array — interesting."
Volunteer the fragile spots: "Try it with a project over 500 tasks. I'm not sure about that path."

That last behaviour is the magic of the format. Developers know exactly where the bodies are buried. In a pairing session, they will tell you — because finding the bug together feels like winning, while a ticket three days later feels like losing.

Minutes 25–30 — capture. List what was found. Decide which items are bugs, which are questions, which the developer will just fix now. File tickets for everything not fixed on the spot.

Why it halves reproduction time

The expensive part of most bug reports is not finding the bug — it is transporting the context from one head to another. Steps, environment, data, timing: everything a written report tries to carry, imperfectly, across days.

In a pairing session the transport distance is zero. The developer watches the bug happen, with the console already open, on data they can inspect immediately. Questions that would take three ticket comments take four seconds of speech.

There is a second effect, quieter but larger: bugs found in pairing get fixed at a much higher rate. A ticket from a stranger is a chore; a bug you watched happen next to the person who found it is a puzzle you already started solving.

When to run it

Not constantly — pairing spends two people's time, so aim it where written handoffs are most expensive:

Moment	Why it pays
Feature about to be marked done	Cheapest moment to find edge-case gaps
A bug bounced twice as "cannot reproduce"	Zero-distance reproduction ends the ping-pong
A new tester joining the team	Fastest possible product and codebase tour
A risky area nobody fully understands	Two partial mental models beat one
After a big refactor	The developer knows exactly what to be nervous about

One session per feature, or a couple per sprint, is plenty. Teams that try to pair on everything burn out on it; teams that aim it at the list above keep doing it for years.

Remote pairing

Works nearly as well as in person, with three adjustments:

The tester shares their screen, not the developer. The person driving shares.
The developer keeps their own tools open locally — logs, code, the network tab of a second session against the same environment.
Capture as you go, because "can you send me that error?" is friction. If the tester reports findings through a tool like Crosscheck, each finding arrives with the screenshot, console, and network log already attached, and nothing gets lost between the call and the tracker.

Keep remote sessions at the short end — thirty minutes — since screen-share attention fades faster than side-by-side attention.

Still write the tickets

The one failure mode of pair testing: findings that live only in two people's memory of a good conversation. Then the developer fixes three of the five things, everyone forgets the other two, and one of them reaches production.

The rule is simple. Anything not fixed during the session gets a ticket before the session ends. The last five minutes exist for exactly this. Tickets from pairing can be short — the developer already has the context — but they must exist, because tickets are the team's memory and the fix's verification record.

Frequently asked questions

Is pair testing the same as pair programming? Same spirit, different activity. Pair programming is two people writing code. Pair testing is a tester and a developer exercising a running feature. Sessions are shorter and less frequent.

Does the developer's presence bias the testing? Slightly — testers self-censor small findings out loud. The fix is a norm stated at the start: everything gets said, even the trivial. It becomes natural after one or two sessions.

What if we find nothing? It happens, and it is genuinely good news about the feature — plus the developer watched twenty minutes of realistic use, which almost always produces a UX observation or two. A quiet session is not a wasted one.

Who should initiate the sessions? Whoever wants them — but putting a recurring 30-minute slot on the calendar for "pairing on whatever is about to ship" removes the per-session negotiation, which is what usually kills the habit.

Does this replace normal QA? No. It is one high-bandwidth tool in the mix. Regression suites, exploratory sessions, and written bug reports all continue; pairing removes the slowest conversations from the loop.