Dev/QA – The Unusual Pairing

Dev/QA – The Unusual Pairing

As soon as we hear the term “Quality” , we directly associate it to the Testers or the QA department and it is assumed that it is a their responsibility to maintain and assure quality of the product.

A decade ago, during the waterfall days, the above statement would have made absolute sense. However, in today’s era, where the industry is rapidly moving towards Agile and where testing activities are moving towards left, Quality can no longer just be associated to a particular role; instead it belongs to the TEAM. Quality is a team’s collective responsibility!

Quality Assurance ~ Testers Team.

As in Agile world, where the emphasis is given on Client’s early feedback, the same should be extended to agile development where the team provides early feedback during the implementation/development phase to improve the Quality of the product. By doing this, teams can prevent bugs getting introduced rather than finding and fixing them later in the phase, resulting in longer Quality feedback cycle. The objective should NOT be to kill the bugs quickly, but to avoid them altogether.

Although the Agile-Scrum team plans their sprint for the available capacity and are expected to achieve the planned sprint goals, it is often observed that the last few days before sprint’s closure are a hurry-scurry. The common major reason for this hustle, is finding and fixing bugs towards the end of the sprint. These last minute fixes require re-testing the user stories which introduces risk of something else slipping through the eyes.

Why does this happen when we have planned for all the risks?

We realized that the root cause was ‘Bugs‘,  finding-documenting-analyzing-fixing-re-testing the bug, completely use up our capacity. So, what can we do then? One of the things that we have tried successfully is ‘Dev-QA Pairing‘ and I am going to explain about how it works.

Elaborate process for Dev/QA pairing:

Clarification: Dev/QA pair together, get the flow clarified, get the triggers and post conditions clarified.

Analysis and intimation: QA share test cases with the developer before developer finishes coding. While the developer is coding, the QA identifies and analyzes the various possible scenarios which need to be handled. These are the foundations of test cases or sometimes also called “High Level test cases“. The QA can share this test cases with the developer so that he or she can take proactive measures to prevent bugs.

Demonstration:  Developer demo’s to QA. Once the story is code complete, Developer runs through all the acceptance criteria in the developer demo to QA’s and hands over the user story to QA .The act of preparing for the demo and giving it has certain advantages:

1. It usually helps the developers unearth some defects which they can quickly fix.

2. During the demo, the QA can ask questions and identify any issues / bugs and explain those to the developer in the conversation, hence cutting down on the time to document and report the bug.

In this process, more emphasis is given on preventing defects rather than finding and fixing them later in the life cycle.

Upside of Dev /QA pairing:

1. Prevention better than cure:  This approach helps to build software without defects in the first place.

2. Timely delivery: Quick turn around time. Multiple iteration of back and forth between developer and testers are reduced which helps team to deliver the product on time.

3.  Challenging and interesting: For both QA’s and Developers, pairing makes their job more challenging and interesting.

4. More automation: QA can spend more time doing automation.

5. Knowledge sharing: Reduces Bus factor . It helps in spreading the code understanding and allow more people in team to know the code/design.

6. Creativity and brainstorming: The opportunity to discuss about the story with a peer encourages creativity and healthy camaraderie between the Dev and the tester

7. Optimal testing and debugging: The tester now understands the internals better and the Dev understands the functionality and its boundaries better, so both of them are better equipped to test and debug any issues coming out of the story.

This approach is easy to follow and helps in sharing common understanding of a particular user story within the team. Any tester(manual/automation) can contribute early in a development process and become better able to test by pairing with the developer. I hope you will find this exciting and interesting approach. Try this to experience the benefits.

Please share your ideas and how you are implementing it to make agile testing more smarter, effective and efficient.

Happy Testing!!