Combat between test engineers and development engineers

As a test engineer, the developers who have the most contact in daily work are of course the development engineers in the team. How to communicate effectively with the development engineers is an important issue facing the test engineers. In general, there are always developers who like and dislike test engineers in a team. The efficiency and efficiency of both teams are very different. Of course, it cannot be arbitrarily said that testing engineers who do not like them must be low-efficiency testing engineers, or unqualified testing engineers. However, in general, engineers who are easily recognized by developers are always able to better discover and urge them to solve the defects during testing. Test engineers and development engineers are responsible for two different aspects of the development work. To put it bluntly, one is creation and the other is destruction. Although the two have the same ultimate goal, however, there are great differences in how to achieve the goal. Therefore, conflicts are inevitable in the Process of striving for the same goal. However, with some suggestions below, let's look at the lives and work of developers from a different perspective, there may be many conflicts that can be resolved in an invisible way. In The book Testing Computer Software, Cem Kaner said: "the best tester is not the one who finds the most bugs or who embarrasses The most developers. the best tester is the one who gets the most bugs fixed. "(the best tester is not the one who finds the most bugs or makes the most developers uncomfortable, but the one who can [persuade the developers] Correct the most bugs ), we recommend that you fully understand this sentence. As for me, I switched from a development engineer to a test engineer. I also had some personal experience on the situation and ideas of the Development Engineer, maybe this is the reason, it was quite smooth during my communication with the development engineers, and I got along well with them. In my testing experience, I have also met a considerable number of development engineers. Here I sum up my experience with developers as "five to four ": 1. Be patient and careful Being careful is a basic quality for test engineers. test engineers are responsible for quality. When quality problems are involved, they cannot be vague. Therefore, be careful, treat every possible BUG, every piece of code you check carefully, every BUG report you write carefully, and every email you send carefully. Carefulness is a kind of attitude. Sooner or later, your attitude will infect developers who work with you. This is often the basis for a pleasant cooperation. Speaking of patience, during my work experience, I took the trouble to explain a BUG to the developer, so that he realized that the importance of the BUG is a constant thing. In fact, it is normal to think about it, it is not comfortable for anyone to point out their shortcomings or shortcomings. Therefore, an impatient mood may cause a lot of dislike, this makes your work unnecessary. 2. respect each other Development is a task that requires comprehensive and comprehensive consideration. during development, it is normal for the program to have problems due to various reasons. As a test engineer, discovering these problems is not worth your boast, nor does it mean that you are smarter than development engineers. A good testing engineer must be a person who knows how to respect development engineers, the technical skills of the other party, and the code of the other party. Developers I have been familiar with are very kind. Generally, the greatest respect for them is to acknowledge his professional skills and his code. For them, the code is like your own child :) so remember to express your respect for him at the right time and praise the subtlety of his code. 3. Put yourself in the shoes of the other party Development engineers are generally under a lot of work pressure, and their superiors directly assess their indicators to a large extent is completed code, so when the work is tight, the BUG reported by test engineers may be solved or even put off. The test engineers feel that they are not cooperative. At this time, you need to put yourself in the shoes of the other party. Everyone will prioritize their work. If he thinks that solving the bugs you find is not important, the biggest possibility is that you have not explained to him the severity of the BUG. It is our responsibility to discover bugs and to urge them to be resolved. Therefore, we can calmly discuss the severity of bugs with developers, work with him to prioritize bugs and determine the time to resolve them. 4. Principles Do not forget that test engineers are responsible for the quality of their products. There must be principles in this regard. Test engineers can establish good personal relationships with development engineers, but they must follow the company's related procedures on specific matters. Of course, while adhering to the principles, you can adopt some euphemistic expressions and try to be considerate of development engineers if allowed, but remember, A principled test engineer can truly help the development engineer and win the respect of the Development Engineer. 5. Take the initiative If the development engineer asks you to assume some responsibilities that are not yours, for example, locating the BUG you found to the code level, or helping him write some documents and code (don't trust it, so what will you do? I have encountered these things in my testing experience. My principle is to take as many responsibilities as possible. In fact, it's all about work. If you have the ability, you can do more. In my testing experience, I will provide as much reference about bugs as possible based on my own progress and schedule, or even locate the code level, this is not a formal approach, but it is very helpful for improving the degree of trust you have. However, when taking the initiative, you must make it clear that you can take the initiative only when you have the right to accept it. Otherwise, decline is the best countermeasure. 【4id] 1. Don't laugh at it Don't laugh at the bugs you 've found. never laugh at even stupid mistakes. Maybe the mistake was made by a development engineer who had been working overtime for 24 hours. Always respect others' work. If you think it is necessary to remind him not to make mistakes frequently, you can use this method: compile a document that developers often make mistakes during testing (Remember, do not write down who has made these mistakes.) Send it to developers in a relaxed tone. I have used this method and developers can accept it quickly. 2. Do not comment on development engineers behind the scenes Never comment on the technical capabilities of development engineers behind the scenes. This is definitely a very taboo thing. The speed of your tongue may make you no longer be able to cooperate well with him, development engineers are most concerned with others' comments on their technical capabilities. In fact, this is not only the principle of testing engineers, but also the principle of human beings. 3. Do not use the upper layer to suppress each other. When there is a disagreement with the other Party, how should we persuade the other party? Directly asking for help at the upper layer is of course a solution, but the negative side of this solution is also obvious. First, the processing result as the upper layer may not necessarily meet your wishes (in many companies, the Development Engineer's position is higher than that of the test engineer, which leads to a certain bias in the upper layer when dealing with the differences ); second, the upper layer is often used to suppress the other side and only leave a useless impression on others. So when there is a disagreement, try to solve it through communication. It is not enough, and then use the final means. 4. Communicate with developers not only about bugs In addition to the BUG record, you can also contact your development engineers in other places. :) chat with each other during lunch or group activities, on the one hand, it can enhance mutual feelings, get familiar with each other, and make it easy to deal with each other. On the other hand, you can learn business knowledge from him and all aspects of his module, and improve yourself. I personally like to communicate with development engineers. In fact, development engineers are generally quite talkative, especially those who are more familiar with and have more contact with their own programs, it is always beneficial to you. After writing so much, there are actually two key points: think more from the perspective of others, the so-called "empathy", more respect for the other party will certainly get the respect and cooperation of the other party; the second is to strengthen communication with development engineers so that they can clearly recognize the value of your work to him and the importance of every BUG you discover. I always think that a good test engineer must be a happy person who is respected by everyone in the company, rather than an "ironclad judge" :) of course, as I personally think, I never dare to say that I have done a good job. However, I often remember to remind myself that I respect each other.