On our day to day lives, professional relationships matter. Theoretically, how QA should handle themselves with developers is very obvious. Or is it?
Well, it’s not.
Reporting to developers about an issue and leave it like that is not a good enough approach. It’s way too basic and distant. Professional relationship should include talking to the developer about the issue. Sometimes it requires further explanations. Other times, it will require helping them reproduce it. It will also have to involve a good set of interpersonal communication skills.
“Us” vs. “Them”
From the early days of my career, I never stopped hearing about the “Us” (QA) vs “Them” (developers) perception. I never joined those calls. Not because I feared to speak up my voice, but rather because I could never relate to it, even to this day. I think this perception is useless and has nothing to do with teamwork. The QA are a part of a bigger team. QA are not lone wolves that wait for the attack and then retrieve. If you have any wish for your product to be successful, you have to work in a collaborative way. Only great teamwork can take your product to great places.
Expect to find bugs, but keep a positive attitude
New features to test will always have bugs. That’s ok. It keeps us working and ever challenged to find new “holes in the plot”.
Wherever there’s code, there will be bugs to keep that code warm at night.
One of the main characteristics of QA engineers is being skeptic about the code. Yet, they must stay positive. That means they should not start testing while being judgmental about the code, nor should they hold assumptions about the developer who wrote it. Also, they should never be cynical about the upcoming test.
The above traits are harmful in the day to day relationship of the QA engineer and the developer.
Human communication instead of tools
Yes, Jira (or any other bug reporting tool) is a nice tool to communicate through it. Using it can be efficient and clear. Yet, you need to keep in mind that the best communication form is the verbal one. Get up from your seat and go talk to the developer if you are unsure about your findings. Talk to them about any issues you caught, especially the critical ones. Worst case, you gained some exercise.
A professional QA engineer should have excellent communication skills. These skills come into display in 2 main forms:
First, they should keep in mind that the developer who wrote the code cares about the code. When the developer says that the code is bugless, they actually mean that.
It is not just a saying to make the QA think he is waving them off. When returning to the developer with bugs, they will obviously dislike it. You should break it to them gently – don’t be arrogant.
Second, before you start your test, you need to have a good handover talk with the developer. Ask about what exactly changed and where, what are the important cases to look at and so on.
On the one hand, the QA engineer sees the “bigger picture”. On the other hand, the developers know their code well and can guide you through it. They can help you find stuff you might not have thought of before.
Becoming the enabling QA
During my career, I handled a positive relationship with any developer I’ve ever worked with. Developers aren’t all alike. They each have a different approach, belief and coding strategy. The QA engineer should know his way around with any developer he works with.
Respect them and you will get respect back. Talk to them in a cool and easy tone and you will always get answers in the same manner. Walk them through what you’re going to test. Seek their advice and show them you appreciate it.
The enabling QA is the one that doesn’t talk in the form of “I am..”, but rather in the form of “We are”. Remember that you are part of a team and act like it. Help the developers create the best possible version. This type of version has as little as possible amount of bugs (and zero critical ones!) within the preset timetable. If they fail, then you have failed as well. If they succeed, then so have you.
Let it go, let it go
Know when to stop testing. Let go of too minor or too extreme cases. You can get advice from your colleagues – peers, developers, PM. Communication, remember?
Don’t hold back on giving the green light on a version just to spite. It will not make you look more professional. It will often be perceived as the opposite.
Remember to have fun
“Breaking” stuff is fun and so is software testing. We get to play with innovative products and new technologies. We also get to find creative new ways to make them work less than expected or not work at all. You get to work with smart and fun people that you can learn from. Yes, our job is important and can prevent any product from being a complete disaster as it rolled out. Caring about our work is super important. You should respect it, but you need to remember to have fun while you do it. Enjoy the ride. If you appreciate what you do, You’ll do it better!
Love what you do. I know I do.