How to report a BUG???

Firstly, how do we call it. Either BUG or DEFECT?
As far as my concern, both are practically same. Defect is when the tester raises a issue, where as we call it them as Bug  when the defect is accepted by the developer officially.

Its a professional war :) between a developer and a tester. However its a friendly battle :) Only one can have the upper hand, either a quality code or a strong tester.
When a bug or a defect identified, a tester should report it to the respective developer. But how? What are the steps need to follow while assigning a bug to the developer?

With the following template I guess the bug/defect can be reported accurately

1.Title: A short description about the bug in a single line
2.Identified by: Name of the tester
3.Date: Bug identified date
4.Assigned to: Name of the respective developer.
5.Environment: In which environment does the bug identified. Like windows or linux or solaris... 6.Build no: Build release number in which the bug is identified.
7.Bug Type: States the type of bug it is. Typically these are,

• Functional:  Bugs that are deviated from the expected flow.
• Usability: When an end to end scenario accomplished in different way instead of the actual way
• GUI: Bugs that affect the presentation, look or layout of pages, images and form elements.

8.Bug Severity: This renders the impact of the bug on the application. Defining the type of bug identified, whether its functional or usability or gui or security. Severity levels can be differ as per the process followed by the companies. My severity levels are likely critical, high, medium, low.

•  Critical: If a bug is mapped to this means, then the screen/application encounter with unexpected errors and can not be tested further and need to be resolved immediately. Ex: Can not log in to app
• High: If a bug is mapped to this means, then the functionality in the screen/app is deviating from the expected result. Ex: clicking on a link takes you to page X instead of the intended page Y
• Medium: When a record is saved into database but improperly shown in the user interface. Then the bug can be mapped with this.
• Low: Bugs that do not interfere with core functionality and are just annoyances that may or may not ever be fixed. Typically spell mistakes, color legends. Ex: Search results format display incorrectly in different browsers

9.Priority: How fast the bug has to be resolved. Decision take by the developer/manager
10.Test data: What kind of test data used while testing and through which data the bug is identified.
11.Module name: Name of the module bug identified in the application.
11.Screen name: Name of the screen under respective module, the bug identified.
13.Description: Detailed description of the identified bug with proper reproducible steps.
14.Root cause: Specify proper reason for the bug caused.
15.Attachment: Proper snapshot of the bug, if required.

"Although tester has classified the bug, lead or manager has right to re-classify the bug."

Happy Testing...

 A Journey towards Testing...:)