Using Team Explorer with Bugs
New Bugs Items with Team Explorer
To create a new Bug item using the Team Explorer interface in
Visual Studio, right click on the Work Items folder of your Scrum project in the
Team Explorer window. A window will appear that may offer the option to "Add
Bug" in which case select this option. Alternatively if this
option is not available you will find it in a further window by selecting
"Add Work Item". See the screenshot below:
It is also possible to create a new Bug through the "Team" drop-down menu or by
using "Add Related WorkItem" from the right-click menu on an existing work item, like
a Product backlog item for example.
Here is a screenshot of a new Bug created by right-clicking on a Product Backlog item and creating a bug that is linked to it:
Bugs Work Item Fields
A number of additional fields have been added to the Bug work item to enable greater flexibility when working with bugs data
via Work Item Query Language (WIQL) queries whether consumed by Team Explorer or Excel. Custom WIQL queries can be used to augment
those that we have provided out of the box and then viewed in Team Explorer or Excel.
A Bug workitem has the following fields:
| Field Name |
Type |
Description |
| Title |
Text |
Short title describing the bug |
| Area |
AreaPath |
Team System hierarchical AreaPath field that can optionally be used to further categorise
the type of bug or indicate which part of the system it relates to |
| Release and/or Sprint |
IterationPath |
This field allows the bug to be allocated to a specific Release and Sprint for resolution after
the Product Owner has prioritised it against the rest of the Product Backlog |
| Estimated Effort |
Number |
For the Team to provide an estimate of the effort required to resolve the bug – units are Story Points or Days |
| Team |
List |
Used to allocate the bug to a specific team if there are more than one team working against the same Product Backlog.
Teams are setup with the List Manager tool |
| Testing Impact |
List |
A field set by a QA to indicate the bug’s impact on their ability to test the system. "1 - Blocking" through to "5 - Low" |
| Business Priority |
Number |
Set by the Product Owner to indicate their view of the business priority for resolving this bug relative to priority for
implementing other Product Backlog items. Higher numbers are assumed to higher priority in the sort order for WIQL queries |
| Delivery Order |
Number |
The team take the business priority set by the Product Owner and make adjustments where necessary based on technical factors.
So the Delivery Order field is used to indicate the order in which the team will work on the Product Backlog and Bug items that
closely resembles the Business Priority - higher numbers are assumed to be higher priority |
| Work Remaining |
Calculated |
A calculated field that displays the total number of hours work remaining in the Sprint tasks that implement the Product
Backlog or Bug item |
| Current Status |
Workflow |
Tracks the status of the Bug, moving from Not Done - In Progress - Ready For Test - Done - Deferred or Deleted |
| Found – In Build |
Build Lookup |
Used to select the Build number of the code that the bug has been found in |
| Found – Date Discovered |
Date |
Records the date when the bugs was first found – useful to enable easier manipulation of the bug work items with WIQL queries |
| Fixed – In Build |
Build Lookup |
Used to record the Build number of the code in which the bug was tested and proved to be fixed |
| Fixed - Date Closed |
Date |
Records the date when the bugs was fixed – useful to enable easier manipulation of the bug work items with WIQL queries |
| Description |
Tab/Text |
Detailed description of the bug |
| Replication Action – Environment |
Tab/Text |
Records the environment that the bug can be replicated in, e.g. “System Test”. The Environments can be configured in the List Manager utility |
| Replication Action – Steps |
Tab/RO |
Description of the steps required to repeat the bug |
| File Attachments/Screenshots |
Tab/Files |
Related screenshots and data files can be attached to the bug work item |
| History |
Tab/RO |
Shows all the automatically recorded changes to the bug work item over time. Manual annotations and comments can be added to augment the automated change tracking information |
| Links |
Tab/Links |
Primarily used to link related Sprint Tasks that are required to implement a resolution to this bug but can also be used to link to Product Backlog items that this bug might relate to |