How to Write test reports

 

ArticleSource: http://www.clover.ewyu.com/user1/liqiuming/archives/2006/5588.html

Recently, I have benefited a lot from the software testing experience and lessons learned co-authored by CEM Kaner, James Bach, and Bret pettichord. Therefore, I will share it with you based on some of the content in this article, hope to achieve the purpose of knowledge exchange and sharing. If you are interested, you can also read the original book.

The test report is the main means for the product department to communicate with the technical department. The quality of the test report directly affects the bug modification speed andProgramPersonnel's mood. If you study and write a report, all those who read the report will benefit. Therefore, I have compiled and compiled this article, hoping to help the product department and the technical department.

I. Principles of defect reporting

1. Some errors will never be corrected. The tester's responsibility is not to ensure that all errors are corrected, but to accurately report the problem so that the programmer can understand the impact of the problem. In-depth research and writing of good reports often have a huge impact on the possibility of incorrect correction. 2. Report defects in a timely manner. Do not report program errors until the next day or next week, and do not wait until you forget some key details. The longer the delay, the less likely the program error will be solved. 3. Each program error must be reported separately. Do not try to merge different program errors into the same report to reduce the constant complaints from project managers or programmers about repeated error reports. If multiple program errors are written to one report, some errors may not be modified. 4. Small defects are also worth reporting. A small error may confuse the customer and reduce the customer's confidence in other parts of the product. Small defects may include misspelling, small screen format problems, mouse relics, and small computing errors, incorrect image proportions, online help errors, inappropriate gray menu options, ineffective shortcut keys, and incorrect error messages, and other Programmers think it is not worth the effort to modify the defects. 5. Strive to make error reports more valuable. Since many people have to read and rely on error reports, it is necessary to enrich the information of each error report. Improve report comprehension. For example, A. Clearly list the preconditions and implementation steps of the Error Report to avoid language confusion. It should only be described, do not try to give programmers a solution in the process of generating errors. This makes the error report lengthy and difficult to understand. If there is a good solution or suggestion, you can attach it to the error report description. B. Always maintain a neutral tone. C. Do not joke. Otherwise, misunderstanding may occur. 6. Always report non-reproducible errors. Such errors may be time bombs. Non-reproducible errors may be the most expensive defects the company can pay. Sometimes errors cannot be reproduced. I saw a program error once, but I don't know how to make it appear again. If this happens to the product delivery customer, the customer's confidence in the product will be affected. If the technical support staff needs to evaluate the customer's data or environment for a long time, the customer will get bored. If the tester clearly reports error signs, the programmer may learn how the tester gets specific messages, or when the tester views a dialog box or clicks a specific control. To be able to trackCodeI believe that programmers can correct 20% of the "non-reproducible" defects in the report. However, when reporting such bugs, you must make it clear that you cannot reproduce the program errors.

Ii. Precautions for the defect report

1. Be careful when referencing others' error reports. If you do not have the permission of the person who submitted the error report, you can add comments, but cannot edit others' materials. Do not modify the error reports of other testers even if they are terrible. At any time, you must add your own name and date to the error report. 2. Seemingly extreme defects may be potential security vulnerabilities. For example, if one is expected to accept one 1 ~ If you enter 65536 9 in the 99 field, the program will crash. Will someone really do this? Yes, of course someone will. Some people will think that "If someone is stupid enough to do this, program crashes will teach him" and ignore this error, but in fact the idiot is not the only one who abused the program. Any problem that may cause serious consequences should be solved, no matter how "impossible" It may occur. When skilled attackers exploit defects in the program, they will write the message and spread it widely, so that all of their new users can use scripts. 3. immediately decide to appeal against the delay of program errors. If the decision is justified, it is necessary to win. If the tester has opinions on how to handle a bug and does need to appeal, do not rely on the language and information in the original error report. The report cannot be changed, but the tester needs to list more effective examples, the tester needs to communicate with related personnel of other product projects and conduct some subsequent tests to find more serious errors that may occur in the program. Every appeal made by programmers must be convincing. Even if you cannot win all appeals (of course you cannot win all appeals), you should be well known to have won all your appeals.

At this point, the terms listed above are closely related to our actual work. I hope you can use this article to read all the content of this book, which will certainly benefit you a lot.