Devs and QA :A Different Way To Work

by Niroshan Madampitige , Roshan Amadoru & Eranga Jayalatharachchi

At Vetstoria, we always experiment with new ways of working so that we can optimize our processes and team dynamics to have the best engineering team a software company could have. In this instance, we wanted to find an optimized way of collaboration while cutting down the process steps and improving the speed. When we did a deep dive into the processes and the way we work. Among quite a few improvements, we saw one area that would surely help us to improve the collaboration, speed, and quality. In this article, we talk about one practice that has helped us to improve massively in the past few weeks!

The Experiment

At the beginning of December 2020, the platform engineering team started an experiment on pairing up software engineers with quality engineers. Our ultimate goal is to implement “Pair Programming” and this is step one towards it.

Earlier, we had quality engineers and developers working in their specific domain — This worked, yet, we saw a big room for improvement — We wanted to avoid back and forth revisions between Devs and QEs. While we were trying to develop a cross-functional team, we decided to start with pairing developers and testers.

Goals and Objectives

As mentioned earlier, our ultimate goal is to adopt pair programming and then move into mob programming to increase collaboration and focus. As a starting point, we paired the developers and Quality Engineers. Our initial goals are as follows:

• Improve the delivery process and throughput by eliminating additional steps such as “Dev Testing” and “Code Review” -
• Reduce the number of defects found during the development life cycle — This practice also reduced the need for raising bugs as the Devs and QA were working together
• Collective ownership of work
• Encourage knowledge & skills transfer between the engineers from the two disciplines

Execution

In order to achieve the goals and have a structured approach to the experiment, we came up with 2 simple guidelines.

Organization

Each pair is recognized as an atomic sub-unit in the sprint team.

Responsibility

Each pair is responsible for delivering complete work units to be part of the respective release. The pair should pick-up the Jira ticket together, work on all the relevant aspects of it and publish it as complete work to the release.

The pair worked as a unit on all the aspects of the development work. Some of those aspects were;

• Working with the respective product leads to understand requirements, raise clarifications and design the solution
• Presenting the solution to the other engineers and addressing their feedback
• Identifying test scenarios and writing down test steps
• Coding
• Testing on development and staging environments
• Stamping the “Quality Verified” label on the Jira tickets

Reception

Even though it was just a 2-week sprint, during the retrospective session we heard a lot of positive feedback from the team. We asked our team members to share their thoughts on how they perceived the new practice and this is what they had to say:

The best thing is the discussion with my partner to understand his point of view and validate the scenarios that I have come up with. —? Kasun Seneviratne

Pair programming will help to speed up the process but with fewer defects. We can plan for more frequent releases — Thushara Wijesekara

I feel it’s easier to test and faster as well —? sivaloganathan jeyaprakash

Initially, I felt it was distracting and time-consuming. But later it started showing promising results on the work. ‘How do we test?’ became a very important question. Data manipulation which the developer can do is not an option anymore. Testing became more efficient as the pair can play it to their strengths — be it typing Linux commands or trying out edge scenarios —? Samanala Athaudahetti

I was able to write more efficient code than before since I could learn about the scenarios I need to address —? Uditha Melan

“Pairing” is “sharing” — it creates a very conducive environment for knowledge sharing —? Anton Perera

When I’m driving my Ford Focus 120 mph towards a 130o corner to the left with a sudden incline and another sharp 40o to the right in a rally race, my co-driver is the one who guides me about the exact incline angle and speed I should take the first corner to tackle that hard 40o. The perfect combination for the win —? Nipuna Dilshan

Testing became fun and easy with two people helping each other —? Maleesha Gunasekara

Exceptions

A member is on leave

When we found out that one member is unavailable, we found an alternative pair for the other member — when it wasn’t possible, we let the individual member work alone.

The tasks were too simple

Pairing is great for complex problems where you need more collaboration — yet, if the problems that you are trying to solve are simple enough, we let the engineers pick them up individually.

Loopholes

Work that leave the partner on hold

There were some instances where one engineer was focusing on something that demanded their specific skills and had no way that the partner could contribute to it in any productive manner. Even though the engineers took the “exception” approach described above, in such instances, we believe that there are further improvements we can make here

The beginner’s bad luck

Since this is a change to the routine we were familiar with, we took longer than usual to complete the release we planned. We attribute this failure to not having the new team dynamics figured-out properly, which is arising due to the new way of working we adopted.

Achievements

First thing first, our best achievement is?optimized collaboration and the realization that “this is a great way to work as a team”. Both developers and testers felt the same and everyone conquered our approach is the way forward! This is more than winning the half-the-battle.

Less number of defects, better quality:?This is a huge achievement too. In any software team, defects keep you stuck. With this new practice introduced, we have been able to reduce the number of bugs reported by testers.

We stopped starting, started finishing:?This is another achievement — we must say, a big one! We had the habit of starting to work on several stories at one given time. Now, our focus is to focus on a few stories per team — just one story per pair at one given time. This has helped us to be focused, and therefore, achieve more!

An optimized Value Stream:?With the introduction of pairing, we managed to cut down two major process steps “Dev Testing” and “Open to QA”. This avoids back and forth hand-offs between Devs and QEs.

Verdict

As an agile team, we wanted to optimize the collaboration targeting enhanced focus and value delivery. We started the discussions around this topic and after a few intensive brainstorming discussions, and retrospectives, we agreed to proceed. As seen in this article, our team enjoys this practice so far and feel that this is the way forward. We have just started pairing a few weeks ago and still see a huge improvement in the collaboration and the results.

What about you? What are the practices that have helped your development teams to be effective?