Pairing: Tester and Other Team Members
A few times over the years, I’ve had the chance to pair with other members on the team to test together. The effectiveness of those sessions seems to vary dramatically based on the person’s role as well as their understanding and interest in testing.
On more than one occasion, I’ve paired briefly with a project manager (PM) who wants to know more about testing, more about the product, or at least more about what remains to be done from the testing team. When I’ve tested with PMs, the time needed to test seems to become clearer to them, which in turn improves our communications and helps us better forecast time expectations. I’ve also found that PMs seem to better realize the technical skills needed of a tester. If I can help a PM deepen his or her understanding of testing, there can be subtle improvements in our ability to work together. These sessions are far more likely to happen when I offer them in a way that’s appealing, such as: “Hey, would you like to watch and listen while I retest a few defects or while I spend my first session with this new feature?”
Database administrators (DBA) are other team members inclined to pair with me especially for isolated sessions focused on data model discrepancies or other pinpointed issues in which they may have a particular interest. I’ve learned plenty from the DBAs and system architects I’ve met over the years. Sometimes in our short sessions together, we can better determine a defect priority as we discuss the two perennial factors: likelihood and impact. It can helpful to gain another point of view for the product, the risks, and the defects.
By offering to test with another team member and having a specific test purpose offered, I can often get different team members willing to sit in on a test session with me. I’m not always sure what the outcome will be, but I know I’ve made myself accessible, my testing less mysterious, and heard someone else’s perspective about at least one area of a program.