How to export Test Artifacts from TFS

TFS 2013 Update 2 (CTP 1) brings in another cool update. Till now, we have been using Test Scribe to export Testing related artifacts from MTM. With the latest update, some of those artifact export features are part of the product. From the web interface, we should be able to export the whole Test plan and Test suites. Artifacts can be exported as email or printed and configured to print as PDF or to OneNote or whatever you prefer…

Below is my sample Test plan and suites

Export at the Test Plan level

Export at the Suite level

You will see another dialog asking for some inputs to export appropriate content

 

  1. What to export from “Test Plan”
  2. What to export from “Test Suite”
  3. Where to export – to “Email”
  4. Where to export – to “Printer”

Though these are pretty simple options, output offers moderately attractive data

Information about the whole plan.. suite hierarchy (the ID next to the plan is not work item id..)

 

Test case and associated Requirement and Parameters

 

Although, we don’t get the Test runs, execution summary, results and other things that Test Scribe offers, those might be on the way in next update..

PowerShell+update TFS build properties

If you are wondering how to update some build properties like ‘build quality’ or overwrite ‘retention policy’ or some other TFS Build property dynamically/scriptically…. PowerShell is a good option….

After I deploy the build on a test environment, I wanted to update ‘build quality’ and ‘lock’ a specific build for reference –  so that my retention policy doesn’t wipe off the build….. naturally Visual Studio Team Foundation Client provides a tiny ‘lock’ symbol and it does provide interface to manage build quality too…. they appear right on the build explorer window and are simply perfect….however, I tend to forget that operation post deploy – meaning the way I got my deploy is completely unattended……of course, my retention policy retains only 5 builds…its embarrassing  when a developer seeks a specific build inorder to  reproduce a defect….. 😦

When  I was seeking ways to automate this task..certainly there are ways like MSBuild custom task etc…. but I hate to write c# code, compile, reference that in MSBuild …. PowerShell was an elegant and neat option for my need…. loads the assembly at runtime…. no compilation, msbuild etc….

So the following script can be used to set build properties automatically post deploy – simply call powershell.exe with appropriate parameters….

here we go..

#must pass inputs in the following order

#1. TFS Uri 2. project name 3. build definition 4.build number 5. build quality 6. retain(true,false)

param (

[string]$TfsServerUri = $args[0],

[string]$ProjectName = $args[1],

[string]$BuildDefinitionName = $args[2],

[string]$MyBuildNumber = $args[3],

[string]$MyQaluty = $args[4],

[bool] $retainBuild= $args[5]

)

$ErrorActionPreference = “Stop” ;

if ($Verbose) { $VerbosePreference = “Continue” ; }

Write-Verbose -Message “Loading TFS Build assembly…”

[void][System.Reflection.Assembly]::Load(“Microsoft.TeamFoundation.Build.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”)

Write-Verbose -Message “Loading TFS PowerShell snapin…”

$TfsSnapin = Get-PSSnapin -Name Microsoft.TeamFoundation.PowerShell -ErrorAction SilentlyContinue ;

if ($TfsSnapin -eq $null) {

Add-PSSnapin -Name Microsoft.TeamFoundation.PowerShell ;

}

Write-Verbose -Message “Getting TFS server instance…”

if ([string]::IsNullOrEmpty($TfsServerUri)) {

$TfsServer = Get-TfsServer -Path (Get-Location) ;

} else {

$TfsServer = Get-TfsServer -Name $TfsServerUri ;

}

Write-Verbose -Message “Querying builds…”

$BuildServer = $TfsServer.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer]) ;

$DetailSpec = $BuildServer.CreateBuildDetailSpec($ProjectName, $BuildDefinitionName) ;

$DetailSpec.QueryOrder=”FinishTimeDescending”;

$DetailSpec.MaxBuildsPerDefinition=10;

$Builds = $BuildServer.QueryBuilds($DetailSpec).Builds;

$(foreach ($build in $Builds) {

if ($build.BuildNumber -match $myBuildNumber)

{

$build.Quality=$myQuality;

$build.KeepForever=$retainBuild;

$BuildServer.SaveBuilds($build);

}

});
hope this helps someone…..

Red ‘x’ on Builds node…..

Number of times we have had bizarre behaviour with Team Foundation Client for Visual Studio….both 2005 and 2008…

1. Red ‘x’ on Builds node… if you closely notice it would be Build instead of Builds….

2. TF31001: Team Foundation cannot retrieve the list of projects from Team Foundation Server…..

Both the above scenarios were specific to local and specific to my workspace…. both the occasions, TFS event log, database connectivity and other basic things were just perfect….others were working good… I was able to guess its something to do locally….

I uninstalled VS, TFPT etc… and reinstalled… still it was challenging…

Finally… one of the posts helped me with the following solution… looked to be something currepted locally…

  • Rename “C:\Documents and Settings\<User>\Local Settings\Application Data\Microsoft\Team Foundation\1.0” or 2.0
  • Start –> Run : “devenv /resetuserdata”.

This will reset your Visual Studio user data…..be careful before trying this..

TFS & PowerShell

PowerShell has got excellent features could be useful for SCM tasks….for example, I wanted to monitor history of set of files(say 25) on a weekly basis… I know history command will do but still did not want to do that manual work weekly… if we go for .cmd file… getting the date difference was a challenge… meaning…. everyweek we need to take the history for the past 7 days…which means you need to manipulate date variable… I wasn’t really sure whether its possible in batch scripts…

but powershell does that in 1 line…

executing tf.exe was simple enough…..

here we go….

$TFExecutablePath = “C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\..\IDE\TF.exe”
$file = <path>
$outputFile = <path>

$a=get-date
$a=$a.addDays(-7)
& $TFExecutablePath history $file /version:D$a~T | Out-File -filepath $outputFile -append

So sweet….. though scheduling this script took me a few hours, its great….. enjoy guys…. 🙂

Team Foundation Server and Requirements Management….my crudites

It’s been my wish to join the best & brightest group of people who have been actively consuming, woodcrafting, living, loving TFS.  Finally it starts here with my cocktail…. TFS and requirements management…. I’ve tried to be very simple and 1st course of meal provides only the overview and setting the expectation right…what TFS can do for your shop and what not…

Here we go….

Is TFS a comprehensive “requirements management” tool….?????

TFS wasn’t designed specifically to support a requirements management process……However, we can leverage the features to manage the development process…..TFS can help support a productive RM process

How????

2 primary ways
SharePoint or Team Portal
Same as your existing (might be) repository, like a network share for authoring and tracking your specifications
Work Items
TFS provides work item tracking to allow items (bugs, tasks, or in this case, requirements) to be treated as individually managed objects with their own workflows, attributes, and traceability

Team Portal (Sharepoint)

  • Team Foundation Server creates SharePoint-based (specifically Windows SharePoint Services) web portals automatically when you create a new project.
  • It’s the document library that provides a natural fit for bringing your specifications a little more in line with the rest of the application lifecycle.
  • Allows analysts to remain in their comfort application (MS-Word)
  • Changes to requirements is much more accessible to those that will consume those requirements (architects, developers, testers, etc.).
  • How to access?
  1. Team Explorer (either embedded in Visual Studio or as a standalone client)
  2. TFS Web Access

Value-add

  • Changes are tracked, and linked, at the document level.
  • Analysts remain in comfort application (Word, etc.)
  • SharePoint is a “natural” extension in Word/Office applications
  • Requirement specs are more easily consumed by other roles in lifecycle.
  • Provides basic mechanism to enable traceability and better “cross-artifact” reporting.

Drawback

  • Still don’t have granular control over individual requirements changes. ‘Lack of item-level granularity’
  • Document-level linking only (can’t link to an individual requirement inside specification document)
  • Document Workflow managed by SharePoint, whereas Workflow for other lifecycle artifacts are managed by TFS.

WorkItems:

  • A fast and flexible way to track any item of record throughout a lifecycle
  • Managed by TFS in TFS database
  • Provides a proper level of granularity for controlling change and traceability.
  • Customizable – Create and customize Work Items – example, we can create work item types that represents Business, Functional, and Non-Functional and have own set of attributes.
  • How to access?
  1. Team Explorer (either embedded in Visual Studio or as a standalone client)
  2. TFS Web Access
  3. Excel & Project

Advantages:

  • All changes will be recorded and audited
  • Links can be created between individual requirements and other work items (any type), source code, test results, and hyperlinks)
  • Workflow is enforced and controlled in the same manner as all other work item types
  • Supporting information (screenshots, documents, UML diagrams, etc.) can be attached
  • Reporting can be much more granular (showing requirement implementation rates, impact analysis, scope creep).

Challenges:

  • Change of interface may meet resistance (no more Word!)
  • Customization work most likely involved (creating custom work item types, fields, & workflow).

Work Item customization – how open is that…..??

  • TFS SDK – you can write a custom lightweight interface for business analysts to enter and track requirements work items in TFS.
  • SQL Server Reporting Services – to create custom report

we’ll talk more on work items, tracking, customization, 3rd party RM tool integration, reporting in upcoming posts….stay tuned…. 🙂