Here are some of my thoughts in the form of questions and answers, which mostly come from feedback I gave Alex and Oana on exploratory testing when I first started out as a tester, and although much has changed since, I still have a lot to learn in order to become better at my craft… Enjoy! 😀
Q: So… pair testing; comparing the experience to testing alone, what are the things you did differently when testing with someone else?
A: Pair testing? Err… don’t you mean peer testing? Hm…
*thought about this for a while, then googled a bunch of stuff regarding peer/pair testing*
Okay, let me try to explain why naming it peer testing makes sense to me: if someone is your peer that means the person is of the same level as you (viewed as your equal, if you will). So if two peers sit down together to test a piece of software, there is no hierarchical difference between them, one tester does not simply oversee the other tester’s progress, both testers are interchangeable. I’m not saying pair testing implies inequality between the two participants, but it does not exclude that possibility either (one could be a developer or a business analyst – according to the Wikipedia page on Pair testing, anyway). I also did a Google search on peer testing, turns out it’s also used in the way I’ve used it, but pair testing is more widespread, so I guess for the sake of familiarity, I’ll change the name.
Regardless of how you call it, one thing is certain: there are far more questions raised by two people looking at the same piece of software than going at it alone. Instead of sitting in front of a monitor and wondering what this feature does, you engage in conversation. The testing partners enter a kind of dialogue in which the third participant is the application itself.
Another thing is you bounce ideas off each other about how a user might act in a certain situation or what might be considered a bug in what situation. There are also occasions where you just look at each other perplexed and wonder what had just happened and how you could make the application do that again.
The way I see it, the person sitting at the keyboard focuses on the task (or scenario) while their partner takes notes and can look at the overall changes happening in the application. It’s kind of like driving a car really, the driver, as in the person at the keyboard, focuses on the road ahead, and is basically in control of what the application is doing, and sure there are times when the person next to them tells them what to do or where to go, but backseat driving is never popular. 😛
Meanwhile the passenger can look around freely, without any focus in particular. They can look at different things that happen throughout the application, not just what the “driver” is looking at. This is where most of my ideas for possible tests came from. When you are focusing on one thing happening (or waiting for some particular thing to happen), you can’t see all the possibilities for bugs just waiting to happen. Of course some of the ideas are a little far-fetched, and wouldn’t necessarily discover bugs in most situations.
Peer/Pair testing isn’t restricted to exploratory testing, is it?
Hm, I wouldn’t say that it’s restricted to exploratory testing. I mean I could actually see the benefits of writing scripts or test ideas/cases together with a partner, then execute them, but I think that ultimately pair testing offers less value to those who run scripted tests than to those who go for a more exploratory approach.
I would actually go so far as to say that in order to really benefit from testing with a partner, the tests need to be more free-form, (they require more wiggle room if you will 😛 ) and scripted testing might not offer as much flexibility as exploratory testing would.