none
Measuring Contract Developer with Excel report

    Question

  • We have multiple contract developers working on our project.  We want to be able to measure the contract developers based off the number of bugs their code introduced to QA Testing or production.  To do this I realize I need to make sure the bugs are linked back to feature tasks (this is a struggle presently in our group).  I know how to create a report showing the developer that fixed a bug but how do I show who originally developed the feature?  For example, If Dev1 developed a feature in January and then it goes to QA in February and they submit a bug that Dev2 fixes in March, I want the report in March to show Dev1 introduced a bug.  Also I presently only have access to the TFS data through Excel and not through any SQL reporting tool.

    Monday, April 23, 2012 1:45 AM

Answers

  • Since both the bug will have a ChangeSet associated and the original Task will have a ChangeSet associated, you might be able to query the TFS_Warehouse for the cross-reference between the two. That way you'll get an indication on who worked on the source file that contained the bug. That way you can derive which tasks and which bugs are related.

    It'd be very hard to figure out exactly who introduced the bug, unless code is really owned by a developer (e.g. one developer has written all the code in a code file). Maybe the bug was caused by a change elsewhere, requiring changes to calling code. In that case, you might say that the bug was introduced by the developer on the receiving end, but had to be fixed by the calling end. 

    Personally I would be against trying to write reports which can be used to blame a specific developer, as bugs might not be caused by incorrect code, but by faulty designs, unclear requirements, bad architecture or unforeseen changes to the .NET framework in patches. All of which are usually outside of the scope of the actual developer. I'd also be against to place blame on a specific developer as code quality is supposed to be a team effort. I might even go as far as to say that if it takes 2 months to detect a bug, you should focus on getting more testing done earlier in the process so that your bugs will surface much earlier. That way the cost of bugs will be greatly reduced and you won't have to care as much who actually introduced the issue int he first place, as it will be caught early.

    Trying to play the blame game can result in a fear culture, which will result in lower quality code overall in the long run. Try to make the whole team responsible for the bugs and the code quality as a whole and ensure that the bugs are found as soon as possible in your development cycle. If needed add some testers or end-users to your development team or have them work together on a regular basis.


    My blog: blog.jessehouwing.nl

    Friday, May 04, 2012 12:07 PM

All replies

  • Hi,

    You can try to add a field which is used to show the developer name.

    And, you can try to customize the warehouse adapter. http://archive.msdn.microsoft.com/Tfs2010SampleAdapter

    Best regards,


    Lily Wu [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, April 24, 2012 7:19 AM
    Moderator
  • Since both the bug will have a ChangeSet associated and the original Task will have a ChangeSet associated, you might be able to query the TFS_Warehouse for the cross-reference between the two. That way you'll get an indication on who worked on the source file that contained the bug. That way you can derive which tasks and which bugs are related.

    It'd be very hard to figure out exactly who introduced the bug, unless code is really owned by a developer (e.g. one developer has written all the code in a code file). Maybe the bug was caused by a change elsewhere, requiring changes to calling code. In that case, you might say that the bug was introduced by the developer on the receiving end, but had to be fixed by the calling end. 

    Personally I would be against trying to write reports which can be used to blame a specific developer, as bugs might not be caused by incorrect code, but by faulty designs, unclear requirements, bad architecture or unforeseen changes to the .NET framework in patches. All of which are usually outside of the scope of the actual developer. I'd also be against to place blame on a specific developer as code quality is supposed to be a team effort. I might even go as far as to say that if it takes 2 months to detect a bug, you should focus on getting more testing done earlier in the process so that your bugs will surface much earlier. That way the cost of bugs will be greatly reduced and you won't have to care as much who actually introduced the issue int he first place, as it will be caught early.

    Trying to play the blame game can result in a fear culture, which will result in lower quality code overall in the long run. Try to make the whole team responsible for the bugs and the code quality as a whole and ensure that the bugs are found as soon as possible in your development cycle. If needed add some testers or end-users to your development team or have them work together on a regular basis.


    My blog: blog.jessehouwing.nl

    Friday, May 04, 2012 12:07 PM
  • Using the method you describe in your original question, link the CurrentWorkItemView (CWIV) to vFactLinkedCurrentWorkItem (LCWI) on CWIV.WorkItemSK = LCWI.SourceWorkItemSK then link back to CurrentWorkItemView (CWIV2) on LCWI.TargetWorkItemSK = CWIV2.WorkItemSK. CWIV is where you get the defect, CWIV2 is where you get the feature/task that the development was done under. CWIV2.AssignedTo should then be the developer that introduced the bug.

    To Jesse's point, however, just using workitem linking to do this may be a flawed approach as it relies on users to accurately identify the appropriate feature. This will take some policing and I think will likely be inaccurate until the bug is closed and verified so I would restrict the query to only closed/verified bugs. This still has potential issues since a changeset may be linked to multiple work items (features/tsks/bugs) or none at all. Also a changeset may even include file from multiple projects and bug fixes.

    If you link changesets back to work items you can use the WorkItemChangesetOverlay go from a changeset to the linked work items.

    Monday, September 24, 2012 4:16 PM