Unanswered Reporting state change count but filtering on current field value

  • Thursday, August 16, 2012 5:12 PM
     
     
    I'm new to using Report Builder, and I'm trying to generate a report that will show the number of bugs created during a particular date range. However, I also want to filter the data by the build the bug was found in (Work Item.Microsoft_VSTS_Build_FoundIn).  My problem is that the value of FoundIn may not be correctly set at the time the bug is created (some users may leave the field blank or may set it incorrectly, so the value may change at a later date). I'm using State Change Count, and this causes the report to only show me the number of bugs whose FoundIn field was set to my specific values at the time the bug was created (i.e. when the state changed to "Proposed").  The report does not pick up bugs who's FoundIn is currently set to the filter values, which is what I want to see. Any help is greatly appreciated.

All Replies

  • Monday, August 20, 2012 3:22 AM
    Moderator
     
     

    Hi H Connor,

    Thanks for your post!

    Please check out the following link:

    http://blogs.msdn.com/b/jpricket/archive/2010/08/09/tfs2010-customizing-the-build-details-view-summary-view.aspx

    In this link, you can see how to customize the build report summay view.

    If you want to get the related work item, I think that your best option is to modify the build process template using the version control API. For some information about how to access the list of associated changesets and work items inside the build process template, check out the following blog post:http://geekswithblogs.net/jakob/archive/2010/04/15/implementing-release-notes-in-tfs-team-build-2010.aspx

    If you have any concern with it, please feel free to let me know.

    Best Regards,


    Cathy Kong [MSFT]
    MSDN Community Support | Feedback to us

  • Monday, August 20, 2012 4:03 PM
     
     

    Hi Cathy,

    Thanks for your reply, but my question must have been unclear, so I apologize. We are not performing automated builds, and when user's create a new bug, the "Found In" field is optional and the pick list is populated from values that are manually entered into TFS.  Because the field is optional, users sometimes forget to select it, or they often select the incorrect value, which has to be changed at a later date/time.

    Perhaps this will clarify my question. We are trying to create a report in Report Builder that sums the number of bugs created per day for a particular build (Found In). Previously, we had been using the following TFS query to list the bugs that fit this criteria.

    In trying to replicate this TFS query, I created the following Report Builder query:

    The problem is that if a user did not set the "Found In" field to "6.1.1.23" when the bug was created, the Report Builder query does not include the bug in its count, even though the current value of "Found In" *is* set to 6.1.1.23.  The bug count reflects only those bugs whose "Found In" field was set to 6.1.1.23 at the time the bug was created. 

    Is there a way to accomplish  this in Report Builder?

    Thanks for your help!

  • Monday, August 27, 2012 2:40 PM
     
     
    Any ideas on how (or if) this can be done in Report Builder? Thanks.
  • Friday, September 21, 2012 7:21 PM
     
     

    so you want a count of distinct testable bugs where created date between x and y and build found in = z. So remove the filter for State=Proposed, change the date filter to created date. Also I noticed that the query does not include the specified start date filter value (7/20) but does include the end date filter value. To replicate that with "includes"in the report filter change the start date to the following date (7/21).

    Something else I would suggest. Since build found in is important, make it required. If you don't want to delay bug creation while they look up the build number then do not set a default value for the field but add "unknown" or something similar to the list. This will force them to set a value for the field but they can choose unknown (since your build numbers are numeric, "unknown" should be a the end of the list so it won't be the "easy" choice).



    • Edited by Tim Pacl Friday, September 21, 2012 7:22 PM
    • Edited by Tim Pacl Friday, September 21, 2012 7:23 PM
    •