Often we developers are represented as introverts with a big ego. And, most of the time, that representation is accurate. We prefer to lock ourselves in a dark room with a massive amount of coffee and create complex and beautiful systems. That makes us happy but also boosts our ego. Haven’t you felt like a god after completing a challenging task after 12 hours workday? I bet you have. We all have.
Being a god (I hope you got the irony here 😊) with not so developed social skills sometimes causes problems in our relationships at work. One such a special relationship is the relationship with the QAs.
The fall of the false gods
QAs do not believe in gods. They believe in what they see. No god can subdue their will.
QAs are the people who pull the rug under our feet and expose us, us the false gods. Only they can bring us out of our dark sanctuaries and makes us responsible for our evil deeds against humanity (customer). For us, only the pain of the destroyed apotheosis remains. Licking our wounds, we brew another cup of coffee and continue to serve humanity until we grow stronger again. Then the cycle repeats.
Back to reality
The relationship between developers and QAs is an interesting one. As a developer, I have seen many things – from extremely toxic relationships to very productive ones.
All the bad ones have one thing in common. Both parties think that their personality is attacked, not the quality of their work. The focus of both parties changes from “is that good for the customer” to “how to handle that moron.”
I have heard developers saying, “You are QA just because you are an unsuccessful developer.” Or QAs saying, “He is an idiot, I am reporting him this bug for the third time, and every time something new is broken.”.
Scenes such as these are scarce, but this does not mean that everything is ok. Sometimes both parties prefer the passive-aggressive approach instead of a direct clash.
We all can see that this type of behavior is disgusting and leads nowhere.
QAs are not your enemy
I am happy that 99% of my collaborations with QAs have been more than successful. And this is not due to luck. It is all about mutual respect and realization of the shared goal – our mission is to make the customer happy.
I prefer to think of my QA buddies as a sniper team having my back during an intense battle (unrealistic deadline, unclear stories… you name it).
Most of the time, they have a wider angle of vision than us developers. They are more familiar with the general picture, and for them, it is easier to see what is more useful for the customer. Their knowledge also helps them to see how a change will impact other parts of the system.
Don’t work in isolation. Leverage that knowledge. Ask them for their opinion. Both try to see beforehand possible complications. Try to build a strong team. Team that shares knowledge and ideas.
It is also very important for both parties to stay open for constructive criticism. Yes, sometimes is hard to put your ego aside but is essential to do it.
Here are several simple steps you can take to improve your relationship with the QAs. All of them are extracted directly from my experience and believe me they really work.
How to be the cool dev in the block
- Just test the code you wrote for god sake! I have seen developers pushing code without even trying if it builds.
- Don’t test only the happy path. Don’t be lazy. Set aside a half an hour or an hour to test your code out of the prominent cases.
- Read very carefully the task you have. Be sure that you have implemented all requirements before pushing. Don’t play ping pong with the QAs just because you haven’t been careful.
- Always run the unit tests suite before pushing!
- If your task has some prerequisites, document them. Don’t leave your colleague to guess blindly.
- If your task does changes that can not be reverted, let your colleagues know. That way, they will be able to save a backup of the current state of the system.
- If there is a way to save them time, tell them. For example – “John, if you use the WF from 3.1 and revert the document to version X.1, you will be able to test functionality Y easier.”.
- If something you have not implemented (for whatever reason), document it. Please don’t leave your colleagues searching for something that does not exist.
- I know It is annoying to be distracted but if they are reaching out to you for help – help them. This, for me, is imperative.
How to be the cool QAs for us, the developers
- An issue with copy/pasted stack trace is not a bug report 😊. Please describe all the steps needed for reproducing it.
- If a task has more than one problem (and they are not blockers), please don’t report them to us one by one. Have them all described and then send them to us.
- Please add some visual data. It is far more useful if we have some screenshots or even a video clip.
- Please use the correct terms and exact wording. If there is a field named “Paid by customer,” please don’t refer to it just as “Paid” (even If it is the single field on the form).
- If you can provide the test data you are using, we will be forever grateful.
- Please provide the expected result/behavior. We may have missed some cases.
- Sometimes you expect us to remember why calculation X behaves that way (from a task that is a year old). Yes, we are competent, but please give us a minute to recall or check in the code.
- Please leave the “I got you” and “Now you will see” attitude behind.
Something like conclusion
Just be a professional. Nothing more is needed. Only by having good and fruitful relationships with your colleagues you will have a happy customer. And as you already know, only satisfied customers are going to pay your salaries.
