Defect Logging

When the defect has been isolated
• See if it is known. Check the bug database to see if the bug you have found has already been reported.
• If the defect you have found is a duplicate but the one in the database has a status of Closed, reopen it and enter a comment in the history.
• If the bug you have just found is similar to a bug which is already in the database, but not exactly the same, then the existing report may need to be modified. Add your comments to the bug.
• If it isn't a duplicate, write it up after isolating it.

Writing up Problem Reports
In general, the Problem Title and Steps to recreate should be very specific and not contain editorial comments or opinion. With the exception of Enhancements, these fields should describe "what you did", "what object you did it to" and "what happened". The object needs to be referred to by its real name. Likewise, correct OS terminology must be used as well. Using the correct terminology will help others find your bug and reduce the number of duplicate bugs.

Given below is the format of how to log a clear and concise defect

/*****************************************************/
Problem Title:

Product name:
Build Tested:
Origin:

O.S. Tested:
O.S. Affected:

Tested in previous version of the product (if applicable):
Affected:

Browser Tested :<>
Browser Affected :<>
(Applicable only to web related defects)
_______________________________________________________________________
Steps to Recreate:
1.
2.
3.


Result:
Expected Result:

What works vs what does not:

Note
/*****************************************************/

Description of the main fields is given below:

Problem Title:

This is a one sentence summary that describes the bug. The summary should be concise, and include any special circumstances or exceptions. The Problem Title should be so accurate that someone associated with the project should be able to understand and even reproduce the problem from the problem title field alone.

Steps to Recreate:

This is a sequence of steps that describe the problem so that anyone can replicate the problem. Descriptions should be as concise as possible and should really be no more than 10 steps. The result needs to be written down separately. The steps should only describe the incorrect behavior. There is a tendency to write an example of similar correct behavior first and then the incorrect behavior to help justify the bug. This only confuses and frustrates the developer.

Result:
Description of the incorrect behavior, including specific file errors with stack crawls, asserts & user breaks.

Expected Result:
Description of what the specification defines or (if undefined) your expectations. If the expected behavior is at all at question, it probably needs to be escalated to management for definition.

What works what does not work:
a) Should contain what works and what does not (mandatory for almost all defects, few exceptional cases may be there!).
b) Special notes describing the defect, which is helpful for R&D to fix the defect (optional).
c) Related defect Ids. (Optional).

Note:
This is additional information that assists the developer in understanding the bug. This could be the version where it was introduced, things that you discovered while narrowing the bug down, circumstances where the bug doesn't occur, and example of the correct behavior elsewhere in the product, etc.

Proofread your bug reports and try to reproduce the problems following the steps exactly as written.

Visit Defect Thrashing Procedure and Defect Tracking as well for more information

For more software testing definitions, please go here