The Love-Hate Relationship Between Testers and Developers

Admit it. Every time we think of the major forces that shape the world such as tech or science, we think of rocket launches, medicine, or even media that form our perceptions. Not many of us think of the people behind the scenes, the relationships between them, what inspires them and makes them drive it all forward. We just assume that things ”get done”.

Back in the day, people responsible for software development were usually hidden in their garages, they were a bunch of data geeks and brainy visionaries. The division between developers and testers was… non-existent. It truly is mind-blowing how much has changed since then! We literally hold the entire Internet in our palms. Apps and software play key roles in our daily lives. They teach, entertain, inform, and enhance our lives in so many ways. So why is the dependency between testers and developers so essential to that immense progress?

Most testers love their jobs, and they get paid to simply ”break stuff” and be annoying. The pickier you are about those bugs, the better. The problem is that nobody wants to hurt anyone’s feelings and no one wants to be pointed for their mistakes. The whole relationship between QA teams and developers is based on testers trying to spot errors made by developers who take so much pride in their work. So it all boils down to being professional, precise, but still polite. And that’s how the story begins.

No Outcome is Good Enough

Both testers and developers work towards a common goal — to build a high-quality and bug-free product. They are equally responsible for the final outcome. However, since testers are solely responsible for catching bugs and stopping the bug infested code from being released, there are two, very common situations that QA teams find themselves in:

• The tester has found a bug
• The tester hasn’t found a bug

Conclusion: neither situation is perfect

In the first case, usually, it goes the same old way. After a bug has been found, developers ask testers whether it really is their problem. Perhaps, they can put the blame on something else and not have to deal with the problem at all ;)? Or they will ask way in advance about the number of bugs they should expect as if testers had superpowers and predicting the future was one of them. And they really DO expect a precise number. The answer is very simple – as many as you have done in the code.

The second scenario creates the perfect opportunity for developers to start an open discussion with testers. If there is a leftover bug that hasn’t been pointed out before, some will say well, this may actually be your fault, this bug was so painfully obvious!
But no hard feelings. Even if such situations take place, it’s all for the greater purpose.

It Works For Me!

There is a certain saying that is often used by some developers. Not all of them, just some. They say it when customers encounter bugs. They say it when QA says that something still doesn’t work.

It works on my machine!

Perhaps everyone has come across it on the Internet, or at work. That’s the all too famous excuse that developers say when confronted with a defect in the production environment. However, anyone who has been in IT for a while or scrolls through memes on a regular basis knows that developers say it as a joke. And that’s a fact!

If testers could share one expert tip with all developers, it would be to push all updates before handing over the task to QA. It avoids releasing things that don’t work to production. It saves developers the embarrassment when telling someone they are wrong, while in reality that are actually right.

Let’s go, give it another try to see what you’re doing wrong … Oh, I see!

However, that isn’t something what experienced engineers say. As they progress in their careers, most of them come to realize how valuable QA feedback is. Senior developers know that testers want the best for them and that they’re not a bunch of manipulative liars. They cooperate with QA to iron out any bugs before they get to production. Most often, it is the matter of pride and admitting that no one is perfect, and we all make mistakes – even in the precious code. And it comes with time. At Grape Up, we seek to maintain a healthy cooperation between testers and developers every day.

What Does It Take To Be a Good Tester?

Not just anyone can be an exceptional tester. QA team members wear many hats: they must have an eye for detail, but also think outside the box like a user. They must know how to prioritize and put on a brave face in all situations. Perfect communication skills are a must while it is highly appreciated that they learn from their own mistakes – and from others too. Being objective and professional is also a nice-to-have. Last but not least, every tester should know how to say “no” to the developer and that something isn’t their job.

This is important as sometimes QA members, after having identified an issue, get asked to fix bugs themselves. This, of course, should always be done by a developer – not a tester. Therefore, assertiveness above all! That’s just the tip of the iceberg of what employees require from testers. But with practice, QA teams learn to harness their inner Sherlock Holmes and hunt down every bug to build an impeccable piece of software.

After All, Love IS In The Air

Putting everything aside, developers and testers do love each other. These two groups come together in symbiosis to create a product that works for the end user. Symbiosis by definition, is a relationship of mutual benefit for both sides. And just like in the case of developers and testers: both groups give and take. Testers give feedback, developers take that feedback, give their time to eradicate bugs and give back a bug-free product. Because after all, we’re all in this together, right?