We hired a new QA manager a few weeks ago. He’s a nice guy named Eric and he sits in the cubicle next to mine.
As I was heading out the door the other day he stopped to ask my opinion on a testing approach for a large project his team will begin testing in December. The idea he described is essentially pair testing, along the lines of pair programming, and he mentioned it was a combination of something he did at a previous job and something suggested by our Director of Development, who used to work with Scrum.
Since the project consists of a bunch of applications working together in one ecosystem, it’s going to take a lot of time to run tests on it, and a comparable amount of time just to figure out if the tests are succeeding or failing. The idea is to cut down on QA troubleshooting and data-churning time by having a developer and a tester sit at the same computer and run through tests together.
I’ve read a lot about pair programming but have only done it a handful of times. The concept of pair testing is intriguing because I know how much time our testers spend working on non-testing issues that a developer could likely clear up if they were sitting at the same desk, and I know our code will be more thoroughly tested because of it. That being said, I’m the development lead on the project and I can’t spare a developer for even a few hours right now due to the massive amount of work to do between now and D-day.
It’s quite the conundrum.
The end result: I plan to support the approach on a limited basis until we can measure the benefits and sacrifices that both teams forego to make it work. Obviously we have to get the software written before they can test it, so it will do us no good to pull a developer from a half-finished application to sit with the QA team. But assuming we can eek out the time, something in my gut tells me this is the best way to thoroughly test this beast.
Have you heard of or participated in pair testing? What’s your opinion on whether or not it will benefit both teams (development and QA)?