locked
Best Way to Track Bugs - TFS 2010 RRS feed

  • Question

  • Hi guys,

    Trying to get my team using Wokitems to track our bugs. Here's my understanding of how this works: A new bug comes in, and gets entered into TFS and assigned to a developer to work. When the developer fixes the bug, he associates his check-in with the workitem and marks it as resolved. What happens next? 

    We generally deploy the change to a testing area so the client can kick the tires and verify that they are happy with the fix. (In our case, this simply means copying the individual files related to the fix -- we're using WSP, not WAP). Sometimes it may take a couple of days for them to get around to letting us know they're satisfied with the fix. There's no status for the workitem to show that the bug is currently in that phase, that I can tell. (Is this where custom process templates come in?)

    Also, once the client gives sign-off and we deploy the fix into production, shouldn't the workitem get a new status at that point as well? Overall, it would be useful to see which workitems are open, which ones are fixed, being re-tested, and have been deployed as well as which branch they're in. Is this possible, and I'm just not connecting the dots?

    I'm open to hearing how other teams do this.

    Friday, May 13, 2011 7:26 PM

Answers

  • Hi,

    When teams are using TFS for developing new products (within their own comapny) the active,resolved, closed states are sufficient in most cases.

    When you are participating with customer or third parties in more or less maintenance projects, I can imagine that the states are not enough.

    You can modify the Work Item Definition and add states, reasons and other fields.

    http://msdn.microsoft.com/en-us/library/ms243889.aspx

    I've done many implementations where I added states to follow the scenario that you described above. For example, Active, Resolved, Test, Closed.

    I would recommend to carefully look at the number of states you introduce. I prefer adding reasons to a specific state. For example the State Active has the reasons:

    • ToDo
    • In Progress

    And the reason Test has

    • Ready for Test
    • In Progress
    • ReTest

    Hope this helps

     


    René van Osnabrugge W: www.delta-n.nl B: osnabrugge.wordpress.com T: @renevo
    • Marked as answer by jabell Tuesday, May 17, 2011 2:47 PM
    Monday, May 16, 2011 3:58 PM

All replies

  • Hi,

    When teams are using TFS for developing new products (within their own comapny) the active,resolved, closed states are sufficient in most cases.

    When you are participating with customer or third parties in more or less maintenance projects, I can imagine that the states are not enough.

    You can modify the Work Item Definition and add states, reasons and other fields.

    http://msdn.microsoft.com/en-us/library/ms243889.aspx

    I've done many implementations where I added states to follow the scenario that you described above. For example, Active, Resolved, Test, Closed.

    I would recommend to carefully look at the number of states you introduce. I prefer adding reasons to a specific state. For example the State Active has the reasons:

    • ToDo
    • In Progress

    And the reason Test has

    • Ready for Test
    • In Progress
    • ReTest

    Hope this helps

     


    René van Osnabrugge W: www.delta-n.nl B: osnabrugge.wordpress.com T: @renevo
    • Marked as answer by jabell Tuesday, May 17, 2011 2:47 PM
    Monday, May 16, 2011 3:58 PM
  • Hi Jabell,

     

    Thanks for your post.

     

    For this issue, have you took Rene’s suggestion?


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, May 17, 2011 2:18 AM
    Moderator
  • Thanks Rene, I think this type of suggestion is exactly what I was looking for.
    Tuesday, May 17, 2011 2:46 PM