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.
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.
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
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
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 maybe offer some chocolates
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.
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.
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…
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 happens several times
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 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
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.
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.
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!
@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!)
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.
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!
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.