As a test engineer, the development engineer in the team is of course the one who has the most contact in daily work. How to communicate effectively with the development engineer is an important issue faced by the test engineer.
Generally speaking, on a team, there are always test engineers that developers like and dislike, and there is a big difference in productivity and effectiveness between the two. Of course, it cannot be arbitrarily said that test engineers who are not liked by testers are necessarily inefficient or unqualified test engineers, but generally speaking, those engineers who are easily recognized by developers can always be better when testing. Find bugs well and push developers to fix them. Test engineers and development engineers are responsible for two different aspects of development work. To put it to the extreme, one is creation and the other is destruction. Although the ultimate goal of both is the same, there are differences in the way to achieve the goal. big difference. Therefore, in the process of striving for the same goal, conflicts are inevitable, but through the following suggestions, looking at the life and work of developers from a different perspective, many conflicts may be resolved invisible.
Cem Kaner has a passage in "Testing Computer Software": "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." A good tester is not the one who finds the most bugs or makes the most developers uncomfortable, but the one who can [convince developers] to fix the most bugs), I suggest you understand this sentence well.
As for me, I changed from a development engineer to a test engineer, and I have a personal experience with the situation and ideas of a development engineer. Perhaps this is the reason that made my communication with the development engineer relatively smooth. They get along just fine too. In my testing experience, I have also come into contact with quite a few development engineers. Here I summarize the experience of communicating with developers as "five musts and four nos":
[Five musts]
1. Be patient and careful
Carefulness is a basic quality of a test engineer. A test engineer is a person who is responsible for quality. When it comes to quality issues, they cannot be vague. Therefore, you must be careful, treat every possible bug carefully, and treat every piece of code that is checked by you carefully. Be careful with every bug report you write and every email you send. Carefulness is an attitude, and sooner or later your attitude will infect the developers you work with, and this is often the basis for a pleasant cooperation. As for patience, in my work experience, I take the trouble to explain a bug to a developer and let him realize the importance of the bug is a regular thing. In fact, it is normal to think about it. For anyone, being pointed out One's own shortcomings and deficiencies are not comfortable things, therefore, a little impatience may cause great resentment to the other party and bring unnecessary trouble to one's own work.
2. To know how to respect each other
Development is a work that requires comprehensive and comprehensive consideration. During development work, it is normal for problems to occur in the program due to various reasons. As a test engineer, finding these problems is not worthy of your boasting, nor does it mean that you are better than you. Developers are smart. A good test engineer must know how to respect development engineers, respect the technical level of the other party, and respect the code of the other party. The developers I've dealt with are very nice, and generally speaking, the greatest respect for them is to acknowledge his level of expertise and acknowledge his code. (To them, the code is like their own child :) So remember to show your respect and praise the subtleties of his code when the time is right.
3. Be able to put yourself in the other person's shoes
Development engineers are generally under great work pressure, and their supervisors directly assess their indicators to a large extent on the completed code. Therefore, when the work task is tense, the bug reported by the test engineer will be delayed or even solved. It is a shirk, and the feeling to the test engineer is that it is very uncooperative. Then at this time, you need to put yourself in each other's shoes. Everyone will prioritize their own work. If he thinks that solving the bug you found is not an important thing, then the biggest possibility is that you did not ask for it. He explained the severity of the bug. Finding bugs is our responsibility, and urging them to be resolved is our more important responsibility, so we can sit down calmly with the developer to discuss the severity of the bug, and work with him to prioritize and fix the bug. .
4. Have principles
Don't forget that test engineers need to be responsible for the quality of the product, and there must be principles in this regard. Test engineers can establish a good personal relationship with development engineers, but in specific matters, they must be handled in accordance with the company's relevant procedures. Of course, while adhering to the principle, you can use some euphemistic expressions, and try to be considerate to the development engineer if allowed, but please remember that a principled test engineer can really help the development engineer and win the respect of the development engineer. .
5. Be proactive
If the development engineer asks you to take some responsibilities that do not belong to you, for example, to locate the bugs you found to the code level, or to help him write part of the documentation and code (don't believe it, there is such a thing), then you will How to do it? In my testing experience, I have encountered these things, and my principle is to take as much as possible. In fact, it’s all about work. If you have the ability, it’s okay to do more. Of course, there must be some people who disagree with my opinion, and I don't want to argue here, it's just my personal opinion, just for reference :) In my testing experience, I will provide as much information as possible according to my own progress and schedule. BUG's reference opinions are even located at the code level. This method is not a formal method, but it is very beneficial to improve the degree of trust. But when you take the initiative to undertake, you must make it clear that you can undertake it only when you really have the spare capacity, otherwise, declining is the best countermeasure.
[Four nos]
1. Do
n't laugh at the bugs you find, even if it's a very stupid mistake, don't laugh at it, maybe that mistake was made by the development engineer working overtime for 24 hours, and the work of others should always be respected . If you feel the need to remind him to stop making some common mistakes, you can do this: write a document of common mistakes developers make during testing (remember, never write who made these mistakes ), tease it in a light-hearted tone, and send it to the developer. I have used this approach, and developers are quick to accept it.
2. Don't comment on the development engineer behind your back.
Never comment on the technical ability of the development engineer behind your back. This is definitely a very taboo thing. You may never be able to cooperate well with him if you talk too fast for a while. What an engineer cares about most is what others say about his technical ability. In fact, this is not only a criterion for being a test engineer, but also a criterion for being a human being.
3. Don't use the upper layer to suppress the opponent
When there is a disagreement with the other party, what method should be used to persuade the other party? It is of course a way to ask for help directly, but the negative side effects of this approach are also obvious. First of all, the result of the upper-level processing may not necessarily meet your wishes (in many companies, the status of development engineers is higher than that of test engineers). The status of this kind of inequality leads to a certain bias in the handling of differences at the upper level); secondly, the use of the upper level to suppress the other side can only leave a useless impression on others. So when there is a disagreement, try to solve it through communication as much as possible.
4. The communication with developers is not only about bugs
. In addition to the bug record sheet, let the development engineers who work with you contact you in other places:), chat with each other more during lunch or group activities, a On the one hand, it can enhance each other's feelings, get familiar with each other, and it is convenient to deal with; on the other hand, from him, understanding the knowledge of the business and all aspects of the modules he is responsible for is also an improvement for himself. I personally like to communicate with development engineers. In fact, development engineers are generally more talkative, especially for the subtleties of their own programs. It is always beneficial to know more about them and get in touch with them more.
After writing so much, in fact, the key is two points: think more from the perspective of others, the so-called "transpositional thinking", if you respect the other party more, you will definitely get the respect and cooperation of the other party; the second is to strengthen the communication with development engineers, Let him clearly understand the value of your work to him and the importance of every bug you find. I have always believed that a good test engineer must be a happy person who is respected by everyone in the company, and should not be a "hard-faced judge". Of course, as a person, I absolutely dare not say that what I have done is already very good, but I often remember to remind myself: respect each other.