Paired programming brings two developers together to produce higher quality code compared to those same two engineers coding separately. Just as paired programming has someone writing code while another person reviews the code as it is being written, paired testing has someone doing the testing while another person takes notes, asks questions, and spots/reports bugs. I’ve personally found paired testing to foster creativity, maintain focus, provide a new way to teach others, and help release better software in general. Two testers are better than one.
Pick a partner!
It’s probably important to note that not all people actually like to pair up. Let’s face it, many of us work in a world of introverts. Some people just don’t like to talk, or share their personal space. That said, there are a few good pairings you can look at:
Tester and Tester This could be a senior tester and a junior tester, or simply another tester not familiar with a feature to help build domain expertise. I like to let the more junior testers drive the session — give them control of the keyboard, while the more senior tester records and observes. This is a great opportunity for a new person not familiar with a feature to learn, as well as gain empowerment to guide a test. The senior tester can help guide the newbie with “What if” questions, but my favorite thing is seeing a new person light up with, Oh did you see that? I wonder if that’s supposed to happen! (Usually, it’s not — but that’s also why it’s useful to have a Subject Matter Expert on hand to respond and prevent unnecessary bugs from being entered!)
Tester and Developer This is my favorite way to test. I like to let the engineer drive, while I help guide with a charter (or a goal of what we want to accomplish). If I think the engineer missed something, I like to lead with, “What do you think will happen if we…”, and then dive into that area. The last few times I have done this, the engineer I have partnered up with has said, “Wow I didn’t even think to look there!” (or something to that effect). We’ve found some pretty good bugs this way, yet prevented them from being found way too late in the game,which we all know gets expensive.
By pairing a tester with a developer, you bring together two very different skill sets that help foster even more creativity and different ways to test. The biggest benefit to me is that developers start to cultivate some of those skills that testers have, and they ultimately start to think about what will be tested before they even code something, or — BONUS — they find more tests they can add!
You can also pair up when automating tests - similar to concepts in paired programming, two heads are usually better than one. From test creation to execution, having a partner in test has several advantages (especially if you have someone new on your hands!) - ensuring feature coverage, higher quality test scripts, mastering the art of debugging those failing tests, and stabilizing your tests.
Tester and Designer ...or a developer and a designer. Basically, instead of a designer going in and performing an audit by themselves, have the designer pair up with someone to walk through and really test. Similar to a developer learning QA, a designer begins to understand what makes a feature testable, incorporating that into design and acceptance criteria — and that leads to better software.
Tester and Client This idea is not new. In fact, before we even really started doing this with our QA group, we were inadvertently working with an even better partner: our clients. We used to conduct usability testing, which our client would drive. The facilitator/observer/recorder (me) would provide a goal, and then observe and record what it would take for the client to achieve that goal (or if they could at all). We’d also take video and review facial reactions or murmurs. We would record how long it took to achieve something, or if they had to look all over the screen to figure it out. These are perhaps the most telling tests of how easy a product is to use.
Get Started!
However you pair up with someone, the concepts are the same — Someone drives the testing at the screen while the other person observes and records. I can’t say what a difference a partner makes in my testing. I just flat-out enjoy it more. Sometimes we both still test, but on different devices while trying to accomplish the same thing. Sometimes we both contribute to the bug report. (Am I the only tester that actually hates filling those out?) In general, it’s a new way to test in an environment that can become stale … or maybe I’m slowly becoming less introverted.
Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
