Development Team vs. Quality Assurance Team. The eternal rivals?

Although there are different variants of how to form teams in the software industry, the most common in companies is to have an application development team responsible for creating software and a QA (quality assurance) team responsible for testing that software.

I started in the software world about 10 years ago, by that time, I worked on researching products, and on identifying and developing requirements to implement in the software.

Due to my responsibilities, I should be in constant communication with the development team and the quality assurance team. From the beginning, you could see a strong rivalry between them, such as being fanatics of different baseball teams (New York Yankees vs Boston Red Sox) or soccer teams (Real Madrid vs Barcelona) in the final tournament.

Due to this reality, the actions of one harmed the other, that is, if the quality assurance team found issues in the software, that meant that the development team did a bad job (point to QA), on the other hand, any reason was good to put an issue “Rejected” or “Can’t Reproduce”, a drafting error, missing a step, etc. (Point to Development).

I also witnessed and participated in endless meetings where they fought fiercely with all kinds of arguments on who was right about the implementation of a requirement or a detected issue. If an issue in production was detected it was very easy to blame the “opposite” team, one said “QA didn’t test well”, the others said “Development did it wrong” or “delivered late.” It was very simple to discredit each other’s work and to place the responsibility on the others.

Over time they began to show miscommunication between equipment, failures in delivery times, low-quality application development, and to try to solve these problems, the company began experimenting in search of solutions. Among other things, additional hierarchical levels were added to the teams, processes were restructured, methodological changes, etc. Which in my opinion resulted in very little success.

During my career, I have worked with many teams, with different structures and different products, however in a major or minor way that rivalry has always been present, and this story is the common denominator of many companies.

Later in the company where I worked, it was decided that we should use agile methodologies.

We would start to work using the Scrum methodology which was not at all easy, you have to change many paradigms, and to be honest I didn’t think it would work, although I had to leap, the order to use Scrum came from above.

As we progressed with the implementation of the methodology I realized that the status quo that was so hard to leave, was gradually diluted until it finally disappeared, but, Why did this happen?

The fact of having meetings every day and that all team members were involved, did that each of the “teams” members gradually understood and internalize that we were working towards the same goal.

It allowed us to understand and appreciate the work of our colleagues and that each of the team members has specific skills that enable them to cope with a greater dexterity certain types of tasks.

This created a work environment where it was understood that the work and effort of each one are reflected in the developed software.
Due to that, we are humans, we make mistakes, there will be things we do not know, we’ll have problems unrelated to our work, so it’s necessary to help each other to achieve the project goal.

It is an indispensable requirement that all team members are aware of the needs of a product and actively participate in the process to achieve that goal. The only way to achieve this is with a very high level of communication.

Over time, developers no longer felt attacked by the people from QA, they understood that everything was just meant to improve. The QA people no longer disqualifies the work that was done and they are now focused on improving the software, improving the application development process and no team members evade their responsibilities.

As the months passed, the team became a unique and well-established team that achieved:

• Work delivered with high quality
• More work was completed within the same timeframe.
• The nighters to achieve deliveries were minimized.
• People leave the office in time to share with their families and live their lives.
• A harmonious and solidarity work environment.

Although this seems like a difficult story to believe, this is achieved by applying agile methodologies, because these frameworks have a focus on communication and certain techniques that enhance interpersonal relationships and promotes this progress.