As a test engineer, it is of course in its daily work. It is of course the development engineer in the team, how to conduct effective exchanges with development engineers is an important issue in the face of testing engineers. In general, in a team, there are always developers who like and dislike test engineers, the work efficiency and effects between the two are very different. Of course, the test engineer who cannot be arbitrarily said that the test engineer who does not like is a low efficiency test engineer, or it is unqualified test engineer, but in general, the engineers who are easy to get developers can always be more It is a good discovery that defects and urges developers to solve defects. The test engineer and the development engineer bear the two different aspects of development work, and the extreme is extreme, one is creation, one is destruction, although the end of the two is the same, but in the way of achieving the goal is very Large difference. Therefore, in the process of struggle for the same target, it is also inevitable, but by some of the suggestions, change to the development personnel and work, there may be many conflicts can be resolved. Cem Kaner has a paragraph in the "Testing Computer Software" book: "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 Bus Fixed." Good testers are not discovering up to BUG or make people who are unable to develop people, but can [persuverse developers] to correct the most bug people), I suggest you understand this sentence. As for my personal, it is a development engineer to test engineers. It has had some experience in the development of engineers, and may be this reason, let me have a relatively smooth in the process of communicating with the development of engineers, and They are not bad. In my test experience, it has also been exposed to a number of development engineers. Here I am attributing the experience of communicating with developers as "five need four do not": 1. Be patient and careful is a basic quality, test of test engineers. Engineers are people responsible for quality. They can't be vague, so they must be careful, carefully treat each possible bug, carefully treat each piece of code that is checked by you, carefully treat every bug report you wrote, Carefully treat each email you sent. Attitude is an attitude, your attitude sooner or later will infect and work with you, and this is often a pleasant foundation. As for the patient, in my work experience, I redeemed a bug to developers, so that he realized that the importance of BUG was often the matter. In fact, I thought it was normal. For anyone, I was pointed out. It is not a comfortable thing that is not comfortable, so a little impatient mood may cause the other party's great disorder, bringing unnecessary trouble to her work. 2. To understand the development of the other party is a comprehensive and comprehensive consideration. In the development of work, due to various causes, the problem is very normal, as a test engineer, found that these problems are not worthy of you You can't explain that you are smarter than the development engineers. A good test engineer must be a person who knows to respect the development engineer, respect the other's technical level, respect the other's code. The developers I have touched are quite good. Generally, the biggest respect for them is to recognize his professional level and recognize his code. For them, the code is like a child :) So, remember to express your respect for him when it is right, praise the exquisiteness of his code.
3. It is necessary to set up the place to develop engineers to develop engineers. Under a large work pressure, his boss directly assesss their indicators to be completely completed, so when the task is nervous, for the test engineer The reported bug will delay solve even off, the feeling of testing engineers is very uncomfortable. So at this time, it is necessary to set up the other party, everyone will schedule a priority for their work, if he thinks that the bug you discovers is not an important thing, then the biggest possibility is that you are not He explained the severity of this bug. Discover BUG is our responsibility, urged BUG to solve our more important responsibility, so we can discuss the severity of the bug and determine the priority level of BUG and determine the time to determine the time to determine the time. . 4. Don't forget the principle, test engineers need to be responsible for the quality of the product, and must have principles in this point. Test engineers can establish a good personal relationship with the development engineer, but in a specific thing, be sure to process according to the company's related process. Of course, while adhering to the principle, some euphemistic expressions can be used, which can be considerate as much as possible to understand the development engineers in the case, but keep in mind that a principled test engineer can truly help develop engineers, in order to win the respected of the development engineers. . 5. To take the initiative to assume that if the development engineer asks you to bear the responsibility of your part, if you locate the bugs you discovery, or help him write some documents and code (don't believe, there is such a thing. So what do you do? In my test experience, these things have encountered, my principle is to be borne as possible in the case of possible. In fact, it is a matter of work. If you have the ability, do more. Of course, there is certain that some people don't agree with my opinion. I don't want to argue here, personal opinions, for reference only :) In my test experience, I will provide more as much as possible according to their progress and time. Bug's reference, even positioned to the code level, this method is not a regular way, but it is very beneficial to improve the degree of trust. But when you take the initiative, you must be clear that you can do it if you do have a lot of effort, otherwise you will refuse to be the best countermeasure. [IV] 1, don't laugh at the bug you discovered, even if it is very stupid, it is absolutely not to laugh, say that the mistake is because the development engineer contact overtime is committed 24 hours, and the work of others should always respect. . If you feel that it is necessary to remind him that there is no longer commit to some frequent mistakes, you can use this way: writing a developer discovered in a test process (remember, don't write anyone who made these mistakes ), With a relaxed tone, send it to the developer. I have adopted this method that developers can accept it quickly. 2, don't comment on the development engineer, you will never have a technological ability of the development engineer, this is absolutely a very taboo thing, the time, the faster, the tongue will make you never cooperate with him, you must know, develop Engineers are the most essentials that others have evaluated by his technical capabilities. In fact, this is not only the guidelines for testing engineers, but also the guidelines for people.
