Bug Entry Good Practices

Enter Bugs as Soon as Possible

Bugs should be entered into the bug database as early as possible. As a rule, a bug should be entered by the tester as soon as it is found.

One Bug per Record

Each record of the bug database should describe only one defect. Testers may consider holding several defects within one record only if they have the same cause. In this case the tester should provide a clear explanation of which problems were combined into one bug record. For example, list the affected objects with their locations. Or explicitly say that all of the objects of a kind have the described problem, if this is the case.

Points to Focus On

When describing a bug, the focus should be in figuring out how to minimize the work needed to be done by the producer in evaluating it and by the programmer in localizing it. The bug description should be easy to understand and should provide the simplest way possible to reproduce the bug. It should also provide all the additional information that may help the producer to decide on what to do about the bug.

Bug Summary

The bug summary is used alongside the bug number as a bug identifier, so it should be unique and unambiguous.

The summary must be a compact, clear statement of the bug. It should completely describe the problem, while being concise and easily readable quickly. The summary is important since it is used on reports and overviews.

To make the summary short and unambiguous, you should follow the noun-then-verb pattern, that is, specify first the object and then the problem.

Bug Description

A complete bug description consists of the following:

• Detailed Description – a description of the defect with more detailed information than the bug summary.
• Steps to Reproduce - exact steps necessary to replicate the defect. Keep bug steps to a minimum. Avoid including steps or items that are not actually part of the bug. Testers need to whittle the bug description down to the minimum necessary for the programmer or producer to see the bug. This may take extra work by the tester, but is worth it.
• Actual Result - description of what the defect is. This should be what happens after following the Steps to Reproduce.
• Expected Result - this is what the expected result that should occur, as stated in the original specification. The tester needs to clearly identify what the expected result should be. The expected result coupled with the bug summary should be enough to understand the bug for users who do not need to reproduce it step-by-step (management, end-users, etc…).
• Suggested Fix - the tester's proposals about how best to correct the defect.
• Investigation Notes – any information discovered the tester tried to reproduce the bug under different conditions, information on how widespread the bug is, limits to the cases when the bug may appear, a workaround if any, etc.... The tester should research to determine parameters that affect the bug.
• Additional Information - whatever information that might help the producer decide on what to do about the bug.

Not every bug description will contain all of these sections. For example, if only one step is needed to reproduce the problem, the detailed description is enough. If the actual result is obvious, there is no need to describe it explicitly. However, it is always best to include a section, than to leave it out, just in case.

Screen Shot

A screen shot can be part of the bug description if it will help make the bug easier to understand.

Testers can provide screen shots to illustrate bugs that are difficult to describe verbally, such as appearance bugs. If it helps, the tester might also provide a corrected mock-up of the corrected screen.

Customer's Bugs

All bugs sent by a customer should be logged in the project's bug database. When logging customer-submitted bugs, descriptions should be entered as is, without any corrections. If the customer's description is not clear or complete enough, the tester who logs the bug can add comments, but not edit the customer's original description. Both the customer's description and the testers comments (if any) should be clearly specified.

> Overview
> Features
    - Web-based
    - Unlimited
    - Reports
    - Email Interface
    - Data Import
    - Custom Form
    - Web-query
    - RSS feeds
    - Project Sharing
    - Multilingual
    - Source Control Integration
> Pricing & Licensing
> Choose Your Edition
> Security

	Risk Free Trial
		Click here to start with 14-Day Risk Free Trial!

	Learn More
		Workflow Presentations White Papers Documentation Usage Scenarios Bug Entry Good Practices

	Referral Program
		We will pay you for your lead! Up to $200 if we sign them up.