Bug Tracking 101: Where TFS Blows It

As a developer, I love Microsoft Team Foundation Server. As a manager, I hate it.

Why? Bug tracking.

“But TFS does bug tracking,” you say. Sure it does. So let me try to explain why Microsoft’s brand of bug tracking just isn’t going to get the job done. I’ll start with my personal opinions about bug tracking.

Bug tracking is one of the basic life-support functions in software development. I’d rank it second after Source Code Control as far as critical support functions. To put it bluntly, there’s just no reason not to have a bug tracking system these days. There are hundreds of very good systems out there, and you can get most of them free in a box of breakfast cereal.

It’s pretty common, in my experience, for people to argue against logging bugs. There’s a perception that logging a bug is a big, hairy deal, or maybe they want to keep the count low in their “real” bug database so their numbers look good. Bull-pucky, I say. Log everything. If a bug occurs and it doesn’t get recorded, it never happened.

Sure, you’re going to get some bad bugs. You’re going to get some duplicates. You’re going to get some bugs you can’t reproduce.

So what?

If you log a bug and have to close it because it’s a bad bug, you spend some time doing so. Bug if you don’t log a bug, you can never reverse that decision. In fairness, you’ll usually want to have *something* in a report that’s actionable, but I really prefer to set the bar low so I sweep more bugs into the net. I can far more easily wipe out the bad than I can make up for lack of data if there’s something going on that I’m not seeing.

You may have inferred by this point that I prefer to let most, if not all users and testers enter bugs. Right on. Again, this is to help gather information as close to the source as possible. And yes, again, this increases the chance for junk data. And yes, yet again, the alternative is no data. If you make it easy for lots of people to give you feedback, some of them will give you feedback. If you make it difficult, damned few will give you any at all. You’re in the dark — probably with a false sense of confidence about the state of your system. “Look – no bugs logged in the last week! We’re perfect!” Sure, you are.

Ok, so that’s how I feel about bugs. Feel free to argue amongst yourself, or even with me. ;-)

Back to TFS. Like I said, they have a bug tracker, so what’s the problem? Not a thing, if you happen to be a developer with TFS already running as part of your IDE. If you’re not a developer, here’s what you’ve got to do to use TFS:

  • Buy a license. Yes, if you want to log a bug, you need a full TFS client license. Just to log a bug. JUST TO LOG A BUG.
  • Since you have to buy a license, you’re probably going to need to justify that license to somebody (not that I’ve run into that brick wall recently, or anything….). Quick review: you’re going to be asked to make a business case for purchasing a client license for someone so they can LOG A BUG!! Let me know how that goes for you, ok?
  • Now you need to get Team Explorer installed on the workstation of the person who’s supposed to log the bug. Oh, no — you can’t just browse to a web page to do this (despite the fact that TFS makes heavy use of SharePoint). Is any of this making sense to you? Astute readers will observe at this point that there are add-on software components available to web-enable TFS. I’ll observe right back at you that the very fact that this is an add-on tells you something about whether Microsoft gets how this software should be used.
  • Now, your user is ready to log a bug. After they open Team Explorer. On the machine where it’s installed. Oh, they’re at a different machine now? Maybe they’re testing on a Mac? Nuts. Well, write everything down and log it when you get back to your desk. Poof! Your bug just disappeared, because 99 out of 100 users are just going to say, “why bother?” And they’d be right, of course.

Come on, Microsoft — think this through and get it fixed. Now. Please.

In the mean time, use this.

24 thoughts on “Bug Tracking 101: Where TFS Blows It

  1. Thanks for the comment, Sam.
    Thanks for the comment, Sam. I think you hit the nail on the head — Joel's incredibly focused on usability, so I can where FogBugz is probably very well-suited to the job. The bug tracker in Team System, among other things, is among the least inspired user interfaces imaginable.

    Gotta leave something on the table for the next release, though, right?

  2. thanks for that great ideas
    thanks for that great ideas there….it is very useful

  3. I have been a QA Manager for
    I have been a QA Manager for some time and your insight into bug tracking is dead on. However, I've found myself in a new company where TFS has so many benefits to our particular work that we cannot overlook it. So I have forced myself to adapt to using it for bug tracking – in order to take advantage of the integration. I have felt the same pain you wrote about… but 2008 has addressed two of your primary concerns:

    MS bought TeamPlain and integrated it into the 2008 release. So now TFS has a built-in web client that offers all the functionality you need for interacting with WI through the web without needing Team Explorer.

    Second, the licensing in 2008 was changed so that users who interact with WI do not need their own CAL. Here is a reference: http://blogs.msdn.com/adamga/archive/2007/11/20…>

  4. Hey, that's great – I missed
    Hey, that's great – I missed that update. Obviously, that's a welcome change. I sort of figured Microsoft would eventually come around and make TFS more usable. The core functionality and interoperability is a really compelling sell, which makes the stupid little issues all the more frustrating.

    My #1 remaining gripe? You can't change a bug into a task (feature request), or vice-versa. It's really easy for someone to mis-report a feature request as a bug, and the fact that nobody can switch this type is pretty annoying.

    Maybe next release, though, right?

  5. Having used both, I actually prefer TFS with 2008. I love the integration with Excel and MS Project, and the ability to customize how work item tracking works (fields, workflow, etc.)

  6. This post is old….but is incorrect.
    Licensing always allowed anyone to log a bug w/o a license…as well as have read only access.
    Further, you can log a bug w/o any software installed…and from any machine, using the Team Web Access portal (if your TFS Admin was smart enough to install it).
    This has been available since TFS 2008 (maybe even late 2005).|

    This alleviates both of your complaints. :)

    • I’d love to post an update to this with more recent licensing info. Licensing of MS products, of course, has been pretty complicated for quite some time, of course, so if you’ve got specific information that shows that this is the case, please give me a shout. I tried googling this just now, and one of the links I turned up made it seem like this was still an issue for TFS 2005, so it’s quite possible that it changed for TFS 2008.

    • I’d love to post an update to this with more recent licensing info. Licensing of MS products, of course, has been pretty complicated for quite some time, of course, so if you’ve got specific information that shows that this is the case, please give me a shout. I tried googling this just now, and one of the links I turned up made it seem like this was still an issue for TFS 2005, so it’s quite possible that it changed for TFS 2008.

  7. Hey,
    looks like many things have changed in TFS since this message has been posted.

    is it possible to interact with the TFS via an webservice interface?

    regards

    John

  8. Hey,
    looks like many things have changed in TFS since this message has been posted.

    is it possible to interact with the TFS via an webservice interface?

    regards

    John

  9. Thanks for the comment, Sam.
    Thanks for the comment, Sam. I think you hit the nail on the head — Joel’s incredibly focused on usability, so I can where FogBugz is probably very well-suited to the job. The bug tracker in Team System, among other things, is among the least inspired user interfaces imaginable.

    Gotta leave something on the table for the next release, though, right?

  10. thanks for that great ideas
    thanks for that great ideas there….it is very useful

  11. I have been a QA Manager for
    I have been a QA Manager for some time and your insight into bug tracking is dead on. However, I’ve found myself in a new company where TFS has so many benefits to our particular work that we cannot overlook it. So I have forced myself to adapt to using it for bug tracking – in order to take advantage of the integration. I have felt the same pain you wrote about… but 2008 has addressed two of your primary concerns:

    MS bought TeamPlain and integrated it into the 2008 release. So now TFS has a built-in web client that offers all the functionality you need for interacting with WI through the web without needing Team Explorer.

    Second, the licensing in 2008 was changed so that users who interact with WI do not need their own CAL. Here is a reference: http://blogs.msdn.com/adamga/archive/2007/11/20/tfs-for-defect-tracking-licensing-change.aspx

  12. Hey, that’s great – I missed
    Hey, that’s great – I missed that update. Obviously, that’s a welcome change. I sort of figured Microsoft would eventually come around and make TFS more usable. The core functionality and interoperability is a really compelling sell, which makes the stupid little issues all the more frustrating.

    My #1 remaining gripe? You can’t change a bug into a task (feature request), or vice-versa. It’s really easy for someone to mis-report a feature request as a bug, and the fact that nobody can switch this type is pretty annoying.

    Maybe next release, though, right?

  13. Having used both, I actually prefer TFS with 2008. I love the integration with Excel and MS Project, and the ability to customize how work item tracking works (fields, workflow, etc.)

Comments are closed.