Steps for Better Bug Reports

Bug report is the document including the information about the defect, its description an all required attributes. The Bug report must be carefully written for the person or organization can understand the problem and fix it with the minimal time and cost.

Some number of bug reports will always be irreproducible or contested. Some bugs exhibit symptoms only intermittently, under obscure or extreme conditions. On some projects without clear requirements, there can be reasonable differences of opinion over what is correct behavior under certain test conditions. Sometimes testers misinterpret test results and report bugs when the real problem is bad test procedures, bad test data, or incorrect test cases.

Bug report writing tips:

1. What was happening before:To fix the bug developers need to reproduce all workflow that tester and system do. So, don’t forget to describe steps specifically and informatively.
2. Be specific:You should write the same names of fields, buttons and other items as it named in the application. If you want to describe message, copy and paste the whole message in the description of the bug report.
3. Attachment:You should attach different screenshots, video, messages and etc as more as possible. It’ll help to developers easier and faster find the issue and fix it
4. One defect per report: No more, no less. A single bug in a report can help to avoid duplication and confusion. If you describe too many defects some of them may be overlooked.
5. Reproduce the bug before writing a bug report: Make sure your actions lead to reproducing the bug without ambiguity. The defect should be reproducible.

Ten Steps for Better Bug Reports:

1. Structure : Test thoughtfully and carefully
2. Reproduce : If the problem is intermittent, report the rate of occurrence.
3. Isolate : See if you can identify variables— for example, configuration changes, workflow, data sets— that might change the symptoms of the bug.
4. Generalize : Look for places that the bug’s symptoms might occur in other parts of the system, using different data, and so forth, especially where more severe symptoms might exist.
5. Compare : Review the results of running similar tests, especially if you’re repeating a test run previously.
6. Summarize : Write a short sentence that relates the symptom observed to the customers’ or users’ experiences of quality, keeping in mind that in many bug review or triage meetings, the summary is the only part of the bug report that is read.
7. Condense : Trim any unnecessary information, especially extraneous test steps.
8. Be clear : Use clear words, avoiding especially words that have multiple distinct or contradictory meanings; for example, ‘‘The ship had a bow on its bow,’’ and ‘‘Proper oversight prevents oversights,’’ respectively.
9. Neutralize : Express yourself impartially, making statements of fact about the bug and its symptoms and avoiding hyperbole, humor, or sarcasm. Remember, you never know who’ll end up reading your bug report.
10. Review : Have at least one peer, ideally an experienced test engineer or the test manager, read the bug report before you submit it.

REFERENCES :
Rex Black. (-). Managing The Testing Process. 03. Wiley Publishing Inc. Indianapolis. ISBN: 978-0-470-40415-7.