# Wednesday, November 25, 2009

I learned a very important tip today about Microsoft Test & Lab Manager.  The data collectors that you can specify in your test runs (which by the way are extremely helpful) don’t necessarily attach data to the test run or bug all of the time.  It depends on the actual success of the test case during the test run.  Two example were mentioned today:Visual Studio Data Collectors in Microsoft Test and Lab Manager

  • IntelliTrace – The IntellIiTrace data collector will only output a trace log if the test case fails.
  • Test Impact Analysis – The Test Impact data collector will only publish test impact data back to Team Foundation Server if the test case succeeds.

So this leads us to the fact that we won’t ever see both of them together at the same time.  If you see an IntelliTrace trace log file for a test case then you won’t be getting any test impact data published to the server (and vice versa.)  Be sure to have both of them enabled though if you would like to get that type of data when the test case ends.  This also helps me in figuring out why I haven’t been getting impacted tests in my build reports and the handy view of “recommend tests” based on choosing a build in MTLM.  I need to actually pass some tests to get that data published back up to the server!

 

How about that?  Very handy to know.  The Visual Studio Quality Tools team has a blog that has been very active lately.  If you would like to learn more about Microsoft Test & Lab Manager head on over to the site.

Ed Blankenship

posted on Wednesday, November 25, 2009 6:13:23 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Monday, November 09, 2009

If you’ve had the responsibility of administering a TFS 2005 or TFS 2008 server you may have run in the “Display Name” problem before.  In March 2007, the TFS Work Item Tracking team put a great post together about what’s exactly going on and it’s available here:  http://blogs.msdn.com/teams_wit_tools/archive/2007/03/15/handling-display-name-changes-in-team-foundation-server.aspx

Basically, in TFS work item types, you can specify a field to hold the name of a user like in the Assigned To field.  The value that gets stored is basically just a string value of the person’s Display Name in Active Directory.  Not so bad except it’s not a strongly-typed object of a user but is just a string.  The problem comes when the user’s display name gets changed in Active Directory like when an employee gets married and take’s their spouse’s last name.  This causes a problem because all of the work items are still assigned to “Jane Doe” instead of “Jane NewLastName".  Even worse, “Jane Doe” is not even a valid user any longer so the work item becomes in an invalid state.  It’s kind of a maintenance nightmare.

Background:  Every hour an Active Directory synchronization job gets queued up and processes changes to Active Directory like new users, group membership changes, etc.  TFS keeps a cache of AD locally to help with operations across several subsystems.  For users, it caches certain information like the primary e-mail address, display name, domain/user name, SID, distinguished name, etc.

Thankfully there was something that helped us out available in the TFS Power Tools release called “TFS Users.”  You had to know about the display name change so working closely with your IT department was important.  Thankfully, it looks like TFS 2010 has added some abilities to notice those display name changes and proactively help you out within your system.  One of those changes is a new attribute in your work item type definitions that tells TFS which fields to automatically update.  I’ve bolded and underlined all of the changes from the previous default definition of the MSF Agile Bug.

<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
  <VALIDUSER />
  <HELPTEXT>The person currently working on this bug</HELPTEXT>
</FIELD>
<FIELD name="Activated By" refname="Microsoft.VSTS.Common.ActivatedBy" type="String" syncnamechanges="true" reportable="dimension">
  <WHENNOTCHANGED field="System.State">
    <ALLOWEXISTINGVALUE />
    <READONLY />
  </WHENNOTCHANGED>
</FIELD>
<FIELD name="Changed By" refname="System.ChangedBy" type="String" syncnamechanges="true" reportable="dimension">
  <ALLOWEXISTINGVALUE />
  <VALIDUSER />
</FIELD>
<FIELD name="Closed By" refname="Microsoft.VSTS.Common.ClosedBy" type="String" syncnamechanges="true" reportable="dimension">
  <WHENNOTCHANGED field="System.State">
    <ALLOWEXISTINGVALUE />
    <READONLY />
  </WHENNOTCHANGED>
</FIELD>
<FIELD name="Created By" refname="System.CreatedBy" type="String" syncnamechanges="true" reportable="dimension" />
<FIELD name="Authorized As" refname="System.AuthorizedAs" type="String" syncnamechanges="true" />
<FIELD name="Resolved By" refname="Microsoft.VSTS.Common.ResolvedBy" type="String" syncnamechanges="true" reportable="dimension"> <WHENNOTCHANGED field="System.State"> <ALLOWEXISTINGVALUE /> <READONLY /> </WHENNOTCHANGED> </FIELD>

If you have custom process templates or you have modified the out of the box process templates, you’ll have to do some maintenance to your existing team projects to light up the new TFS 2010 features available including the ability to automatically sync the name changes from Active Directory.  If you are using the MSF Agile template you will want to update the following fields:

  • Assigned To
  • Activated By
  • Changed By
  • Closed By
  • Created By
  • Authorized As
  • Resolved By

For all other process templates, you’ll want to update the work item types that have fields that hold display name values.  There is actually some great information already available about this particular topic available in the MSDN Library:  http://msdn.microsoft.com/en-us/library/dd286562(VS.100).aspx

One of the other things we notice from the changes are the addition of the ALLOWEXISTINGVALUE rule to some of the fields.  This rule allows a previously entered value to still be valid even if that value is no longer a valid value.  In addition, there are also some state/transition rule changes for allowing the existing value.  Be sure to do a diff against your current work item type definition and the new MSF Agile work item type definitions to find all of the new changes.

For more information about managing work item type fields in TFS, see this MSDN Library Article:  http://msdn.microsoft.com/en-us/library/dd236909(VS.100).aspx

 

Ed Blankenship

posted on Monday, November 09, 2009 2:26:38 PM (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback

I don’t know how many times I’ve heard this suggestion from people:  “Microsoft should just buy TeamPrise and make the Eclipse and non-Windows clients just part of the TFS product.”

That day is finally here.  Microsoft has purchased the TeamPrise-related assets from SourceGear.  More details about the acquisition announcement are available at Microsoft’s PressPass site and also the Pathways site for TeamPrise and Visual Studio.

Also, in addition to purchasing the TeamPrise assets, Microsoft has also hired a majority of the development team including, most notably, Martin Woodward who has been an absolutely fantastic part of the “Team System” MVP group.  It will be really sad to see Martin leave the group (as of today) but something tells me that he won’t be hiding :)  Congratulations to him and the entire team!

Now the one thing that i think people might be worried about will be what will happen to the future of the TeamPrise clients and will that development team be able to innovate as quickly as they had before?  I’m pretty sure the same “mission” will be in place and the team will be able to more closely leverage the other team members and assets within the Team Foundation Server product team.  As far as speed of innovation, that’s tough to tell.  Most other Microsoft products have tons of release requirements that slow them down such as localization, security reviews, etc.  All of which are great things but do end up slowing you down if you have to support those requirements.  Who knows if the TeamPrise development team will have to support them?  My guess is that if they’re going to be part of the “Visual Studio” product line that they will have the very similar if not the same requirements as the rest of the stack.  We will definitely see…  Another possible hang up is that Microsoft (specifically Developer Division) will have to learn how to sell & market a Java/non-Windows based product.  I can only imagine there will be some growing pains.

As far as licensing, right now you’ll need to still purchase the TeamPrise clients and get support from TeamPrise directly.  A Microsoft-branded “TeamPrise” client will become available with the 2010 release.  If you own a current license of the TeamPrise 3.3 software it looks like you’ll be upgraded to the new version when it is released.  Also, if you own a Visual Studio 2010 Ultimate with MSDN license at the time you’ll get access to download the new clients from MSDN Subscriber Downloads.  After the 2010 release, it looks like there will be a new SKU available to be able to purchase just the new clients that will also include a CAL for Team Foundation Server that will run somewhere around $799 retail.

I’m excited about the decision and it looks like both Martin and Brian Harry are as well.  I’m excited to see the platform broaden and truly support teams who have heterogeneous development environments!

 

Ed Blankenship

posted on Monday, November 09, 2009 11:57:26 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Tuesday, November 03, 2009

Looks like there is a new migration tool being made available that helps you with importing test cases into TFS 2010 which now has Test Case Management as one of it’s new features.  It’s now available on CodePlex and works with the Beta 2 release.  Here’s some of the features available:

  • Imports Test case information (along with Test Steps) present in Excel into TCM/TFS server – Note: This is ONE way migration only
  • Provides a wizard based UI to run the tool one file at a time
  • Provides a command line support to run the tool in a batch mode
  • Allows you to save your selections/configurations into a mappings file to be reused later
  • Default mapping file that works across both Agile based and CMMI based projects are shipped along with the tool

http://tcmimport.codeplex.com/

I believe some systems allow you to export your test cases into Excel (HP Quality Center?) so this might be a good migration option.  You can also use the TFS 2010 SDK to build a custom migration utility that will import from another system without having to go through Excel at first.  Take a look at it and see if it might be helpful for you!

 

Ed Blankenship

posted on Tuesday, November 03, 2009 11:24:54 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback