Top 10 Most Often Overlooked Features in Visual Studio Team System

Features, features, features - Visual Studio Team System is just chock full of them.

But of course, as any good sales/marketing person will tell you - sell benefits, not features!

Sometimes, in following this good advice, some features get lost and forgotten about.

Anyways, I thought I would pick out a few that I think don't quite get the attention that they deserve.

Here they are, in no particular order

1. Web Test Transactions

The transaction feature just enables to capture timing across a series of pages.  For example, let’s pretend that registering for a site involved a user going to the following pages.

1. www.mygame.com
2. www.mygame.com/register.aspx
3. www.mygame.com/information.aspx
4. www.mygame.com/interpretcaptcha.aspx

By default, you would get per-page (or per-request) data which is useful.  In some cases, however, you might want to know what the overall user experience for a given scenario is like. For example, you might ask, how long does it take a person to sign up for the game? 

In that case, you would create a transaction called ‘User Registration’ and put each of those page requests under that transaction. 

When you run the load test, you’ll get per-transaction data as well. So then you can see the average amount of time it took to execute those 4 pages together. Sometimes the system integration type companies will get SLA requirements like ‘a new user registration must be completed in 4 seconds or less’; that feature helps verify it.

2. Load Test Timing Details Storage

This property captures really interesting information, but it is not on by default. From the documentation (http://msdn2.microsoft.com/en-us/teamsystem/aa718897.aspx), a quick description about this feature.

"If Timing Details Storage is enabled, then the time to execute each individual test, transaction, and page during the load test will be stored in the load test results repository. This allows 90th and 95th percentile data to be shown in the load test analyzer in the Tests, Transactions, and Pages tables."

3. Merging Code Coverage Results

This one is quite cool - if you ever have a bunch of individual test results that address the same set of code and you wonder what the collective code coverage of those tests are, you can merge the code coverage results together with this feature.

4. Uploading documents from the Team Explorer

Actually, this is probably news to nobody except for me :) Being a very small company, I don't make too much use of the Team Portal. But, if you do, remember that you can upload documents directly from the Team Explorer node if you do not want to go to the Team Portal site. You can also create new folders and document libraries; very cool!

5. WasEver clause in WIQL

I mention this a lot whenever I train or present, but the wasever clause is very powerful in WIQL. For example, you can quickly see what bugs have regressed in your project by using 'state wasever resolved'.

6. Test MetaData

I try to mention this whenever I get the chance, but there is a wealth of metadata that you can associate with any type of test in VSTS. This metadata is available by viewing the properties of a test in the Test View. Anything from the person that owns the test, to the area that the test addresses can be attached.

7. The Test View can group!

If you ever need to organize your view of your tests, you can group by a number of fields; this is where using metadata like owner or area really helps.

8. You can export Performance Reports

 

This one is close to my heart; sometimes it is just easier to process dense performance reports when they are in XML or CSV format. Exporting a performance report gives you that option.

9. Cloaking items in Workspaces

I've talked a little about this one before. Sometimes there will be things that you don't want in your workspace. Maybe it is a bunch of image files, or documents, or old code. Most of the time, when you are editing your workspace, you are figuring out what you want to work on. The cloaking feature allows you to specfy what you don't want to work on or worry about.

10. Exit Criteria choice in a Task

Last, but certainly not least is the humble Exit Criteria indicator on the default Task work item type. 

I'm often guilty of looking at only the Description tab in a Task; but there is a wealth of good data in the other tabs too :)

One of these is the field that indicates whether the given task is used to determine whether the current milestone or iteration can be exited. If you use this field diligantly, you can build a better picture of when you are close to the end of an iteration.

Anways, there are many more features out there built by the hardworking folks on the development team; apologies for the ones that I've missed.

Thanks!

Eric.