Bug reports vary greatly in length and complexity depending on your product, corporate culture and needs but there are some fields that I believe are a must for any bug report. A bare minimum, if you will. This happens to be my own list and other testers will have different fields they consider mandatory but I tend toward a bit of minimalism.
A clear and concise title helps everyone. I make it a practice of putting unique information in the title like error codes or exe names. This makes it easier to later search the bug tracking system for duplicates or regressions rather than file a new bug.
A summary of the environment the bug occurs in as it relates to what you are testing. It could be as simple as the operating system or as complex as the os, browser, version of flash, etc.
How important do you think this bug is to fix? This should be important to the overall product and it may be higher priority if it’s blocking other testing or progress.
Product or Feature Area
What product (in a shared tracking system) or what feature area this bug occurred in. This serves to help when deciding who to assign bugs to or what areas of the product need concentrated attention.
This is the current owner of this bug and who is responsible for the next action with it.
These are the steps, in order, required to reproduce this bug. They should be complete enough that someone unfamiliar with that bug can accurately reproduce it. I recommend a numbered list. If an additional file or script is needed to reproduce the bug, the location of that should be noted here or the file or script attached if the bug tracking system supports it.
This is a clear statement of what the issue is and why this is a bug. This is the place to make a case for this bug to be fixed so customer impact as well as expected behavior should be listed. If the bug is not high priority, that should be listed here as well. This is not a place to try to game the system and artificially cry wolf on bugs that really don’t deserve it.
Who opened the bug. This allows questioning of the person, if necessary.
Date the bug was opened. This is useful for determining bug age.
This is the version of the product the bug is being reported for. It tracks what version was tested, no matter the date the bug was filed.
Who fixed the bug.
Date the bug was fixed.
Version of the product the fix will appear in. This allows the person verifying the fix to know when to expect it to be fixed instead of guessing.
Who verified the bug was fixed.
Date the bug fix was verified.