1. Keep the Defect Summary concise.
The defect summary should be very concise and to the point, developer should not need to scroll through the synopsis. For example, “Customer data import fails when .zip file is selected”. Also it is a good practice to indicate the affected area by putting one or two words before the defect summary. For example “Database: Customer data import fails when .zip file is selected”
2. In description write clear steps to reproduce the problem.
You should provide clear steps to reproduce the problem, the steps should be detailed so that anyone who is trying to reproduce the problem does not face issues in doing so.
3. Describe the test environment in detail.
There are many defects which can be reproduced only in certain environments, so it is very necessary to describe the test environment in detail on which the defect occurred. Whenever the developer looks at the defect he needs to know on what particular scenario did that defect occurred. You should clearly fill out the platform/OS/environment fields and describe whole test environment in the description field.
4. Do not be too verbose, keep to the facts.
While entering the defect description you should keep to the facts, do not put irrelevant information.
5. Attach snapshots and Logs.
A snapshot or defect logs are very important thing because they can clarify the defect by just seeing them, so always take snapshots to the problems occurred and attach them to the defect entries made. Make sure you use compressed images like Jpegs to keep the snapshot size small.Also if your find that the error is logged into the log file, attach it to the defect entry as well. If the log file size is large cut the small section containing the error or compress the log file using zip/tar utilities.
6. Assign appropriate severity and priority.
You should assign appropriate severity and priority to defect. Usually you can follow a rule to assign same priority as severity however this does not hold true for every defect, so you should properly study the severity caused by defect and then assign a priority to it, there are defects which are less severe but they have high priority for example, A spelling mistake on the login page of web portal does not cause any threat to the system functionality however this needs to be fixed because everyone logging into the system will see that error.Severity levels can be tweaked a little bit by organizations as per their defect life cycle guidelines however the general levels of severity and priority are as follows.
Severity:
1-Critical
2-High
3-Medium
4-Low
Priority Levels:
P1 – Fix Defect Immediately
P2 – Give high Attention
P3 – Normal Queue
P4 – Low priority
P5 – Can be deferred
7. Multiple issues should not be grouped into a single defect entry.
Most of the times we find many defects while testing one single area, usually test engineers club multiple issues into one defect which is very bad practice. Never club two issues in a single defect, always create a separate defect for each problem.
8. Do not enter duplicate defects.
There is a possibility that the defect that you just uncovered has already been found by someone and logged into defect management tool. So before logging a defect always search the defect management tool to find out that there is not such defect already logged, also its a good practice to consult other testers who have worked on the same functionality and find that no one else has entered same kind of defect.
