The Dev-QA Delicate Relationship

Success to your product is directly influenced by the ability of your 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. Symbiosis between QA and Dev will accelerate 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 your product/team in the opposite direction. There is a delicate relationship between the two and a certain tension that must be confronted and not overlooked. Most of you probably felt it in your work place. You hear a QA’s question thrown to the air, followed by a smug 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 vacuum. He understands enough to accomplish his tasks, but not enough so that his code will be reusable. He can not foresee 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 Dev 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 Dev 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.

 

Reference: The Dev-QA Delicate Relationship from our JCG partner Nadav Azaria at the DeveloperLife blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

One Response to "The Dev-QA Delicate Relationship"

  1. Taylor Mathewson says:

    I’d add one more point. Everyone needs to remember they’re all working towards the same goal: releasing an awesome feature or feature set.

    Just as devs sometimes commit bugs, so testers sometimes misinterpret requirements or behaviour. No one is perfect and a KEY responsibility of both dev and qa management is to keep the relationship respectful and collaborative.

    Additionally, dev managers need to be accountable and hold their teams accountable for preparing a quality build for QA. We are too often guilty of dumping stuff in an unfinished state on QA. The other side of that coin is that QA manager need to be accountable and hold their teams accountable for preparing quality bugs that are clear and intelligible, and for working with devs to diagnose and identify issues.

Leave a Reply


6 − = one



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close