The Developer and QA Delicate Relationship

Success to the product/project is directly influenced by the ability of our QA and Dev teams to work well together. This is even more tightly coupled in the agile world when QA and Dev work and deliver under the same team. Cooperation between QA and Dev will quicken delivery time, create a more robust product, and overall will increase team member satisfaction. 

Saying the above is obvious. However, failing to understand the relationship between QA and Dev will take the product/team in the opposite direction. There is a delicate relationship between the two and a certain tension that must be challenged and not ignored. Most of us probably felt it in our work place. We hear a QA's question thrown to the air, followed by a self-satisfied reply that is basically telling him that he will never understand since he didn't write the code. Or the other way around, when a developer asks a question about the product and the QA looks at him in a look that says "you really need to get out of your little world. There is a whole cosmos waiting for you..."

There are several symptoms/causes that can help you identify the level of tension in your workplace:

Domain knowledge is mostly in the QA hands

In this situation, the developer works in a void. He understands enough to accomplish his tasks, but not enough so that his code will be reusable. He cannot anticipate new advances in the field of interest. He is like an ox plowing in long corridor blind folded.  

Lack of respect

You all know it is there and from both sides. "This feature was written with so many bugs, my grandma would have written it better", or maybe "How dare he open this bug? It just shows me how little he understands..." Each side is building his own trench while accusing the other side in every single problem earth has encountered. 

Over Testing

There seems to be a tendency to retest the entire product after each change (which should be prevented by proper sanity automated tests, and not by manual checks). Checks are too strict. This leads to slowness in the product improvement and frustration for developers. 

Under Testing

Features are written under pressure, and as such are tested under pressure. Not all extremity cases are simulated. This may cause frustration in QA side, since they are the one that signed off the feature.

Who's the Boss?

Developers sometimes see QA as their personal assistants. They might ask the QA to complete tasks that are not directly related to QA but mostly to save "expensive" developer's time.  

Who is to blame?

In places where the QA is hold responsible for product quality every bug which was shipped with the product has the potential to flame a new fire. Who is to blame?

WHAT CAN WE DO AS MANAGERS TO HELP REDUCE THIS TENSION?

• Cross Functional teams. Putting them in the same team and make the entire team responsible for the product. As we said before this is already happening in the agile era.
• Let them do each other's job. Let the QA do some Development in the form of writing scripts or anything that will make them understand bugs are inevitable. Let developers do some QA so they will understand the horror of saying: "I tested it and it is ready for shipment"
• The layer of team managers should originate from Development and QA both, thus giving the management a broader perspective.
• Management must have excellent interpersonal relations and be aware of the tension, confronting it when necessary.