Voice pair testing

I want to define voice pairing applied to testing as following: two (or more actually) testers sits in front of their computer and test independently. They have the same goal (e.g. chuck of software to be tested) and aim to testing with the same goal simultaneously. But they only exchange with observations (this works, but this doesn’t work for me). They are not allowed to see each other screens. They challenge (review and clarify) each other observations – that’ the only collaboration allowed.
It best applies to session based exploratory testing SBTM, but actually I first used it while helping another tester to hunt-down not repeatable bugs. Didn’t you? It goes like this:
A peer tester (PT): I have a not-repeatable bug
Me: exciting, I would love to help you get it repeatable, tell me what you know about it so far.
PT: … tells me in what situations it seems to happen
Me: testing… testing… of I think I know how to repeat it. You have to …bla-bla
PT: … no, just did as you said – everything is fine
… and so on

Details
I don’t know if the pair-testing roots in pair programming, there are at least 3 types of pair-programming: side-by-side in front of a screen; in front of two screens with two keyboards and screen pairing one person in front of another.
The same could be applied to testing, but I know at least one more type for testing. I would call it Skype pairing or voice pairing for open office. It may sound silly, but testing differs from development: if developers wrote two different pieces of code that does the same thing – it makes little sense. If two testers did the same test in a different ways – that does makes sense. Looking at a computer for other tester’s actions may cause inattention blindness for alternative ways to do the same test.
Benefits
I see two at the moment: competitive motivation and bug quality. By competition I means that you want to find the bug before the other tester does; quality of a bug: you need to prove that this bug is a bug to the other tester who will help you to remove assumptions/ambiguity trying to repeat it from your instructions (remember - the other tester hasn’t seen the bug on your screen).
Drawbacks or how to justify double work?
Let’s take the managers position for a moment. If we compare pair testing to one tester testing, we have twice as much time spent testing the same thing. That sounds like 200% resource usage. You could cost by half without pair testing, can’t you? Well, first of all each defect reporting takes time and each bug is reported once only.
If we are talking about SBTM with a manager I would use Jonathan Bach data that says that only 28% of testers’ time goes to testing. If it is pair testing it is only 28% additional resources and you get the benefits I described above, including saved developer’s time on reading poorly described bugs.
Now if we forget about mangers, it is still an issue – we do really waste some time doing the same things twice. It sometimes pays back, but not always. So probably you want to have only a part of your testing done paired.

P.S. I consider to move blog to softwareclub. I have my blog on testingreflections now, but I may move here.

0 members like this

Next Post >

Add a Comment

You need to be a member of Software Testing Club - An Online Software Testing Community to add comments!

Join Software Testing Club - An Online Software Testing Community

Comment by Yuri Tarasov on November 19, 2009 at 16:51: It could be interesting to combine SBTM and Voice Pairing on the stage of session ideas generating and planning of testing strategy for thier executing.
Also Voice collaboration in time of session is good too for clarification any details and apeared ideas discussing.
And, of course it is very appropriate in the debriefing stage.

Thank you for you article!
We'll try this in our nearest projects and we'll see the result.

Comment by Ainars Galvans on December 15, 2008 at 12:17: Anna, you are right, I don’t think this type of testing should be the only one carried out in a project. I don’t think any approach is enough alone.
Actually the SBTM combined with voice-pairing is not my idea. Oleg is a passionate tester in my team who just tried it over skype. There are a few more details in his practice that I skipped in this blog. I want him to polish his practice before describing it in details.
What I wanted to say: voice-pairing isn’t something new to me (just as for you, Anna). Let’s use it! Let’s improve how we use it. Let’s build a formal process around it for management buy-in.

Comment by Anna Baik on December 13, 2008 at 23:02: Hmm. A former colleague and I fell into this way of working when we had a project where our normal approach of scripting tests first hadn't really worked: as we were on different sides of the country, we didn't have sight of each other's screens unless we wanted to kick off a Netmeeting session. So we mostly communicated via IM fairly constantly throughout the day, switching to phone where it got a bit too complicated to explain via IM. We didn't always cover the same areas (in fact usually not), but when seeing "something weird" we'd usually IM the other to ask "have you seen this happen?" and work together on it for a while. That sounds similar to what you describe above, but it wasn't at all planned as an approach, it just grew out of the way we normally worked (as we didn't work in the same city/office, we needed to generally put a bit more effort into making sure we kept in touch regularly).

We didn't have to justify it to a manager because our test manager was perfectly happy to accept that we were being as productive as possible, and really, given the project, we had little enough knowledge that we really needed to share every snippet that we found anyway.

I think it worked pretty well in those circumstances, but I'm not sure it would feel natural in my current workplace - I think it'd be hard to stop myself just wandering over to take a look before I remembered I wasn't supposed to!

Maybe it would work best on areas where the system is very complex, or you have very little information about functioning? If you do only part of your testing paired, how do you choose which areas to pair on?

Comment by phil kirkham on December 13, 2008 at 16:00: interesting post - not something I've ever tried

( PS We'd be real happy to have your blog over here ! )