Programmer! Do testers get on your nerves?

Of the enormous importance of software testing, no responsible programmer needs to be convinced. After all, it is better to prevent errors than to remove them from already shared applications. A large number of errors affects negatively not only the opinion about the product itself, but also adversely affects the brand of the manufacturer, not to mention the cost of removing bugs.

Is that why software developers are increasingly relying on test teams that developers have to work with? But the Problem is that even if the programmer understands the importance of tests, he does not need to understand testers. Unfortunately, he often sees them as opponents, or at least guys who do not know why, cling to everything and are just malicious.

So can the developer really get along with the tester? With the right approach-as much as possible.

Primary objective

The foundation of any agreement with the tester is the realization that he is not our enemy. Even if it’s an extremely annoying person, the sight of which raises your blood pressure, you need to change your approach. Treat the tester as an enemy, which must be defeated as soon as possible by all possible means. Otherwise, this is the easiest step to conflict in the team. It results in a waste of time, prolonged work on the project and a nervous atmosphere.

Of course. changing the approach to the tester is not easy. After all, in the sweat of your brow, you create code, solve complex programming problems, catch overtime, maybe even earn nights before deadlinem, and here comes a pompous tester who pushes his nosy nose into everything and gets smart. Only is it really the fault of the tester that you wrote the code with errors? Do not forget that you work in the same team, you are part of the same company and you have the same goal: to provide the client with high-quality software.

Communication, communication, communication

Often a big problem in cooperation between the developer and the tester is the lack of communication. You are not separate islands that will never meet. Sooner or later you will face each other: face to face or via e-mail, and then, probably, there will be a clash. Suddenly it turns out that what is a bug for the tester is not a bug from your point of view. The test you ran is not important to you at all, because the function works very well. The tester will probably have a different opinion on this.

All these misunderstandings could have been avoided if there had been good communication. Best talk to the person responsible for the tests before writing the code and discuss with her what will be tested. Set common priorities. Knowing what will be tested and how, you will be able to approach the code accordingly and avoid the snout with the tester.

Test your code first

The programmer must understand that the tester is not his babysitterwho will pat him on the head and take care of all the testing work, thus relieving him of this duty. If you want to avoid excessive frustration, resentment and the feeling that the tester is malicious, test yourself first what you wrote. That’s it. Your role is to identify problems, removing bugs and” finishing ” the code.

You need to understand that the tester is actually the last defense against giving the client software with errors. This is the last respect, which as a result cares about your reputation and prestige of the company in the eyes of product users. Understanding the specifics of the tester’s work changes the optics of the perception of testing professionals. Don’t make them look for errors, give them the opportunity to check the correctness of the code. Not by accident the best testers often say that they review software, not test. A small difference, but a significant one.

Errors in the code, and efficiency

Team effectiveness is critical to meeting client deadlines. Unfortunately, each cycle of finding bugs, fixing and re-checking the correctness of the software is associated with a longer work on the project. What if there are a lot of such cycles? It should not be surprising that such procedures take a lot of time, since it is necessary to perform many different actions: finding and reporting a bug, assigning it to a specific programmer for improvement, sending the code for re-examination, determining whether the bug has been fixed, and then marking it as a done deal.

Good cooperation between the developer and the tester also means that they can avoid formal procedures, which are very time-consuming and reduce the effectiveness of the team. Frequent contact with the tester, conversation, direct cooperation is a faster way to eliminate errors than limiting contact only to official procedures.

It is worth to co-create automated tests

The conflict between programmers and testers often stems from the fact that the latter are not … programmers. No, it’s not a matter of megalomania programmers – it’s about the right skills and knowledge. How many times have you been frustrated analyzing a bug report on your code when you knew it was working? Nevertheless, it turned out that the automated tests failed.

Unfortunately, sometimes the problem is that such tests do not pass because the tester did not write or prepare them correctly. You as a programmer see it right away and… you’re bleeding. The whole day is ruined. Is it not better to cooperate with testers in this field as well? Instead of experiencing frustration when reading an error report, it is better to help the tester create automated tests. Of course, it’s not about doing all the work for him, but about supporting him with programming knowledge.

When the tester does not want Agreement

Unfortunately, you may end up with a tester who doesn’t really want any agreement. No matter how much you reach out to him, he still has a negative attitude towards you. Not only that, every step of the way he tries to prove to you that your code is useless.

Why is this happening? There are many reasons-the tester may have some regret for you from the past, takes out frustrations on you outside of work, or feels like someone worse than the programmer. This last case is by no means rare. Perhaps this is a man who applied to the company as a programmer, and ended up as a tester. In this situation, of course, you could go to the confrontation. But why? Conflict is not good for you or for the effectiveness of your team. It is much better to bite your tongue sometimes, swallow your pride and admit that the tester is right, although, of course, this is not easy.

It often turns out that such a frustrated Tester needed validation or just a simple, human conversation. Soon he himself begins to understand the inappropriateness of his behavior, and even he is ashamed. And then he’ll reach out to you. Unfortunately, this does not work in every case. There are testers” unreformable”, with whom you have no chance to agree. The same goes for developers. However, in such a situation, you will not be able to blame yourself for not trying to get along.