Pairing with Developers
We are working very hard to complete shipping CS5. As a result one of my developers who I worked with on the agile project, the one I paired with the most this cycle, who lives on an Island in the Puget Sound missed the last shuttle and needed a ride home. I dropped him off at the ferry dock and despite being swamped I was finally able to ask him what he found most useful about pairing. I was thrilled to hear that we both agreed on what it was.
From his perspective, the test scenarios I would bring up during the code walk throughs would help prevent bugs. This meant that since he was heads down in the code, when he was showing it to me I could ask questions before the tests were run or written. I know that many agile teams are using TDD, but you can use direct pairing in some cases as an intermediate step! It is pretty exciting to figure out that this is most of what we were doing that we both valued.
The other main advantage was finding problems in the code. When he would explain what the code was doing, it meant he was reviewing his own code later. He found mistakes almost every time we paired. This made his code better by the time it was ever reviewed by a non-tester. We only paired a few hours a week usually, so not a huge amount of time.
If you want to start pairing, ask your developer to walk you through their latest code. Just explain it to you. You might be surprised how useful it is. Then again, if you have been doing TDD all along, perhaps this is useless, but it was pretty great for us. It also helped me to come up with tests on the whiteboard. Oh, and I learned new things that helped my Python scripting as well. I've reviewed some bug fixes in Java and also in Action Script 3.0 (using Flex). I don't write code in either, but if you start looking at it, you can add some scenarios to your testing.
This does not replace other testing, but is great to add to what you are already doing.
From his perspective, the test scenarios I would bring up during the code walk throughs would help prevent bugs. This meant that since he was heads down in the code, when he was showing it to me I could ask questions before the tests were run or written. I know that many agile teams are using TDD, but you can use direct pairing in some cases as an intermediate step! It is pretty exciting to figure out that this is most of what we were doing that we both valued.
The other main advantage was finding problems in the code. When he would explain what the code was doing, it meant he was reviewing his own code later. He found mistakes almost every time we paired. This made his code better by the time it was ever reviewed by a non-tester. We only paired a few hours a week usually, so not a huge amount of time.
If you want to start pairing, ask your developer to walk you through their latest code. Just explain it to you. You might be surprised how useful it is. Then again, if you have been doing TDD all along, perhaps this is useless, but it was pretty great for us. It also helped me to come up with tests on the whiteboard. Oh, and I learned new things that helped my Python scripting as well. I've reviewed some bug fixes in Java and also in Action Script 3.0 (using Flex). I don't write code in either, but if you start looking at it, you can add some scenarios to your testing.
This does not replace other testing, but is great to add to what you are already doing.
Posted by Testy Redhead at 21 Apr 2010 
Categories: real life adventures, testing, automation, agile, test methodology
Categories: real life adventures, testing, automation, agile, test methodology
Great article. One thing I started doing in the past few years is watching developers code checkins. This has made me more aware of what is going into the product I am testing, and has helped me develop some interesting test along the way as well. I am lucky that the developers I am working with will take the time to explain what the checkin is doing if I don't quite get the gist of it.
Reply to this
Thanks! After awhile you might also try, if your developer is willing, to walk them through your most complicated test automation cases and see if they have suggestions. We found one technique I didn't know about that sped up the test over 1000 times faster! Coolest advantage that wasn't direct to the product.
Reply to this
Hi Lanette,
In my work place, we do not follow any of the process - TDD - agile. I learnt one lesson from the RST workshop: Customer would not care which process we follow and would be more interested in the final value he gets.
So, I always work closely with programmers. I have not paired with them but then just asked few questions now and then. Building the trust that you as a tester are not finding their mistakes but working towards a common goal of making the customer happy helps.
The interaction with programmers (mostly informal) has always helped me. The latest addition is www.typewith.me (Jon Bach pointed this tool in Weekend Testing session 32 over last weekend).
Happy to know that the programmer understood the importance of pairing and finally, its a win-win situation.
Reply to this
Hi Ajay,
"Customer would not care which process we follow and would be more interested in the final value he gets."
That is quite profound. Thanks for sharing it. I will try my best to keep that in mind!
I have been blessed to work with the team I had during CS5. I sure will miss them.
Lanette
Reply to this
I've always found that conversations with developers about test cases and functionality to be very helpful. Not only do they take some time to think about quality and how you will be checking for it, but you get a chance to see how they think. I wish there was time for it more often, because it is a very valuable practice.
Reply to this
I found it really useful to ask what was the most difficult part of the code for them to create. Then I'd explain that code to THEM to make sure I understood why it was so difficult for them. For example, live time tracking (time ticking down) is quite difficult partly because it is a performance tradeoff depending on how you design it. So knowing that accuracy vs performance was the consideration I can look for lag as well as any second it could be wrong or fail to update and come up with more scenarios to interrupt.
Reply to this
I'm going to subscribe to this blog because it's very interesting
Reply to this
All people deserve very good life and loan or just small business loan will make it better. Because people's freedom bases on money.
Reply to this
Great ideas. But the problem could be that there just isn't enough trust between the developer and tester. Maybe it would make sense to build pairing into the process.
Reply to this