Pair with a developer on a feature

There are several different pair programming techniques to try out. Ping-pong pairing is popular: Person A writes a test, Person B writes the code to make that test pass, then writes another test, Person A makes that test pass, and so on.

Also I’ve found strong-style pairing, where you switch roles between driver and navigator, most effective. 

For my pairing session,I chose strong-style pairing and the developer and I picked up a userstory ticket.

We started with a brief intro about user story to provide some of the context behind the feature’s design and I ask the developer to explain his code logic to me. This way, I am able to spot bugs – by following his thought process. It works well for both of us.

Then I followed developer’s instructions and type when I’m the driver. When it’s my turn to be navigator, I have ideas for tests and for what code to write.

By the end of the pairing session we delivered the initial functionality, identified some bugs as we tested the code and we wrote some functional tests via BDD.

My learnings from the pairing session:

• It works great and I find it very fun, interesting and valuable. The tricky part is to get the developer to talk about what he is doing so that I can follow the thought process and find potential bugs in the thought process. 
• Pairing with developer helps me to understand how the application works under the hood, this way helps my creativity in creating test cases, and also helps the developer not have some doubtful logic in the code, or add some extra try catches scenarios that will come up with.
• We testers spend much less time in pre-release testing, so we have more time to devote to exploratory testing at the feature level. Yes, some issues still get caught at the last minute, and occasionally even make it into production. ;)
• However, I think the tester must have at least a beginner level knowledge of the code. This way he understands what is being done, not only by listening to DEV, but reading the code also.

Pairing across roles builds on this shared understanding of the story you’re coding and/or testing, and helps you provide the desired value for customers and end users. As a tester, you are likely to take more of a big picture view, see how the story relates to the rest of the system, and think about how customers will use the feature. Your coder pair is probably focused on the area of the code where you are working and how it can be made more robust. These diverse viewpoints help create a better feature and if you disagree on the desired code behaviour, grab a product owner (PO), designer or other customer proxy and talk about the business rules and examples of desired and undesired behaviour. This saves a lot of time when compared with delivering a story and having it rejected because it wasn’t what the customers wanted.

What did you like about pairing session? Should we testers do this more often?

#QA #30daysoftesting #Devops