Although I am no longer the newest recruit on my employer’s Quality team, I am still something of an alien creature to the folks back at the mothership (i.e. home office). However, I have been slowly getting to know them through video conferencing, especially my fellow Quality team members. We have been experimenting with paired exploratory testing, but in my case we cranked it up a notch to *remote* paired exploratory testing. (You know testers don’t like to keep it simple, right?) This added an interesting layer of exploration to an already exploratory experience. (This meta goes out to you, Jace and Will S.) Now, each member of the team has a Skype account, establishing a common medium for communication, and we are learning the basics together. While we contended with screen repaint, we were forced to discuss the products more in depth to make use of the lag time and to give some context for each newly displayed page. This also gave us a chance to discuss the testing process, the collaborative online Quality space, our documentation strategy, and a bit of product history. Oh yeah, and we did some testing.

Since I’m still a newbie, I pretty much expect to feel a bit lost in the woods when it comes to the rest of the company’s product suite. Paired exploratory testing (or ET for the testing aficianados among you) gave me a peek into the Daxko-verse. My fellow testers know the lay of the land and so are better positioned to provide test ideas inspired by the suite’s world as we know it – soon to be rocked by my team’s product! In return, I got to ask the naive questions about what we were looking at, what terminology meant, and how it all fits together. Sometimes, having a second set of eyes isn’t enough. You need someone to ask the dumb questions. Stand back, people, I am a professional at this.

Paired ET fosters the Agile Principles:
1. Continuous Feedback
2. Direct Communication
3. Simplicity
4. Responding to Change
5. Enjoyment

We are still working out how to run the sessions. Does the person on the product team pilot or co-pilot the session? Or do we take this rare opportunity to do some concurrent exploratory testing? How long do we test together? Do we test both products back-to-back or does that just leave us yearning for caffeine and a stretch break? Personally, I am loving this. It’s so much fun to play with the new and novel, and I hope that this livens up the regression routine for my home office folks. If nothing else, it is a great opportunity to geek out about testing methodology and learn a bit about what works in our context.

The best parts:
•Finding bugs!
•Communication
•Knowledge sharing

Can’t wait to get into it again this afternoon.

Addendum: Now that we have completed the initial experiment in the vacuum of ignorance, I am free to research other approaches to paired exploratory testing. I paid particular attention to Agile testing as a new mindset that encourages transferring testing skills to other team members so that the whole team shares responsibility for testing.

Lisa Crispin wrote about paired programming and TDD back in February. As the only tester attending CodeRetreat Boulder, she had many experiences pairing directly with programmers using a variety of languages and time-boxed pairing sessions angled toward producing learning rather than code, since anything the pair produced was deleted as soon as the pairing session completed. She described the experience as developing an appreciation for experimentation.

Jonathan Kohl also describes pairing with developers, first leading the way and then jointly participating. He mentions the benefits of different perspectives on the software that derive from the roles of the team members. Working together, the pair identified the source of problems quickly and produced a high level of confidence in the end product. He includes automation as a familiar area of collaboration with developers. Active participation is not limited to “driving” the session but can also include thinking aloud about the motivation of the test execution.

Janet Gregory elaborates on Brian Marick’s quality quadrants [pdf] to advocate for collaboration among the customer, developer, and tester to benefit external quality through executable examples. Testing with the customer may be directed toward usability, including understanding the personas of the end users. She suggests that this has value even for unfinished code.

Brian Marick’s youDevise Lightning Talk explores debating with developers who, rather than letting the context drive their actions, decided to change the context: altering the code to make it more testable. “When there’s something interfering with their [development] work, instead of accepting it they change it and they are generally too naive to accept the fact that some things are impossible.” In this case, debate was a form of pairing.

Cem Kaner and James Bach have discussed collaboration between team members with the same role: testers. [pdf] Tester pairs experienced high productivity and high creativity in their product analysis. “Testing is an idea generation activity rather than a plan implementation activity.” They also used pairing as an effective training technique. In support of both learning and exploration, the “driver” for the session is not necessarily stable but may swap between the testers, though it often falls to the less experienced member of the pair. Concurrency testing is an easy extension of the paired mission. In addition, the pairing requires communication, forcing testers to articulate test ideas. Immediate review produces better reports of testing results. Working together on a creative exercise is just more fun. Although the pair works as partners, one of the testers takes on accountability for getting the task done, balancing lateral thinking with the session charter. Coaching can help to smooth the transition to this new work style and any interpersonal issues that arise. Managing testers is like managing executives, not factory workers, so give them a longer leash according to their experience.

James Bach revisits paired testing in a recent blog post, only this time his partner is a non-tester (specifically his teenage son). Video documentation helps them to focus on testing rather than documentation, although the senior tester did make notes and develop a compelling testing story. Observing, remembering, and building a mental model are helpful for the survey session: learning the product, characterizing risks, testing challenges.

Image source