Programming.BugReport History

Show minor edits - Show changes to output - 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.

rewrite the above extensively
get screenshots
look up BugTracker documentation for best practices

!! [[#SeeAlso]] 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]]

!! [[#Categories]] Category tags
[[!bugs]] [[!testing]] [[!reporting]] [[!issues]]