How does "test" handle bugs that are controversial with developers? _ Test Development written

At work, testers sometimes experience similar problems: A software defect report has been submitted, but for some reason, developers and development managers are unwilling to modify the program. How should this kind of problem be dealt with? In my opinion, when there is disagreement on the report, the test engineer should first do the following first to second step analysis:

I. Problem recognition and evaluation

Again, it is true that the problem is a procedural flaw and evaluates the importance of the defect and classifies it. For example, the following categories can exist:

1. Functional defects within the scope of the design document

2, affect the security and stability of the program defects

3, interface defects

4, general error (if not considered boundary inspection, etc.)

5, Edge Corner, the law is not obvious, not too easy to reproduce the error

6. Compatibility error (e.g. old model, CPU\MEM, old standard, etc.)

7, security or ease of use, such as the proposed changes

...... (extensible)

Ii. Clear Dev does not modify the exact reason for the defect

For example, you might have the following reasons:

1, the law is not obvious, not easy to reproduce

2, Dev is not affected by the main function of the general bug, because the time is in the version of the stable period, fear of pulling the whole body caused more errors

3, call the third party component or the library letter, is the third party procedure existence flaw

4, the existence of technical difficulties

5, the design itself has the problem, the program logic is correct, but the implementation results are not required by the user (in other words, Dev said this is a design problem, not a program problem)

6, Dev's personal subjective opinion:

• The flaw can be tolerated and no modification is necessary

• Modifying the flaw can cause a bigger problem

7, tester and Dev disagree on the wrong understanding:

Tester Understand the error, the problem is not a bug

Tester didn't convince Dev it was a bug.

...... (extensible)

Iii. specific analysis of specific problems

After the analysis of the first to second step, it is basically clear the issue of the focus of the dispute, and then concrete analysis of specific issues.

1. If Dev thinks it is bad to reproduce, tester has responsibility and obligation to find a more concise and effective recurrence rule.

2. If tester does not convince Dev that this is a flaw, it needs to demonstrate strong evidence (test cases, design documents, error phenomena, etc.).

3, for Third-party Library of the bug, or technical difficulties caused by bugs, then adhere to the principle-ningquewulan, if necessary, rather than sealing off the function.

4, for the wrong design, can not persuade the dev subjective understanding, change hidden trouble, as well as the stability period and other special circumstances, you can communicate through the TM.

Iv. play the role of TM and PM communication

Emphasis on communication

TM and PM are responsible for team communication. TM and PM have the responsibility and obligation to intervene when there are contentious issues in the bug classification, assignment, and feedback process. According to the importance of the problem and prioritize, to adopt different ways to communicate. If the emergence of "three" in the 3, 4 types of larger disputes, can be discussed in the form of meetings and other forms of argumentation, and reached a consensus to resolve the solution to form a memorandum of understanding.

For a variety of reasons to continue to remain in the release version of the bug, especially likely to affect the functionality, should be described to remind users to bypass.