If defect report is productive then there are higher chances that it will get fixed as soon as possible. So it depends on how energetically you report the bug. Reporting a bug is nothing but an art or skill. In this topic will discuss "How to maintain the quality of the bug reports".

Bug tracking is a critical & fundamental part of application lifecycle management. However, it's common for a bug tracking tool to be under utilized by software development and QA-Testing teams, with much of the tool's potential functionality remaining untapped. This can be remedied by implementing best practices throughout the defect tracking process.

Good Quality of Bugs Report can be maintained in Bug tracker by:-

1) Having clearly specified bug number:

The individual number of each bug will help to recognize the record of that bug. This number while reporting any bug is automatically generated on each time by tool.

2) Reproducible:

Reported bug will never get fixed if your bug is not reproducible. Don't forget to mention steps to reproduce the bug. Step by step described bug problem is very much easy to generate and fix.

3) Be Specific:

Be Specific and to the point means it should not essay type. Use minimum words yet in effective way to summarize the problem. Multiple problems shouldn't be combined even they seem to be similar. Write another reports per problem.

Use following simple Bug report template in Bug Tracker:-

Below is the format of bug reporting. The bug tracking/report tool may vary.

Reporter: Your name with email ID.

Product: Product on which you found this bug.

Version: The product version if any.

Component: The sub modules of the product.

Platform: Hardware platform should be mentioned in your report like:- where you found this bug like HP, Sun, PC, MAC etc.

Operating System: Operating systems your are using like Mac OS, Linux, Unix, Windows, SunOS. Mention the different Operating Systems versions also if valed like Windows NT, Windows 2000, Windows XP etc.

Priority: When bug should be fixed? Preference is generally set from P1 to P5. P1 as fix the bug with highest priority and P5 as Fix when time permits.

Severity: This explains the impact of the bug:-

1. Blocker: Testing can't be preformed.
2. Critical: Application crash, Data losing.
3. Major: Major loss of functionality.
4. Minor: minor loss of functionality.
5. Trivial: Some UI improvements.
6. Enhancement: Request for new feature or some improvement in existing one.

Status: Default status of the bug will be New', when you are report the bug in any bug tracking system. Later on it will go through many other stages like Reopen, Verified, Fixed, Wont Fix etc.

Assign To: Bug should be assign to the responsible developer for that particular module/area in which bug occurred. Otherwise keep manager's email address in CC, manger will assign bug to module owner or will assign bug to developer.

URL: URL of page where the bug occurred.

Summary: A brief summary of the bug mostly in 60 or below words. What the problem is and where it is should be mentioned.

Description: Description should be mentioned in detailed. Following fields can be used in description field:-

• Reproduce Steps: Write steps to reproduce the issue.
• Expected result: What should be expected behavior.
• Actual result: What you are getting actual, should be mentioned.

The report types are typically:

1. Coding error
2. Design error
3. Hardware problem
4. Documentation issue
5. New suggestion