Test how to effectively persuade research and development to modify bugs ...

Problem Description: Some bugs in the test process are considered to be invalid bugs, but from the user's point of view, the test believes that the bug needs to be changed, and then the test is more effective to persuade research and development to modify the bug.

Wonderful answer:

1. Reverse the idea of research and development leadership, improve the response speed of researchers:

a). Let the leadership of the research and development team focus on defects:

Many of the leaders of the research and development team are born, have little knowledge of technology, and they are obviously different from the idea of doing technology. I was in the first company, the release of a lot of times, are not testing the end, the function of the development of the product sold, and then the version of the continuous upgrade, the result of this company in about 3 years before the split up. Behind a company's leadership is to do quality management birth, obviously to test the quality requirements are not the same, each request is very strict, the previous test to complete the standard has made further changes. If the leader ignores the flaws, do you think the developers are willing to spend a lot of effort to modify the bug? So, the idea or consciousness of a team leader plays a very important role in the revision of the defect. I remember the previous Test Master Zhuzx also mentioned in a weekly question, we can also learn from.

B. Use of commonly used defect management tools (QC9.0) to improve the transparency of defects:

Our company uses the Defect management tool (QC9.0), the test Manager as the administrator, to the company's top leaders, project managers, development managers have assigned permissions, they can log in to the system to query the relevant information. At the end of the test, especially before and after the release of the release, the leaders are free, and also at any time to go to browse a, unconsciously exert greater pressure on developers. If this time there are many open flaws, developers naturally dare not snub.

C. The response speed of the developer's modification flaw is recorded in the Performance appraisal content:

Because the company director of special attention to product quality, our company to defect modification This is better, each time the defect is submitted, developers respond particularly quickly. If you have questions, talk to the tester one at a time and fix or fix the defect as soon as possible. Our company's slogan is: "would rather spend 100 times times the price, do not let the defects of the discovery to the customer." Another point is the developer Performance Review, we testers to the developer rating, it is important that the developer of the test defect response speed, if this is very low, the boss wants to talk to you, ask the specific reasons. Oh. Therefore, our company has few testers chasing the development of modified defects, the response rate to modify the defect into individual performance assessment, I personally feel is a better way, it is worth learning or promotion.

2. The establishment of a reasonable research and development team, standardize the test specifications:

A) The key is to establish a sound research and development mechanism:

In most cases, whether the software defect or need not to change, how to modify is not the test staff and developers to decide, should rely on the research and Development Department of the relevant system or related departments to constrain. After all, in the domestic software software companies lack such a department, so that the responsibility to modify the defects related to the test personnel on the head, in fact, the tester is too unfair. To solve this problem, the most important thing is to establish a sound research and development mechanism, so that QA and other relevant departments to urge to solve such problems, better.

B. Distinguish the specific responsibilities of team members:

For each member of the research and development team, the responsibility must be clear, otherwise, such as the supervision of defect modification such things are not the tester's responsibility, are now pushed to the head of the tester. Very depressed.

c). Perfect the test specification and make the bug management system clear:

Most of the companies do not have separate departments to manage and supervise whether the defects are modified, are specified think it is the test department. The best thing to do is to give the project team the qualifications they need to deal with the trivia. Often encountered such a situation, a lot of controversial defects have been put to the later version, a period of time down, several versions of the disputed defects more than 100, make the later version is not easy to release. Our practice is that the release of a few days before the issue of each dispute by mail to the project team members first Look, the following in the holding of a defect review meeting, if passed, no doubt modified, otherwise closed or retained to the next version.

3. From the source to prevent the submission of invalid defects:

a). Refine test requirements before testing to avoid submitting ambiguous defects:

Many of the flaws in research and development that are not willing to be modified are caused by unclear requirements or ambiguous interpretations. So, the best thing to do is to start a project meeting before the test, refine the test requirements, let the research and development to confirm or team members collectively review, reach a consensus point of view. As far as possible to reduce understanding ambiguity, and strive to eliminate invalid or controversial software defects, to avoid submitting defects into a controversial defect. Testers cannot convince research and development to fix defects, and in the long run, the authority of the test department is greatly reduced.

(b). Not to grasp the defects, before submitting the best discussion:

Especially in the early stages of the test, because the test involved in the project time is relatively short, sometimes testers do not understand the business or the requirements, and submit the wrong bug is often the thing. This time, often test think that they submitted the correct, developers think that their development software is right, do not let each other, if not handled well, it is easy to can't get along relations, make everyone is not very happy. If such a bug happens in a project, it's hard to convince research and development to change it, and it could be a powerful evidence to develop a "pigtail" to scratch your back, which is harder to do later. Personal practices: All test defects are audited before they are submitted to the defective system to open, is the most insurance method.

C. Clear and unambiguous description of bugs, reduce random testing, and bring in a bug that is not reproducible:

Many times, testers to describe the defect is not clear or ambiguous flaws, developers can not understand, do not understand the specific meaning, coupled with the task of the developer heavy time, it is easy to reverse the heart, which let the developers of the test staff have views, the subsequent submission of the defect recognition is greatly reduced. There is the need to reduce random testing, it is necessary to ensure that the submission of defects can be repeated, it is best to have screenshots, pictures or digital cameras, so that developers realize that the problem is real and more convincing.

D. Do a good job of version configuration management to ensure the accuracy of the test environment:

Many of my colleagues have found that bugs are only reproduced in a test environment and cannot be reproduced in a development environment. Such bug developers are often invisible, and it is easy to conclude that the tester was rejected for submitting an invalid flaw, most of which found the version was wrong. The only thing we can do is to do a good job of source code configuration management, to ensure that the test environment version of the correctness and independence, to compile their own deployment test environment. Only in this way will reduce the submission of invalid defects, avoid the "trouble" to persuade developers to modify defects.

4. Correct analysis of the software defects in the test:

a). Prepare several sufficient reasons for each defect submitted:

In general, when we mention a bug, the developer will say a lot of reasons not to modify the defect, try to stall our mouths, ask us to turn off the defect or disable it or postpone it to the next version. If you're a bull, you can prepare enough excuses for each defect you submit to convince the developer. If you are not too strong, then you can turn to the Department of colleagues, focus on testing the strength of the team, think of some good, stand on the ground, the detailed introduction to the research and development personnel, as long as we submit the bug, each with persuasive words , I think they will change it as soon as possible. This method is really good, you might as well try.

B. A detailed analysis of the various possible impact or defect risks to the project arising from the defect:

For example, we submit a flaw if this flaw in research and development can be modified or may not be modified. We have to give the research and development analysis to modify the need for this flaw, do not modify, what kind of potential impact or risk to the customer. The cost of modifying the defect is measured against the relationship between the repair costs. believe that when we analyze the flaws in detail, the developers will certainly modify the bug.

5. Be a smart test engineer:

a). Attention and research and development personnel communication skills:

If the tester has not done the development work, the understanding may be more one-sided. Some testers, the problem is not patient, temperament is more urgent, is often the case. If there is no good communication skills, perhaps a few words of Kung Fu, and colleagues quarreled, making everyone more embarrassed. Personal suggestion: When talking, must pay attention to the communication skill, must have the way which the transposition thought, does the thing to the matter not to the person, handles the matter must have a tolerant heart. Only in this way can it be good to persuade research and development to modify bugs.

B. Do a good job of personal relationships with research and development, and do research and development audiences:

The more sensible testers must learn to listen to the minds of the developers. Most of the time, when a developer encounters a difficult job, he wants to give it to someone, and if the tester is his audience, then your relationship will be good. Do a good job of personal relations, the work of the defects you submit, they will not be so preoccupied, after all, the relationship is the foundation, the relationship is better, in China is so. If personal relationships are good, it's easy to persuade and develop a bug change. However, it should be reminded that the open flaw cannot be turned off because of the good relationship.

6. Seize the opportunity not to miss a once-in-a-lifetime good chance:

a). Help the top leaders of the company:

Most of the time, when the test comes to a later stage, the developer changes the bug as well, and the company leader (such as the Boss, the director, the project manager, or the development manager) comes to the test department at any time, looking for the test manager or the person responsible for the specifics of the project. If there are a number of issues are controversial, as a test leader you may wish to talk to the leadership, the more senior people pulled in for the test department to speak for the test department, but there is a degree, not too much, otherwise hurt colleagues and the gas.

b). Request Customer representative assistance:

Many GUI defects or can not be modified by the defect, may be used as a customer is not very convenient. We can talk to the customer representatives about such a flaw, if the customer representatives agree to do so, it is not a problem, can not be modified; If the customer disagrees, he will naturally directly to the project manager or senior staff to solve the problem, it is not our testers worry about. Because the customer is God, this is a good trick ...

I now think of so much, I hope that the peer correction ...

This article originates from 51Testing Software test network
http://bbs.51testing.com/forum-157-1.html