Capturing and tracking Bugs is important because it is the primary measure of value from the QA processes.  If the QA processes are not discovering any bugs, then what value are they providing?

Bugs can originate from a few sources:

  • Implementation Testing</li></li>
  • Release Testing</li></li>
  • User Acceptance Testing</li></li>
  • Production</li></li>
  • Other</li>

    All Bugs should be tracked in TFS as Work Items.  Each bug should include the source where it was discovered.  If it was found in Production the source should always be Production regardless of how or who discovered it.  If it is discovered before it hits production, then one of the other most relevant source values should be used.

    Bugs that are discovered as a result of running Tests in MTM should be linked to the Test Case that found the Bug.  If the Bug is created using the MTM Test Runner this link is automatically created.

    For Bugs that are found for new features over the course of the Implementation Phase, it is expected that these will be fixed immediately as part of the Sprint.  For Bugs that are found in Production, or during other phases, they may be placed on a teams Backlog and planned/tracked in a similar way as User Stories.

    There are a few additional processes that teams often use around Bug tracking: Bug Triage, and Quality Reviews.

    Bug Triage

    Production Bug reports typically originate with the Help Desk that supports the application and users.  Depending on the volume of bug reports that are occurring, teams may put in place a triage process.  This is a regular meeting (usually 1-2 times per week), that reviews all new bug requests and determines next steps.  The triage process usually looks at each new bug and answers a few questions:


  • Is this a duplicate of another bug already in the backlog?</li></li></li>
  • What is the severity of this bug? (e.g. is it a total system crash, or is it a spelling mistake)</li></li></li>
  • What is the impact of this bug? (e.g. how many users are likely to encounter it each day/week/month)</li></li></li>
  • What is the estimated effort to fix the bug?</li></li></li>
  • What is the priority of this bug? (this takes into account tradeoffs of the above 3 items to </li></li></li>
  • Which stable team would be responsible for resolving this bug?</li></li></li>
  • Do we have enough information to reproduce this bug?</li></li>

    The end result of the triage process is attaching some additional metadata to the TFS Bug Work Item, and assigning it to the appropriate Stable Team for resolution.

    Quality Reviews

    This is the practice of holding a regular meeting (once a month perhaps), where the goal is to review all bugs found in production since the last meeting.  Go through the bug list and try to get an understanding of each bug, specifically why it wasn't discovered during the regular testing process (implementation + release + UAT Testing).  The intent is to identify what types of bugs are not being discovered, and identify potential improvements to the testing processes to address these gaps.