Thursday, October 9, 2008

Pairing is Not Just Programming

At work, we spend a lot of time pairing. No code gets checked in to the source tree without a pair or a reviewer, and there's a definite bias toward pairing. Now, most of the time you hear about pairing, it's shorthand for pair programming. So how does pairing help a test organization? Just the programming we do?

No way. You can pair in a lot of ways.
  • Pair testing. We do this a lot. Think exploratory testing, only with two heads instead of one.
  • Pair programming. Yes, we do this. Not so much for quick scripts, but in particular for test harness modifications and additions.
  • Pair issue analysis. This we do with support quite often when they have a problem they can't solve. Sure, we can take the logs and the problem description and get back to them with a notice that a hard drive failed or something. Or we can pair with a support person and that person can learn exactly how we figured out a drive failed.
Pairing is something I really enjoy having my team do. It increases our productivity and focus (it's a lot harder to waste half an hour on your newsreader when someone's sitting there working with you). It helps alleviate the transience of institutional memory. It increases confidence that the work is well-done; issues have fewer leaps of faith if someone has had to explain each step to someone else, and designs are stronger when two people are looking at them.

All in all, I'm a big fan of pairing for a lot of test work. Pairing isn't just for dev!

No comments:

Post a Comment