Five reasons why developers are not good testers
Why developers are so frustrated with testing? Why there are so many discussions, and, what is more important, memes on the net like Tester vs Developer? YES, there is a reason, or more precisely, several of them. Today, QATestLab presents 5 main points why developers are bad testers.
Let’s face it: programmers don’t always get along with testers, and it’s quite logical. At first glance, they want one thing, but eventually, they use diametrically different methods. Some build, others break. Software developer plans and tries to predict several steps forward. Does a tester plan? Of course, yes. But with an approach like “Carthage must be destroyed”.
Why then one person is unable to combine these two approaches? Why the developer can’t be a good tester for his product? Here are the most vivid reasons:
#1 – We see the failings of others but are blind to our own
It is extremely difficult to evaluate something related to us or the product of our activity. Even more difficult is the task of pointing out the disadvantages. A similar story is with developers and their code. Developers are vehemently confident in the correctness of their code, and often do not consider the necessity to allocate enough time to test it in all possible directions.
The result of the absence of efficient quality engineering is obvious – small or even far from small bugs remain unnoticed, and then we face the collapse of whole functionality. In such a case, most likely the user will find a more convenient alternative and refuse to use the product like this. Is it then appropriate to ask the rhetorical question ‘why?’.
#2 – Vision (Developer has the vision of the creator, the tester has the vision of the user)
The developer actually makes a product, which often requires analytical thinking and performing complex tasks. Developer discerns and analyze each complex task and simplify it into smaller tasks. So, the developer has his own view on the product which is a transition from large to small elements. The tester has the opposite side, from small actions – to the final goal – from clicking on the button to the fact that this click brings the user to a specific action.
Why the tester’s approach to product testing is more effective? First and foremost, QA testers rely on the user’s scenario. This means that such testing will become more effective and closer to real scenarios of user interaction with the software. Moreover, one of the components of the quality assurance test is to take into consideration complex scenarios to find bugs. So, assurance professionals take simple things and come up with how it can be complicated.
#3 – Scenarios: Positive and negative
Programmers approach their work with a positive scenario: they think over how to make something work, create an abstract idea and then push the code into the action for it. Again, they take a complex process or project and break it down into smaller components in order to find a solution to the problem.
Quality assurance professionals do exactly the opposite things – they are focused on negative scenarios, or more precisely on how to break things down.
#4 – Inability to see small details in the big picture
And again, the tester is a certain mindset. The tester is focused to notice defects and errors. Develop can also do the same thing, but in his head, there will always remain what he wrote. The vast majority of programmers think roughly like this: “Why should I check this out? I just put an exception there” and so on.
#5 – Experience (lack of experience with typical bugs and software bugs)
Probably one of the most compelling reasons from this list. While the style of thinking and the approach to work can be changed, knowledge is a thing that comes with experience. For example, knowledge of typical bugs is what the tester is fluent in. An experienced tester sees the form and immediately begins to think about what typical bugs there may be hidden and what therefore can be tested in the first place. What do developers do in a situation like this? They give a shot in the dark, isn’t it?
Conclusions
Developer and tester are different species with a different set of skills. At the same time, they are ordinary people who can be wrong. But each of them can be wrong in their own way. One way or another, developers cannot be testers in the classical sense, but they can make a significant contribution to the testing process using their development experience.
Testing is a separate skill and that’s why the majority of developers are frustrated. Imagine you have an 8-hour job, and you switch between coding and testing during. You also switch into managing, discussing, talking, prioritizing, and so on. It can be a schizophrenic experience. It’s like constantly switching between your left and right hand, and statements like I’m good, I’m bad, I’m good, I’m bad…
To wish to combine the testing and development process is to wish the impossible things.
Have something to add? Feel free to give your opinion in the comment section below. Visit our blog to learn more about Quality Assurance / Quality Control processes. Welcome to follow us on Facebook and Linkedin.
Learn more from QATestLab
Related Posts:
About Article Author
view more articles
No Comments Yet!
You can be the one to start a conversation.