How should testers report bugs?

      first, make sure that the problem you're discovering is really a bug, and don't get a "bug" caused by a tester operation error or misconfiguration, which reduces your credibility in the developer's mind. When testing, if you find that the actual results of the test and the expected test results do not match, do not worry about reporting the bug immediately, first think about why the error occurred. As a professional tester, you should be able to track the problems, confirm that the configuration, operation without errors, through the tracking analysis to confirm that the business process tested is a bug, and can probably locate the cause of the bug. Testers, need to do a professional, as little as possible to develop trouble, not to create a bug that does not actually exist. After confirming that the problem found is a bug, follow the test steps again to make sure the bug is reproducible rather than random. If the bug can not be reproduced, you should try to find the law of the bug recurrence, in some difficult to reproduce the problem can find the development of cooperation together to find the cause, if it is still unable to reproduce the problem should be described in the bug report and explain the occurrence of randomness. The next step is to fill in the bug report, when filling in the bug report, the most important thing is the title of the bug and the bug description. In the bug report, first a short description of the bug as the title of the bug, so that the development or project manager to see what is the problem, such as "XX module in the stress test 2 hours after the memory leak." In the description of the bug, it is necessary to use concise and accurate language to describe the test steps of the bug, the actual test results, the expected test results, and the conclusions; that is, what is the procedure that describes the action that caused the bug, what the test result is caused by the action of the test step, and what the expected result should be. and the actual result is relative to the expected result, which indicates the problem. For example: "Add users on the admin page, when the new user login name is very long (for example, the login length is the maximum length allowed by the input box), press ' new ' button added after the system prompts that the user exists, and the fact that the user does not exist, it is recommended to handle the long user name." "After testers have discovered an isolated, reproducible problem, they should summarize the problem. Whether the same problem occurs in other modules or other processes. Whether the same failure can cause more serious problems. If it exists, it needs to be proposed for development to be processed together. Once the bug has been developed, the test needs to be skeptical about verifying the problem, requiring rigorous testing in accordance with the test steps, checking that the development has corrected the problem correctly, and whether new issues will be introduced after the bug has been repaired. Do not believe that the development said "has been modified, certainly no problem" will notA detailed examination of the problem, if the development is not completely modified, the problem will still exist, or may be due to the development of the bug in the time when the omission of other details caused by the emergence of new bugs. Try not to close the bug, only to find that the problem has not been modified completely, and do not appear after the bug closed, a new bug has occurred. After the test verifies that the bug has been modified OK, close the bug. When you close, you should give a brief description of the result of the bug's final modification, and if the bug's modification causes changes to the configuration or database or business process, you also need to explain it in the bug closure description.