Testers and Developers sometimes seem to be 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 really do have different ways of thinking, but is this making one better than the other? We shall see.
I can bet that everyone has heard these questions at least once in their life, mostly if you already work in the software development field.
- Is 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 you why:
- Think about some movies that are about software developing, writing code, developers, hackers and so on.
- 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 to be so popular and cool, sometimes being a tester can look less important, but is this true?
In order to resolve this myth, we have to 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. It is quite obvious that 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 about how they could 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 it’s 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 understand why the developers create such a faulty application.
A developer works hard to develop a product, which he handles with so much care and gentleness; a tester works hard to break this code handling it 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 team of 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 many times did anyone heard 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 actually just did that! It might sound a bit silly, but a good programmer knows how to be more objective and accept the fact that testers have to do terrible things to their code, because, if they don’t, someone else will definitely do it!
Often the developers don`t know how their code is going to 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 positives scenarios of how to make things work efficiently, they often lack the ability to switch to “what can go wrong” mind state. From here, another thing that we 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 start to understand each other better, they can learn to work together. This is a progress and at the end, only by working together, they will reach their common purpose.
As humans, we`re going to make mistakes, it’s what make us humans, and most of the times, the most effective way of learning is from a mistake. Often it is much easier to detect a mistake in the work of someone else than to see it on your own. That’s why developers and testers complement each other.
Both do mistakes. It is not important who does most of them. What is truly important is that they find the solution to fix 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 in the same team and they fight for the same purpose: To deliver a Quality Product!
The real never-ending battle is to deliver a Quality Product!
This article is written by Programming Pool.