How to write Effective Defect Report

 

Defect reports are most important deliverables to come out of test. Effective defect report will

• Reduce the number of defects returned from development
• Improve the speed of getting defect fixes
• Improve the credibility of test
• Enhance teamwork between test and development

Defect Remarks

1. Condense - Say it clearly but briefly
2. Accurate - Is it a defect or could it be user error, misunderstanding, etc.?
3. Neutralize - Just the facts. No zingers. No humor. No emotion.
4. Precise - Explicitly, what is the problem?
5. Isolate - What has been done to isolate the problem?
6. Generalize - What has been done to understand how general the problem is?
7. Re-create - What are the essentials in triggering/re-creating this problem? (environment, steps, conditions)
8. Impact - What is the impact to the customer? What is the impact to test?

Sell the defect.

 

Debug - What does development need to make it easier to debug?

(traces, dumps, logs, immediate access, etc.)

 

Evidence - What documentation will prove the existence of the error?

The defect report contains proper following data.

<!--[if !supportLists]-->1.     <!--[endif]-->Title of bug - it should start with your Module number along with your defect summary. For ex Module No-Module Name- Record is not getting updated in database.

2. Select Cross Reference#, if any

3. Select all mandatory details like, opened by, severity, found during, assigned to, etc.

 

In comment section we should provide detail information along with test environment. Because if any new member validates the defect then he/she should able to understand the same in better way.

In comment section, we should follow as:

1. Copy title of bug

2. Test environment: like L1, L2(if any), Browser detail(if any), Database details (if any)

3. Steps to reproduce

4. Actual output

5. Expected output

6. Build date and number (if any)

7. Attachment of log or screenshot (if any)

8. Any special observation/comment

9. Test data (if any) like ID, xml etc.

 

Same way, when we close or retest or reopen the details we need to follow same style.

1. Mention on which build and date you test the defect.

2. Reason for closing the defect, like DB getting updated properly.

3. Defect due to Code, Document etc (if any)

4. Provide test data with which defect is validated.