QA engineers and software developers are often painted along the same lines as cats and dogs — opposites naturally pitted against one another. After all, how could they not be when one’s job is to point out the other’s errors, right? Well, not really. In reality, these two professions are far more collaborative and complementary than it is commonly perceived.
In order to shed some light on the professional dynamic between the two camps, as well as the organizational culture we have strived to build at HTEC, we have enlisted the help of our colleagues who shared their experience of working with “the enemy”.
Human factor
Bugs are inevitable.
As different pieces of code interact with one another and separate processes come together in surprising ways, trying to predict every conceivable scenario while writing code is impossible. Development and testing represent two sides of the same coin — each playing a vital role in the making of clean and functional software.
“The most important thing is the end result, and it is always the product of a joined effort of both developers and QA engineers.” — Dusan Kuvalja, QA engineer
Dusan Kuvalja and Andjelko Visekruna have had a long history of healthy collaboration. In fact, Dusan has been the first QA engineer Andjelko has ever worked with. Despite having no previous experience with this type of partnership, Andjelko was more enthused than anxious about it.
“The first time I realized that I have someone who will be double-checking and testing the code that I’ve written, I was actually delighted. It is like a safety net that eases the pressure and responsibility, and if a tester finds something wrong with the code — even better!” — Andjelko Visekruna, software engineer
Aleksandar Miljkovic and Igor Lalic have also enjoyed a long and fruitful developer-QA partnership. They both believe that the two aren’t natural opposites and that the nature of the partnership is greatly determined by the individual character traits of the collaborators.
“In my experience, in the end, it always comes down to what kind of person you are. We have to be able to trust one another — I trust the QA to examine my work thoroughly and not try to break it in a malicious manner, simply for the sake of breaking it. Likewise, QA should be able to trust that I won’t roll my eyes when they report a bug, that I will respect their time and effort and fix the bug as quickly as possible.” — Aleksandar Miljkovic, software engineer
“The very first time I told Aleksandar that I’ve found a bug in his code, he said ‘great’. No questions, no arguments, just ‘great’. You can never know how a developer will react in such a situation, and his response was both a relief and a strong indicator that we will work well together.” — Igor Lalic, QA engineer
State of mind
A big part of what makes the QA-developer dynamic both complementary and delicate are the diverging mindsets at the very heart of each profession. Our young colleagues Slobodan Vasic and Mladen Bajsic have tried walking in the other’s shoes, and they have both found that they don’t quite fit them.
“Programmers function differently. I realized that when I decided to learn a bit of programming. You’re looking to enable a certain functionality and you cannot afford to think too broadly. You will establish some basic validations, but you won’t consider how many cases you will cover with your implementation, like what will happen if you change the settings or click here instead of there and so on. If you tried to juggle all the possibilities in your mind, you would never finish your code. I think that for programmers it’s actually good to have a narrow and precise focus. Leave it to QA to consider all the ways the users might interact with the software.” — Slobodan Vasic, QA engineer
While the two skill sets are complementary, it seems that programming as a QA engineer or testing as a programmer may not be the best of ideas.
“Recently I did a bit of testing. I was done with my tasks and jumped in to help speed things up. I quickly realized that I don’t have the mind of a QA engineer. I can test the basic functionalities and cover the basic cases, but I can’t possibly think of the things that Slobodan comes up with. Like that time he inserted emojis into the Wi-Fi SSID — I could never come up with that!” — Mladen Bajsic, software engineer
Trust issues
When discussing the QA-developer relations, the one word that keeps reappearing is trust. It implies both the interdependency of the two roles and the delicate nature of the partnership. Between the lines, it also suggests that the relationship is not always rooted in trust, and some of our colleagues have had such experiences in their professional work.
“There are vanity and insecurity on both sides — people unwilling to accept responsibility and people disrespectful of their colleagues’ work. In my experience, regardless of the seniority level, if QA engineers and developers are level-headed the results are always good. Technical skills are important, but we are often willing to turn a blind eye to technical imperfections if a candidate seems mature and hard-working because the human factor is so crucial.” — Aleksandar Miljkovic
As one of the most experienced QA engineers in our midst, Dusan Kuvalja is often involved in the mentoring of new employees. Along with other senior colleagues, he does his best to set an example of communication that the younger team members could follow.
“Lack of soft skills is a common issue in our industry. Some things don’t get said out loud, other things are not communicated properly, and this can create difficulties on a team level. Healthy communication and a healthy attitude towards work are the keys to a good relationship between QA engineers and developers.” — Dusan Kuvalja
Igor Lalic has also done his share of mentoring, and he has seen how issues between the QA and development camps don’t always arise out of vanity or insecurity, but also out of overeagerness and the desire to impress and to prove yourself.
“One of the first things I tell any new QA engineers on our team is this: ‘don’t be a jerk!’ Finding a bug is not a cause to celebrate or to rub it in. It simply means that you are doing your job.” — Igor Lalic
Common ground
The collaboration between developers and QA engineers is rarely as clear-cut as “one writes code and the other verifies it”. From planning together and finding solutions to doing the little things that make the other’s job a little easier, their work often overlaps as a joined effort.
“If you work with someone long enough, over time you gain a better understanding of their work. In a way, you begin to think like them and see things from their side.” — Andjelko Visekruna
Andjelko recounts one large scale project with an enormous number of interconnected parts, where one modification to the code could potentially impact many different parts of the system. His understanding of the work of a QA engineer has enabled him to begin to identify specific risk areas and inform QA where their effort will matter the most.
“This makes my work a whole lot easier and impactful, as it allows me to focus on key areas instead of blindly testing the entire code. I’ve also had the opposite experiences, where I would ask a developer, what are the risks and which parts of the code might be affected by their modification and I would be told that there are no risks — which is impossible. It is a sign of one’s maturity and the understanding of our work.” — Dusan Kuvalja
Collaboration often extends beyond the narrow focus of each profession’s primary tasks and onto territory where both skill sets (and mindsets) are equally applicable — project planning.
“Our collaboration begins even before implementation. After a product owner explains the required functionalities and we map out the project’s scope and boundaries, Igor and I made it a habit to sit down 1-on-1 to see how each of us understood this or that, from the functional side. The goal is to define as many testable cases as possible right from the start, on which I could then base my implementation approach. Then he writes the cases, and I handle the implementation. Once that is done, we meet again to assess our work and see what’s next. That’s all before a single bug is found!” — Aleksandar Miljkovic
Friendly fire
Over time, just as in any other profession, the working relationship between developers and QA engineers can evolve into friendship. The camaraderie is the fuel that drives teams forward and helps overcome even the most tasking challenges.
“The quality of your relationship matters the most in critical situations. For instance, we’re at the end of a sprint, we must deliver the product by 4 PM tomorrow, it’s just Aleksandar and me left at work and we find a critical bug — there’s no way we can either fix it or test it on time. What do you do? I can imagine that there would be finger-pointing and passing the blame with co-workers who don’t have a healthy relationship, but we were able to laugh about it, accept it and get to work.” — Igor Lalic
For some of our younger team members, laughter is their go-to mode, and friendly needling an essential part of their working atmosphere. The developer-QA dynamic represents the essential ammo for laughter.
“There’s always a lot of back-and-forth along the lines of “your code is buggy” and “you’re not testing it right”. Even when dealing with deadlines and pressure, we are able to joke about it and laugh it off. Of course, your sense of humor will not move any deadlines, but everything is easier when you can laugh through it”. — Slobodan Vasic
This friendly fire often produces results that extend beyond the standard boundaries of creativity in an attempt to get under somebody’s skin.
“There’s nothing that upsets Slobodan like not being able to reproduce a bug. When a bug manifests itself on two boards and then doesn’t on the third one — that eats him up! So, we came up with the idea to add an intentional bug to the code which we could switch on and off on command when he tests it. Unfortunately, he caught wind of our plans, so we gave it up. We’ll just wait until he forgets.” — Mladen Bajsic
The verdict
Bugs are inevitable.
They are not to be feared or even avoided. They provide insights that enable us to improve our solutions and our process. Transparency and openness in understanding and embracing this fact is the foundation of a productive relationship.
“Ultimately, our one objective is delivering software with as few bugs as possible. It is completely irrelevant who created the bug or who found it. What matters is that it is removed. Of course, it helps if you work with someone who you can trust and communicate with.” — Igor Lalic