Rule #24
Do you keep the best possible bug database?
  v3.0 Posted at 25/05/2011 10:42 AM by system
There are 101 bug databases on the market at the moment and of course many companies make up their own in-house systems.

This is a common scenario: Your tester/client finds a bug, they log on to your on-line bug database, and enter the data, they save the error message as a gif and upload the image. As Project Manager, you get notified by email of the bug, you log on to the application, view the image, review the status, assign a priority, and assign it to a developer. The developer receives the email, logs on and sets about fixing the bug. When completed, he logs back on to the application, enters a completed date, and an email is sent to the tester/client. The tester/client logs on, and is told what to test, reviews the work, enters a checked by date, and the final email is sent to the manager who closes the bug.

Phew! That sounds like a lot of steps which is why most people resort to just sending an email. I believe most people send requests for tasks via email, if this is the case, why should developers have a separate "to-do" list, in the form of a bug-database in which they re-enter data?

MS TFS has an Outlook addin which can save you a lot of this work called Team Companion. This has a number of benefits including:

  • Developers don't have to re-enter data
  • TFS fully intergrates your bug tracking with your source control.
  • Managers can see important information like Tasks Completed and Tasks Assigned in TFS Reports
  • Clients can see what developers are working on via TFS
 

Loading
Do you like this rule?
Loading
Do you follow this rule?
Loading

......