Pair Testing

27Nov

I was reading Sharon’spost on Test Pairing (run by Karen N Johnson at STANZ 2009) and I automatically made the connection with Pair Testing. They aren’t the same and in talking with Karen at STANZ I mentioned my assumption to Karen which in turn reminded me of a time in which I was involved in pair testing a public Government website.

The great thing was that we had management support. Without it, It would’ve been easy to suggest that its a waste of time having two testers assigned to the same piece of work.

Huh? Two testers, same work? What’s that all about?

Pair testing isn’t new and in fact it has more well known cousin in Pair programming. What it does well is that it allows for two different sets of eyes testing the product. Essentially one is the *driver* and drives the keyboard whilst the other is the *observer* or *navigator* (I prefer navigator – its name suggests a more hands on role.) The navigator is there to suggest ideas, learn, be mentored, mentor, record, find information etc. These roles are of course, interchangable, and allows for a very shared, creative testing activity (of course there are challenges as there are in any approach but we won’t discuss them here.)

As we were testing, we interchanged a number of times and discussed and discovered a number of bugs. This is one of the benefits of pair testing in that brain can be engaged on task longer and is a lot fresher because of the role swapping, different perspectives and the exchange of ideas they will come flowing.

I’ve been involed with pair testing and it works. I have also seen it in action and its an approach that we should consider more often!