Tester vs developer
the never-ending battle

Testers and developers sometimes seem like two people from two different planets. A lot of things have been said about testers and developers. One thing is that they have different ways of thinking, and guess what? They do have different ways of thinking, but is this making one better than the other? We shall see. I bet everyone has heard these questions at least once, mainly if you already work in the software development field.

• • • • • Is it better to be a software developer or a tester?
        • Is development superior to QA?
        • Why QA and not DEV?
        • Developers and Testers are like oil and water?
        • And this list can continue over and over.

The first question that a newbie in this domain would ask is: “What’s a tester?”, now dear testers, don’t be offended because some of you put the same question before starting to work as a tester; I also did that. This is a very normal thing; let’s do a small exercise to explain to you why:

• • • • • Think about some movies about software development, writing code, developers, hackers, etc.
        • Now think about a movie that is about testing and quality assurance.
        • Probably it was much easier for everybody to remember some movies related to development than to testing. Because being a developer seems too popular and cool, sometimes being a tester can look less critical, but is this true? To resolve this myth, we must know both the tester and the developer.

As I mentioned at the begging of this article, the tester and the developer have different ways of thinking. Testers look at the product from a different perspective than programmers do. The developers think about how they can create the application, and the testers think bout how they can break it. By saying, “How they could break it,” it does not mean that a tester will spoil the work done by the developer. It means that the tester will take the user role and apply all the possible and impossible scenarios on the application. This is done so that the application will not break when released in the live environment. In some cases, for both developers and testers, it’s hard to understand the peculiarities of each other’s work. That’s why sometimes developers don’t understand why the testers break their application, and the testers don’t know why they create such a faulty application.

Developer vs. .tester

A developer works hard to develop a product; he handles it with so much care and gentleness; a tester works hard to break this code in the worst possible cases and scenarios to test its strength, resistance power, and defects. So, when a developer finally hands over his much-nurtured sprint to the merciless testers, ready to execute the ‘out-of-the-box testing, they silently demolish the code…

Developers are often seen to possess parental attachment to the code they create. How often did anyone hear these statements: “This is an edge case, the users will never do that” or “I know my code, it wouldn’t do that”? Well, guess what? The code must do that! It might sound a bit silly, but a good programmer knows how to be more objective and accept that testers have to do terrible things to their code because, if they don’t, someone else will do it! Often the developers don’t know how their code will be handled at the other end of the boundary wall, and they aren’t ready for the millions of “edge cases” that testers will find.

Being in the development environment, which usually resolves around optimistic scenarios of how to make things work efficiently, they can not often switch to the “what can go wrong” mind state. From here, another thing te hear many times is, “This is not reproducible on my machine”/ or “I cannot reproduce this”?

As we already know, every project has a deadline when the product has to be released in the “wild,” and this leads to some questions:

• • • • • How will this never-ending battle between the Creator(developer) and the Destroyer(tester) end?
        • What is the purpose of this battle?
        • Who is right or wrong?
        • Which one is better?
        • After the developers and testers understand each other better, they can learn to work together. This is progress, and they will reach their common purpose only by working together.

As humans, we’re going to make mistakes, it’s what makes us humans, and most of the time, the most effective way of learning is from a mistake. Often it is much easier to detect an error in someone else’s work than to see it on your own. That’s why developers and testers complement each other. Both make mistakes. It is not important who does most of them. WIt is essential to find the solution to that problem together as a team. If there is no struggle, there is no progress. We know that progress is impossible without change, and those who cannot change their minds, cannot change anything.

I think that now you are ready to find the truth about this battle:

• • • • • Developers and testers are not enemies; they are on the same team and fight for the same purpose: To deliver a Quality Product!
        • The real never-ending battle is to deliver a Quality Product!

See you soon at CodeCamp Baia Mare for more discussions on the subject: https://baiamare.codecamp.ro.