Pairing with Developers a Testers viewpoint

The common thought about a Tester and Developer is that they'll have arguments and see each other as adversaries but that’s a classic myth.

While working as a tester there will be times you talk to the developers. Here are some experiences from interactions with developers

1. The Demystifier: The project was set-up such that a single QA was working at off-shore and development team was on shore. The primary task of the QA was to do automation. The project was a simple website with typical navigations using bread-crumbs, search pages etc. The automation was done considering these scenarios and did not have to deal with anything complex.

After few weeks the team decided to implement authentication. The authentication was simple username/password but along with it they introduced “captcha” for better security. Since the current automation framework was designed considering no authentication it had to be modified to incorporate the new flow. The challenge was to how to get past the captcha. These was the time when the practice of having feature toggle was very prevalent. So to figure out a solution the tech lead and QA started exploring solutions. Their conversation started by understanding how captcha works and gradually the entire application architecture was discussed. This demystified the entire app for the QA. With this understanding the automation framework was modified to call an api which generates the captcha and use the same for authenticating on Test environment in the process the QA’s also started deploying the app to local environment and set-up the data accordingly.

This kind of interactions with the developers helps a QA understand the application better:

• They understand the underlying technology to tweak it if needed while automation
• Understands the integration points and helps in defining the automated testing strategy considering dependencies from third-party api’s
• Gives confidence to QA’s in debugging and setting up the automation environment.

2. The Teacher:  This experience is from multiple projects in which the team had to deliver an End-to-End automation for a fairly complicated systems like train ticketing, large retail etc. The typical structure of these teams was equal proportion of QA’s and developers since a lot of under the hood apis were being used to develop the entire automation framework. The QA’s were pretty confident with their programming skills but it was mainly from the experience of writing automation frameworks which meant it was primarily extracting methods and reuse them along with some bits of inheritance.

Our organization followed pair programming which meant that QA’s paired with developers almost daily. These daily interactions were very fruitful as during the pairing sessions there were extensive discussions about different Object oriented concepts helping the QA’s cement their programming language. Gradually the QA’s started learning lessons on how to write a production ready code even within an automation framework. QA’s became more confident with terms like refactoring, splitting classes, methods, single responsibility etc.

Also the small things like using IDE effectively, debugging and various practices of developers were learnt. Now the QA’s were more confident around their coding skills.

Its important for QA’s to be confident around writing code if they want to get into automation and this kind of active pairing with developers works wonders given the things mentioned above are learned/observed. The production quality of automated tests help them in scaling and maintaining the suite in the long run.

3. The Tester: Similar to above experience this is from multiple projects where the QA’s were doing automated as well as manual testing. Our organization pushes for Test driven development which means that developers will also write tests which were mainly unit tests, integration tests, Jasmine(java script) tests and View(UI) tests. To understand what is being tested in above mentioned tests the team started a practise of “Test walkthroughs”. The walkthroughs essentially mean that the developers and QA’s will sit together and look at all the tests written above. The discussions during these walkthroughs were mostly:

• Automation of various scenarios for a given story/functionality
• Coverage done by these tests
• Data that can be used

During this discussions the QA’s were able to capture various data sets that can be used for testing. Also the developers would explain how can few scenarios which need particular data/configurations can be tested, security aspect of the feature. Sometimes the developers would themselves suggest tests which might create problems based on their understanding.

When developers start thinking of more scenarios for testing means the team is going in right direction with quality of the product. It also helps mitigating defects being caught later and pushing the release dates. Also an another set of mind looking at the feature helps in coming up with better scenarios.

So keep pairing with developers and you will always learn something new and help teams maintain good quality and collaboration.