Bug Properties

When defining a bug there are many pieces of information you may want or need to enter to capture the essence of the problem and provide the detail necessary for a developer to begin work towards a resolution. The editing options available on this screen depend on your permissions in the project.

An image showing all properties of a bugenlarge screenshot 

Name: This is a quick way to reference the bug, which ideally will provide a brief summary of the fault in question.

 

ID: This is the TeamPulse numeric identifier for the bug. This number is system generated and is not editable.

 

Tags: Tags allow you to label your bugs with common terms. Tags are unique to a project and are shared among all the stories, bugs, risks, and issues. Creating a tag is as easy as typing a name and hitting enter. Existing tags can be selected using the drop down or by typing and using the auto-complete ability. Tags can be removed by clicking the small 'x' beside the tag name. If a removed tag is not referenced by any other item within the project, the tag will also be removed from the list of available tags.  

 

Description: You can enter the basic details of the bug in the description field. This is a rich text field that allows for very descriptive formatting to be applied and help to describe the bug. The description area can be enlarged to provide more screen real estate for enhanced entry or viewing.

 

Blocking: A bug can be marked as Blocking to indicate that it is preventing other work or testing from being completed. A bug marked as blocking will acquire a special icon as well as be highlighted in red throughout the system.

 

Triaged: A bug can be marked as Triaged to indicate that it is ready to be assigned to developers for working toward resolution. For more information on the process of triaging please view the Bug Triaging documentation.

 

Assigned To: This is the member of the team actively working on the bug. For more information on assignment workflows please view the Bug Assignment documentation.

 

Status: Status indicates where your bug is on the way to getting resolved. When you created your project you selected a project template; this template defines the different statuses your bug can have. For example, the default Scrum project template has the following statuses your bug can be in: New, Approved, Removed, Committed, and Done.

 

Estimate: Represents the size of the Bug. Some teams may use Story Points to represent size, whereas other teams may represent the size of a bug in hours, days, or weeks estimated to resolve the fault. We have made no assumptions regarding the unit of work for this field.

 

Priority: This is a value that you can use to help prioritize the Bug in relation to other Bugs. Most templates define accepted values of 1, 2, 3, and 4, however these are configurable via the project template advanced settings XML.

 

Severity: This value can be used to indicate the impact this Bug has on the system, and can also be used to help prioritize the Bug in relation to other Bugs. Most templates define accepted values ranging from Low to Critical or Blocking, but these are all configurable via the project template advanced settings XML.

 

Notify me when others change this item:  If the notification system has been enabled and correctly configured, this check box will allow individual users to request email notifications when this bug has been updated. The value displayed here is relative to the user currently viewing the bug. You will not be notified if you are the only person who has changed the bug even if you have asked to be notified.

 

Sync with TFS:  If the project has been connected to a TFS project, this check box will mark this item as included in or excluded from the synchronization process.  To immediately sync this bug, click the Sync item now button.  For more information about TFS synchronization see Synchronization

 

Area: Areas can be very helpful for managing bugs. You can create an area and assign similar bugs to it. 

 

Iteration: The iteration dropdown shows you to what iteration the bug is assigned for resolution.

 

Steps to Reproduce: This is a rich text field that you can use to describe in detail the steps taken to reproduce the system fault this Bug represents.

Bug Steps to Reproduceenlarge screenshot 

 

Resolution: This is a rich text field that can be used to fully describe the actions take to resolve the Bug.

Bug Resolutionenlarge screenshot

 

Tasks: Sometimes the work needed to complete a bug can be broken down into multiple tasks. This allows individual tasks to be assigned to different people and provides more granular tracking for the project. 

Tasks tab in Bugs overlayenlarge screenshot

Visit Task Management page for more detailed information regarding tasks.

 

Acceptance Criteria: This area can be used to enter multiple Acceptance Criteria entries that must be satisfied to consider the Bug resolved. Each Acceptance Criteria entry can contain a plain text Title along with a rich text description.

Bug Acceptance Criteriaenlarge screenshot 

 

Related Stories: This area can be used to link the Bug to Stories within the TeamPulse system. This can be useful for understanding which Stories are impacted by a specific Bug.

Bug Related Storiesenlarge screenshot

 

Related Feedback: This area can be used to link the Bug to the Feedback item (Problem) if a client has reported it.

Related Feedbackenlarge screenshot

 

Attachments: Using the attachments tab you can attach files to your bug.  After a file is attached it can also be downloaded or streamed to the browser using the grid.

Bug Attachmentsenlarge screenshot 

 

Links: Use the links tab to add links to external content.  Clicking the 'open' button in the grid will open the link in a new window.

Bug Linksenlarge screenshot