Q: What other testing activities have you done besides pair testing?
A: Well, we also did something I named parallel testing, which involves less teamwork but can be just as engaging as pair testing. I’ll try to explain what this means using a similar analogy I used for pair testing. I compared pair testing to a car ride, where one tester is the driver, while the other is a passenger in the same car. Parallel testing is similar, with both testers being drivers (both with their own keyboard/computer), in slightly different cars (this can vary between using different browsers/OSs/computer configurations), driving parallel to each other (testing the same piece of software/section of application), with a communication link between them (both testers are within earshot of each other – in same office or room).
One aspect of this method is that each person tests the same section or even features that overlap with one other. This makes it possible to test things in more detail, knowing that there is another person that is doing tests on the same piece of software.
Instant feedback is another aspect to consider. A different tester is basically testing the same part of an application you are, so when you would normally ask someone to help test something the entire introduction to what you are doing can be skipped. Of course there are some cases where you just end up diverting their attention to something less significant you want them to try out and they might miss something important…
Googling parallel testing turned up finds pointing to a different procedure than what I was referring to, (testing an old version of software in parallel with a new version, checking for inconsistencies between the two), so the name might not be the most appropriate, but it will have to work until someone suggests a better one. 🙂
Parallel testing is effective. Strange, but asking total dummies to test software also gave some good results – because they actually think the way common users think.