When working with developers, how do you keep those relationships healthy?

Being a QA can be hard because so much of our job is about being honest about our findings. I’m sure you could share some horror stories as a QA when it comes to working with developers. Instead of discussing those, what have you learned when it comes to keeping your relationships with developers healthy?

How do you foster good communication?
How do you earn trust?
What do you look for when you are interviewing in a company? What are the green flags?

How do you keep your relationship with the engineering team healthy?

Thanks so much for sharing! Looking forward to your answers.

8 Likes

Simple by giving them chocolates :grin:

8 Likes

I find that simply being friendly, not assigning blame & keeping my own communication as clear as possible goes a long way to keep relationships with developers healthy.

11 Likes

Great question! And a really important / impactful topic.

  • How do you foster good communication?
    • At the core of it all, I treat my teammates like people, and with the respect they deserve
    • I try to pay attention to the way they prefer to communicate, and adapt to the individual, without compromising my own authenticity
  • How do you earn trust?
    • One of the most important things is to deliver on your promises, even if that “just” means providing relevant and timely updates
    • I try to find out how I can support each person, and keep them informed and involved in topics they’ve indicated are important or interesting to them
  • What do you look for when you are interviewing in a company? What are the green flags?
    • Working together and avoiding silos is a good one - seeing the testing specialist as part of the development team
    • The team indicates a genuine desire to know what the issues are, early, and improve quality as a team
  • How do you keep your relationship with the engineering team healthy?
    • One thing I’m very conscious of is not to impose myself on them - I’m not a gatekeeper or management authority, I’m there to help and support. That means convincing, showing, recruiting, not telling, dictating, or forcing
    • Always remember to give positive feedback - whether it’s about a feature or way of working, the news we deliver doesn’t always have to be negative, and it helps morale to know that someone is looking to assess quality - whatever that looks like - not, just criticise
14 Likes

Great points, Cassandra. And I agree with Adrian, being friendly and clear already makes a difference. Asking questions helps too. Devs don’t like unnecessary Jira tickets, do they :innocent:
When reporting/discussing issues, I phrase them in the most impersonal way possible, I’m describing facts, and I obviously provide all the supporting information/evidence. This removes the problem from me as the person who flagged it and the dev as the person who will need to fix it (and that may have “caused” it). It places it at a nice distance from both of us where we can look at it, and it becomes just a thing we are addressing together - which is what it is - to make it better. I try hard to make it and keep it non-personal as much as possible (if it makes sense). I think this minimises the possible clash between the two roles that can creep in, if we are not mindful.
I also find regular communication and updates help a lot, especially when the deadlines are tight, as well as being reliable and accountable, as at the end of the day our jobs are dependent on each other’s.
And finally, remembering that they are fellow humans too and acknowledging their hard work :joy: maybe offer some chocolates :wink:

6 Likes

Well fortunately things have moved on since the times I was working in a V-model 80 strong engineering team sitting at the end of the process where they lobbed their finished code over our wall and we lobbed it back shouting “WRONG!”
So some general bullet points from my perspective how it works for me:

  • Above everything, you have to foster a culture that “we’re all in this for the same reason - releasing top quality products that the customer is gonna love and want more”. Campaign for the teams to know “we’re all on the same side” and be prepared to repeat the discussion.
  • Damn it have some fun! Have some banter! Set out to make each other smile every day.
  • Share early and be open all the time. You’re not here to catch developers out, you’re here to help each other get the best outcome. Share the good and the bad, learn from each others triumphs and pain points
  • Be prepared to sell the value we add. Very recently, the product team wanted an MVP and early UI designs and their instinct was to just talk with dev as they just wanted a POC. So I stuck my foot in the door to just “be aware”. In the end I gave them perspectives they didn’t consider for their POC. Demonstrating we can test without code, gets them wanting and needing your help.
8 Likes

Good Communication - be professional, be smart, be curious. Also be respectful and kind. If they are open to friendly conversation that’s a great way to ease some tension. Take notes, document everything. Screenshots or it didn’t happen.
Trust - earn it. Have a good test plan and know the product. Show up on time and respond in a timely fashion.
Green Flags - I like what someone else said about the QA specialist being part of the development team (rather than being siloed). That is (IMHO) a big part of job satisfaction and learning.

5 Likes

I remember Dot Graham saying to me about reviews (and therefore testing as well, any sort of feedback) always find something good to say first. And then give the improvement suggestions positively as well. There is always something you can praise. All the things that worked, the hard work that went into it, etc.

Dot is so good at this that I have had her review something I have done, walked away from the review feeling really positive about loads of things to fix and change - just because of her manner - her good manners!

I found that works as well with feedback to developers.

Also, get them to review some things you have done, and therefore be prepared to be in receipt of criticism… and take it well.

Finally, if everyone knows that the purpose of a review or a test is to improve the product, and the end result is for everyone to look better - we are all on the same side…

2 Likes

Interacting in a positive way with the developer to make the problem solved.
If the developer didn’t accept my statement/bug means directly i reported to the team leader after that developer accept and work on that :grin: happens several times :joy:

Happy Testing :rocket:
Ramanan

2 Likes

Some of your questions are kinda obvious so I don’t even know how to explain the basics.

How do you foster good communication with people you work with? Not developers but everyone. Probably, we can discuss the basics of communication with people but I dunno, I’m not sure that I’m ready to explain such things :sweat_smile: Context really matters. Simple general advice - be professional, respectful, polite, understand the context, and use it in your communication, as a team member focus on the business and team goals in your communication not on personalities and some personal emotions. If you want to encourage others - be an example for them. If some issues are not in your zone of responsibility - escalate issues timely before the relationships in a team are ruined

How do you earn trust? Be a good engineer, do your job well, be proactive

How do you keep your relationship with the engineering team healthy? - A healthy engineering team is a complicated topic, you need to have an engineering culture, which means strong engineering leadership and expertise. If you have an engineering culture in a team you won’t have any issues (major) in your relationship with your team. Encourage engineering culture and promote quality engineering and your relationship and communication will be fine.

Keep it simple - fix real issues in your team, be professional, and be an expert in your field and you’ll see that all relationship/communication issues stem from bad engineering practices, lack of leadership and management, inefficient processes, the red tape, bad tech solutions, etc

1 Like

One of the most important thing is not to assign blame when reporting issues. Developer should really get the message that you are there to help make the quality of the product better, not to point fingers at people for their mistakes.

Also taking the time to really learn the product so you can ask good questions, instead of asking questions every 5 minutes because you haven’t read the available documentation goes a long way.

2 Likes

Thanks for your thoughts @shad0wpuppet! I completely agree that this post may come across as obvious. What inspired my question (and a post I made coming out on Wednesday) is a conversation I had with someone working on a computer science degree. He was curious about QA as a career and asked how I dealt with the tension between devs and QA’s. I found it amazing that this person hadn’t gotten his first job yet and he knew that for whatever reason, devs and QAs find themselves at odd with each other.

The first QA job I had, I (and the entire QA team) was viewed as less than and as a scapegoat if anything unfortunate was released to production. As I grew in my career, it took time to learn how to work on software in tandem with developers that would help both parties. I had to learn what my poor communication skills (and I had some sadly) were and how I could grow into a person that the developers could rely on.

So, yeah, while it seems obvious, it is possible to be blind to the ways we (hopefully) unintentionally are adding to an environment where people feel like they aren’t being heard or misunderstood.

Hope that helps bring a little more clarity as to why I would ask this.

2 Likes

Also taking the time to really learn the product so you can ask good questions, instead of asking questions every 5 minutes because you haven’t read the available documentation goes a long way.

I’m still bad about this. Sometimes I read so fast and don’t take the time to process the information I received. Great point @mnl!

2 Likes

@isabel-evans, love this! I think I still feel a little scared reporting a defect I find that the fear gets communicated. If I approached it with praise first, that could be really helpful (by first regulating my own emotions!)

@mr_styx

Screenshots or it didn’t happen.

So true!

@ghawkes

Demonstrating we can test without code, gets them wanting and needing your help.

Love this point! I think I’m going to need think on that for a bit.

@cassandrahl

  • One thing I’m very conscious of is not to impose myself on them - I’m not a gatekeeper or management authority, I’m there to help and support. That means convincing, showing, recruiting, not telling, dictating, or forcing

Spot on! I completely agree. And, it’s something I need to remember for sure.

2 Likes

It happens to all of us :slight_smile:

1 Like

Have you tried cute pictures of otters? :smiley:

1 Like

Thank you @cakehurstryan. I feel like this is the missing ingredient and am tempted to mark this as the solution :grin:

2 Likes

For full transparency, I wrote about this last week as it’s been buzzing in my brain. Thanks everyone for this conversation! I really appreciate everyone’s input!

2 Likes

I do my best to build strong relationships with developers by working alongside them and making it clear from the start that my goal is to support them, not to critique them. I emphasize that I’m there to help them look good, ensuring our shared success rather than acting as a gatekeeper. To prevent any animosity, I address misconceptions early on and try to demystify my purpose while reinforcing that QA/QE is about collaboration, not criticism. I also take a genuine interest in their pull requests and projects because understanding how they work and code is essential, not just for effective testing, but for fostering mutual respect and a productive partnership.

2 Likes

When it comes to trust and how it impacts QA, I was exploring it late last year and summarised my findings in an article:

But I thought it was interesting to think about it in terms of rational and emotional trust.

1 Like