Live as a tester with a programmer

Often they ask the question: what to do with the fact that programmers do not like testers, consider their work as secondary, write carelessly - “they will check it all the same” or take revenge for every bug found and try not to recognize them for bugs.
Or vice versa, programmers complain that testers gloat when they find a bug, and consider it a personal achievement if the programmer has made a lot of mistakes.

The standard advice in such cases: explain, make peace, argue - it looks as if programmers are justified by the existence of testers. After the fact, to solve such a problem (and this is a very critical problem) is very difficult. You need to lay the right atmosphere when building a team and wear this right attitude to work for yourself from team to team, from company to company.
')
Do you know what the chip really is? In the difference of goals! Simply described by testers and programmers go to work not for the same, not for the same purpose. They do not have an atmosphere of work in one direction. They have no understanding of what they are doing, in fact, the same thing, only from different sides.

Of course, everyone works for the sake of different things: someone for the sake of wages, someone for the sake of solving interesting problems, someone for gaining invaluable experience. But to achieve personal goals you need to work towards the goals of the project, product, company. Then there will be a salary, and experience, and interesting tasks. Judge for yourself if the goal of the programmer was to produce a quality product, the success of the project, the prosperity of the company, and he worked for it, then it would just automatically work for his personal goal. And in this situation, it will never sound “this is not a bug,” because any suspicion of a bug by such a specialist is accepted and considered.

Right now, I look out over Canadian Formula 1 Canadian Grand Prix.

A phenomenal example of well-coordinated, one-way teamwork. There are 2 parts of the team: in fact, a performer, a pilot, a man who is in full view, who reaps laurels in the eyes of the public, but who speaks at each press conference about the work of the whole team, and there is the same rear team who looks at his work on the track, analyzes it and says into the headset: “Kubica changed the tires to hard, Barrichello too, do not let yourself get around.” And now imagine that the team catches the pilot's mistakes and gloatingly informs him “Due to the fact that you did not change tires at the last pit stop, you lost 2 seconds during the rain.” As soon as parts of the team begin to work against each other - it is doomed to failure!

Let's look at the development team. We clearly need a classification. At first, I wanted to call the described characters Good Testers (or Programmers) and Bad Testers (or Programmers). Then I thought that then in this world there will be a lot of bad things, and this is not so. Therefore, I will have Just Programmers (or Testers) and Right Programmers (or Testers).

Signs that your programmers and testers are not correct:

- from testers seriously heard the phrase "nakolbasil them bugs, let them rake now"

It comes from senior testers and from the general atmosphere in the team. I have not seen a single inexperienced tester who would have thought so from the very beginning.
If the older colleague wants to grow up an evil monster who rejoices when finding a bug, not because the user now gets one less error, but because they annoy the programmer, then he should continue in the spirit of “Come on, son, show these coders what kind of poop they would have let out without us. ” But if he wants testing to work not against programming, but together with him on the quality of the product, and behaves accordingly, then there will never be such a team on his team.

- from programmers too often sounds contempt "this is not a bug"

This means that every bug is perceived as a personal poke: “This is your personal mistake, do you hear? You are a layman. Good programmers write without errors, and you did a bug, oh, you. " I think that here problems should be sought in the personality of such a specialist. Adequate person aimed at development, uses any criticism for improvement, not for offense. Moreover, when one criticizes a work, it is perceived as a disease when it is perceived as personal criticism.

- the programmer does not check the result of his work before passing to testing

“My business is to write code, and to check their business,” “Well, and why did you have to understand them?” Can be heard in such commands. This elementary lack of hygiene, work for the sake of "unsubscribe." Where have you seen a journalist who does not reread his article before submitting it to the editor? If there is a programmer in the team who preaches such an approach, it should be eliminated as soon as possible. Whatever he was a cool specialist.

- testers add bugs, not interested in their further fate

This is the “bullet shot from my side” position on the other side.
The purpose of testing - to find as many errors in the application, of course, has the right to life at certain stages of testing. Only in this definition is missing the second part. To fix. The power of testers to convey the importance of important bugs to programmers and honestly say about the low priority of low priority. If programmers know that their testers will not deliver a good priority, then they take every such bug seriously. But a massive attack with bugs without interest in their further fate, without advancing towards facilitating their localization, is really the result of working only on themselves.

- the effectiveness of the testers' work is measured by the number of bugs found, and the measure of the quality of the work of programmers depends on this

This is the first step that pushes good specialists and quite good (I'm sure) people to squabble at work. If work is not measured by the final quality of the product produced, but only by quantitative indicators of work, then people will work for quantity. Testers to increase, programmers to reduce.

At that time, as soon as the approach “to find the maximum and the same maximum neutralize” is effective, in my opinion, it really works on the product's goal.

I am sure that the list can be continued.

At the same time, feel? In the first and fourth cases, the root of the problem is in Simply Testers, in the second and third - in Simply Programmers, and in the fifth - in Simply Managers. Caught in one of these teams, the first thing you need to understand from whom comes this virus and eradicate it. Or leave. Because productive work still will not work.