The dynamics between the QA and Development Team has always been an interesting topic to me. In my 16 years of experience in Information Technology, I have observed that one of the most fragile relationships in an Agile environment is the relationship between the QA Team and Development Team. I wanted to take some time to talk about my experiences on this subject, give some reasons why I think tension often occurs between the two groups and my opinions on how to prevent a breakdown in the relationship between the two groups.
It’s Only Natural!
When you think about it, The QA and Development Team being at odds is only natural because one group is creating a product and another group is tasked with acting as gatekeepers and trying to find fault in the product. Developers can be a very sensitive bunch and when someone from the QA Team, who is only doing their job, finds bugs in the product, some Developers can find fault with this.
I remember project I was on for a little over 2 years where we had a developer that was extremely sensitive to anyone telling her that her work had bugs. During the daily SCRUM stand ups, she would become argumentative with the members of the QA Team as they gave their daily updates. Unfortunately, this had a very negative affect on the entire team and at one point, the QA Team revolted and refused to talk to the Developers outside of formal meetings and interaction between the two teams were very antagonistic.
The situation reached the point of absurdity when despite the fact that both teams sat in the same SCRUM room and directly across from each other, if a Developer wanted to know the status of a feature being tested and asked QA directly, the QA Team would say, “Look at the SCRUM Board or check the status in Rally”.
The QA Team Feels Unloved!
Another reason why I think that the relationship between the QA and Development Team tends to breakdown is because the QA Team often feels like they are not appreciated. On most Agile Teams, you will most likely have more Developers than QA, the Developers shoulder most of the responsibilities and when budgets need to be trimmed, most of the time, a QA member will be sacrificed before a Developer. Also, there are some Software Methodologies such as Kick-Ass Software Development that asks Developers to be responsible for both Development and QA.
Some of these realities can lead some QA members to believe that they are not appreciated and resentment can build. When the QA Team starts to feel resentment, it can affect their work, their relationship with Developers and overall, this can lead to an inferior product for the business.
On one Agile Team I was on, we had a very low Developer to QA ratio due to budget cuts. On this team, we had some very junior developers and one developer in particular who deleted our Test Database on two separate occasions and wasn’t very productive. Despite this fact, management kept releasing valuable QA resources and as a result, QA morale dropped, they were overworked and the quality of the product suffered.
Developers are Arrogant!
As a Developer myself, I can freely admit that a great many of us are arrogant. Many Developers feel like they are not responsible for some aspects of QA and will scoff at any notion of their code being buggy or not up to specification. I have seen Developers treat members of the QA Team with derision, contempt and will openly claim that the people in QA are in QA because they couldn’t “hack” it as a Developer.
On one project I was on, the Project Manager ran a bug report and was a little dismayed by the number of bugs reported. When she asked the team for any ideas on how to cut down on bugs, I proposed that at the beginning of each Sprint, the Developer who was going to implement a feature and the QA person most likely to test the feature get together briefly before any coding took place and make sure both sides were on the same page and had similar ideas on what was supposed to be delivered. To my surprise, many of the Developers had a huge issue with talking to QA before writing code.
You see to the Developers on this team, it was beneath them to have to talk to QA before they could write a line of code. In their minds, QA just needed to be quiet and just test whatever the Developers threw over the wall, no matter how obvious it was that what the Developers had delivered was incorrect. One of my fellow Developers accosted me during a lunch break and told me that, “QA just needs to stop complaining, shut up and just test our stuff”. Fortunately for our team and the product, the Project Manager/SCRUM Master made an executive decision and implemented my suggestions and I believe that we were a better team for it because the lines of communication were opened up and both teams were on the same page with regards to what they felt needed to be implemented.
So How Do You Prevent Acrimony Between the Development and QA Team?
I believe that there are many things that an Agile Team and Management can do to prevent a collapse in Developer/QA relations. First, the team and management should make sure that every member of the Agile Team feels appreciated and is shown respect. “Rockstar” Developers who feel that they are above QA and treat QA with disrespect should be warned and if this behavior continues, should be shown the door.
Also, I believe that good communication is a great defense in preventing any acrimony to develop between the QA and Development Team. Before a Developer starts to work on a new feature, they should spend some brief time with a member of the QA Team to ensure both sides understand what is going to be delivered and what is going to be tested. One of the biggest sources of grief between the two teams is when a Developer starts to work on a feature, completes it, hands it over to QA and QA feels that the feature is not even close to what should have been implemented.
Last, management, the project lead and other people in positions of authority should make it clear that QA is not just the job of the QA Team and that everyone has some role in preventing bugs, identifying bugs and fixing bugs. After all, the main objective of any Software Development Project is to release a quality product that most closely resembles what the business and the Product Manager asked for.