Three of a Perfect Pair: a #30DaysOfTesting Testability #T9y Entry

Goofy wordplay aside, I had a strong appreciation for the Mark 2 version of King Crimson, of which this title was the last iteration (Discipline was my favorite album from this lineup. Yes, I'm sure you are totally thrilled to know about that ;) ).

OK, less prattle, more "30 Days of Testability".

Pair with a developer to see if they can improve something that you find difficult or time consuming to test. We have a handy guide from Lisa Crispin on Pairing with Developers: AGuide for Testers that’s worth a read. 

I'm fortunate in that I have developers that are willing to pair and look at stuff with me. As we have G-Suite as our main communication platform among the team, it's easy to demo stuff and talk out what is being tested. We are a small team and technically speaking, with management out of the equation, our engineering team is equally balanced between programmers and testers. Thus it's not an imposition or overly burdensome to get together and pair with developers.

Lisa article is a great resource and while I have little to add to it specifically, I can share a few things that I have found help considerably with pairing with developers.

1. Have a specific goal for the session: By developing a very specific charter around an area that is either difficult to test or that may require more knowledge that the developer has, being super specific really helps with this process. Often when I approach and have a question that has very clear parameters (or as clear as I can make them) I'm much more likely to be able to block out time with them. More times than not, we range farther than that specific area because we're into it and we're both able to get more done together than separately (yeah, happens a lot :) ).

2. Block out a specific time interval: set an appointment, set the desired time (about an hour is my usual suggestion, no more than two). We frequently blow past the single hour time set aside but we're usually good about heeding the two-hour limit. Beyond two hours we tend to lose focus but up to that point is usually very effective.

3. Do your homework in advance: This goes with number 1, but if I'm going to try to understand something that's going on in the code, it helps for me to have reviewed it first (if possible). Greenfield development efforts don't always allow for that but since our current efforts are mostly focused on revamping existing functionality, there's plenty of opportunities for me to read up and understand the parameters the developers are working with. I may not understand all of it (frequently I don't) but at least I am ready to start sessions with a list of questions.