I am often asked if there is a way to see a “traceability matrix” in TFS. Different people define a “traceability matrix” in different ways. If you want to see how many tests there are for a set of requirements, then you can use SmartExcel4TFS. However, this doesn’t tell you what state the current tests are in – so you can’t see how many tests are passing / failing etc.
Unfortunately there is no TechEd Africa this year – Microsoft have opted to go for smaller, more focused sessions in multiple cities (or at least that’s what I gather). I think it’s a shame, since the TechEd Africa event was always fantastic – and who doesn’t like getting out the office for a couple of days?
Over the last couple of months I’ve done several implementations and upgrades of TFS 2013. Most organizations I work with are not developing boxed software – they’re developing websites or apps for business. The major difference is that boxed software often has more than one version of a product “in production” – some customers will be on version 1.0 while others will be on version 2.0 and so on. In this model, branches for each major version, with hot-fix branches where necessary – are a good way to keep these code bases separate while still being able to merge bug fixes across versions. However, I generally find that this is overkill for a “product” that only ever has one version in production at any one time – like internal applications or websites.
I was working at a customer that had set up a test TFS environment. When we set up their “real” TFS, they did a get-latest of their code and imported their code – easy enough. They did have about 100 active work items that they also wanted to migrate. Not being a big fan of TFS Integration Platform, I usually recommend using Excel to port work items en masse.
We’ve been working on a rewrite of our Timetracking tool (formerly Notion Timesheet) and it’s going live today – Imaginet Timesheet! Timesheet lets you log time against TFS work items using a web interface. The web site can be installed on any IIS server (if you want to host it on-premises) or even onto Windows Azure Web Sites (WAWS) if you have a public-facing TFS or are using Visual Studio Online. Once you’ve installed it, just log in, select a date-range (week) and a query and start logging time.
In a previous post I wrote about how to do JavaScript unit testing in VS 2012. The same procedure applies to VS 2013 – but the Chutzpah test adapter now allows you to run code coverage too. At the end of my post I link to another blog entry about how to enable the tests to run during team builds.
Keep going!Keep going ×2!Give me more!Thank you, thank youFar too kind!Never gonna give me up?Never gonna let me down?Turn around and desert me!You're an addict!Son of a clapper!No wayGo back to work!This is getting out of handUnbelievablePREPOSTEROUSI N S A N I T YFEED ME A STRAY CAT