Programming.BugReport History

Hide minor edits - Show changes to markup - Cancel

 
 
June 27, 2013, at 11:21 PM by OtherMichael -
Added lines 1-42:

(:description tips on making a useful bug report:)

How to Write a Good Bug Report

Test or Production

 

What you did
What happened next
What you expected to happen.

 

This might also be phrased as Before, After, and Expected.

 

If you are reviewing export data, this would be “what was keyed,” “what was exported”, and “What was expected.”

 

Reporting invalid data without reporting what the data should have been is not helpful -- if you know what is wrong, let everybody know, so they don’t waste more time researching it. If you don’t know what is wrong with it, find out. Reporting correct behavior as a bug just wastes time (and since we bill by the hour, you know what THAT means!).

 

Add screenshots if describing unusual behavior or display (JPGs or GIFs. Straight-up BMP files are excessively large. If somebody sent you a screenshot embedded in a Word doc -- try to extract it first, and upload the image-only, NOT the Word doc (this save both server space AND time -- it is faster to load the image (which can usually be viewed in the browser itself) than to launch Word).

 

 

opening bugs from vendor reports

Each of the issues below should be a separate bug ticket.

 

Please open bug tickets, attaching any relevant screenshots/images/files contained in the original zip file.

 

If a word (or other text) document containing descriptions of issues was supplied, please extract the text, pasting it into the body of a comment in the bug ticket.

 

 

 

TODO

rewrite the above extensively
get screenshots
look up Bug Tracker? documentation for best practices

 

 

See Also

How to Write a Good Bug Report
Bug-tracking Best Practices
How to Use a Bug Tracker
Alternate Names for BAD Bug Reports

 

 

Category tags

bugs testing reporting issues

Restore