Guidelines to follow before filing defects

I created this for my team but felt it would be useful for others if i make it public

General Guidelines
Be precise
Be clear - explain it so others can reproduce the bug
One bug per report
No bug is too trivial to report - small bugs may hide big bugs
Clearly separate fact from speculation
If a bug already exists in the same area then make yours as an annotation to the existing bug instead of filing a new bug
Search the bug tracking system and ensure that the bug does not exist already
Explain the bug in a quick and understandable summary
Mention the browser, operating system, printer and other relevant details clearly
Take a snapshot of the issue if required and add them to the bug report as attachment. Try to attach a jpeg as the size would be small and can be opened easily
Mention the steps to reproduce, expected result and actual result clearly
Mention the component/module where the error occurred
If you unable to reproduce the bug consistently, please mention the same in the remarks/notes section
Have a word with your peer to just ensure if he is also facing the same issue.
Have the right service packs in place for your browser, operating system etc
If the bug is pertaining to look and feel, usability etc test it on multiple browsers before filing it
Clearly categorize the testing level where the bug was found such as unit/integration/system/acceptance
Mention the type of testing you did to unearth the bug such as smoke/regression/ad hoc etc

Build Guidelines
If the bug is identified in an older build, reproduce your bug using a recent build of the software, to see whether it has already been fixed.
Mention the build release date and build number clearly before filing the bug
Make sure that you are using the right build
Read build release notes carefully before filing a defect since the bug that you have identified could be a known issue.

Enhancement Request and Defects
An enhancement request is a case where the tester feels that the existing feature can be either enhanced with a new functionality or completely replaced with a new functionality to give the end user a better product experience. One example is to replace the option of choosing countries using multiple checkboxes by providing a user with a combo box.
A defect is a case where there the expected behavior of the system is not matching the actual behavior when testing it.

Priority/Severity Guidelines
Severity refers to how bad or critical the bug is from a functional/technical viewpoint. Severity of a bug is defined by the tester
Priority refers to the importance of fixing the bug from a customer viewpoint. Usually this is decided by the development team/manager in discussion with the QA manager/team

When assigning priority/severity for a bug, please follow the guidelines below.
P1 - Fix the bug ASAP
P2 -Bug can be fixed before release
P3 - Bug can be fixed even after release
P4 - The bug is very minor, can be fixed anytime
S1 - Blocker
S2 - Critical
S3 - Major
S4 - Trivial/Minor

0 opinions: