How to write better bug report
--- Mihir Kamdar "How to Write Better Bug Reports"
--- Kiki translation from 2006/6/18
Do we often see the developers provide more information about the bug report for our archive? Do we often need to study more time after Bug Report archive? Whether we often hear the developers to be difficult to reproduce bugs there and need to provide "reproducible steps"? In a broad sense, we spend more time to invest more time to test the system. The problem is in the mass of bug Report. Here you introduce some advice on how to improve and meet the perfect Bug Report.
Purpose of bug Report
When we find a defect, we need to tell it to developers. Bug Report is the media that is communicated. The main purpose of Bug Report is to let developers see this mistake. If you can't create that failed with him, you need to give them enough guidelines so that they can create that failed. Bug Report is explaining the gap between the desired results and the actual results and explains how to reproduce the scene.
After discovering defects
· Only when you are confident that you have found a bug, you start drafting bug report, don't end after the test is over or over. In that, you may have forgotten something. Worse, we may forget that bug.
· Take some time to diagnose the defects you are reporting. Think about the cause of possible. Maybe you will find more defects. Tell your discovery in your bug Report. Developers will be happy not only to make their work easily.
· Take some time before starting your Bug Report. You may feel like a re-write report.
Summary
The summary of bug report is the first impression of your bug report to the reader. The fate of the BUG you submit is largely dependent on whether your bug report can attract readers. The principle is that each bug should have a simple and interesting summary. It may listen to advertising activities that write a good job. But then there is no accident. A good summary should not exceed 50 to 60 characters. And a good summary should not carry any subjective expression to bugs.
Language
· Do not exaggerate defects in bug Report. Similarly, don't write too much.
· No matter how annoying BUG, don't forget that BUG is annoying, not developers. Never take the efforts of developers. Use euphemism. "Chaotic UI" can be modified to "incorrect UI". The efforts of developers will be respected.
· Maintain simple and honest. You are not writing a prose or article, so use a simple language
· Remember your target reader when writing bug report. They may be developers, other testers, managers, or in some cases, even customers. Bug Report should be able to be understood by all people.
Reproducible steps
· The process of "reproducible step" should be logical.
· Clear list of prerequisites
· Write the usual steps. For example, if a step requires a user to create a file and naming it, do not require the user to name "Mihir's File". It is best to name as the same file name as "Test File".
· "Reproducible steps" should be exhausted. For example, if you want users to save a file in Microsoft Word, you can ask users to go to the File menu and click the Save submenu item. You can only say "save files". But remember, not all people know how to save files in Microsoft Word. Therefore, finally follow the first method.
· Test your "reproducible step" in a clean system. You may find some steps that are missing or unrelated.
Test Data
Try to write ordinary bug reports, developers may have no authority to access your test data. If bug is related to a set of specific test data, it comes with it on your bug Report. Screen capture
The screenshot is a very necessary part of the bug Report. A picture is better than a thousand words. However, don't turn it into a habit of unnecessary screens in each bug report. Ideally, your bug report should be effective enough to make developers reproduce problems. Screen capture should be just a way to verify.
· If you want to come with a screenshot in bug Report, make sure those pictures are not too big, using JPG or GIF format, not BMP format
• Write annotations on the screenshot to point out the problem. This will help developers can position problems immediately.
Severe procedures / priority
• Influence procedures for analyzing defects before setting up the serious procedure of bug Report. If you think your BUG has a high priority, you should be fixed, prove this in bug Report. This reason should be pointed out in the description of Bug Report.
· If bug is the result from the last internal small version or version returns, then alert. A serious procedure like this bug may be low, but the priority should be high.
Log
An excerpt piece with a log or log in Bug Report. This will help developers easily analyze and debug the system. In most cases, if you don't attach a log and it is difficult to reproduce the problem over the developer, they will retrieve the bug report to you and ask for a log file.
If the log file is not big, take an example, about 20 to 25 lines, you can put it in bug report. But if it is more big, use it as an attachment to bug Report, otherwise your bug report looks like a log.
other information
· If your bug appears random, you can just say it in your bug report. But don't forget to archive it. You can always add accurate steps in any time you find them. This will also save you when others submit this issue, especially when that problem is more serious.
• Write an error message in bug Report, especially when the error message is numbered. For example, error messages from the database.
· Write the version number and internal small version number in Bug Report
· Write a problem that can be reproduced. Accurate explanation of problems that are not reproducible platforms. It is also also understood that the problem is not reproducible on a particular platform and does not test between a platform. This may cause confusion.
· If you have the same result, just write a bug report. The repair of the problem may just be one. Similarly, if you encounter similar problems in different places, and ask the same repair method, but in different places, then write separate bug reports for each problem. Each bug Report corresponds to a fix.
· If you can reproduce the bug's test environment is the details of the developer's accessible, write down to access this setting. This will help them save the time to install the environment to reproduce the bug you submitted.
· You must not stick to any information about BUG. The unnecessary interaction between developers and testers due to inefficient submission bugs before BUG is fixed before.
