Jason Barile - Microsoft in Raleigh, NC

Roundup: Tips For Improving TFS 2008 SP1 Performance

2009-09-02T12:47:39Z

From time to time, I get questions from customers on how to diagnose performance issues with their TFS 2008 SP1 servers and how to improve performance. Here’s a set of blog posts I refer to frequently, now rounded up into one convenient place:

General TFS Performance

TFS Performance. Episode 1 - The Phantom Baseline - a post from the TFS Global Support Team on how to establish a baseline for performance of your Team Foundation Server
TFS Performance Tips & Tricks – Part One – general TFS performance tips from the TFS Global Support Team
TFS Performance Tips & Tricks – Part Two – more TFS performance tips from the TFS Global Support Team
TFS Performance & Excel 2007 Heat Map – Grant Holliday on using Excel to monitor day-to-day performance of TFS
Announcing TFS Performance Report Pack – Some great reports from Grant that will help you monitor TFS performance
Monitoring Team Foundation Server (MSDN) – A collection of articles on MSDN about how to monitor performance of your Team Foundation Server
Download TFS 2008 SP1 – We made a lot of performance and scale improvements in SP1, so if you’re not using it yet, what are you waiting for?

Version Control

Walkthrough: Setting up a Remote Office with Team Foundation Server (MSDN) – How to install and configure the TFS proxy to improve version control performance at remote sites (or even just distribute TFS load across multiple teams)

Team Build

TargetsNotLogged Hotfix Available (Aaron Hallberg) – A hotfix to improve the performance of some Team Builds
Configuring the build to use the version control proxy (Buck Hodges) – Helpful if you have a Team Build server running at a remote site

Work Item Tracking

Filtering WIT Client Meta-data (Martin Woodward) – how to reduce the amount of meta-data that flows between TFS and Team Explorer

8 Tips For Doing Ad Hoc Tech Support via Twitter

2009-08-20T19:36:59Z

I do a lot of ad hoc technical support for Team Foundation Server via Twitter (follow me at @JasonBarile). As a Test Manager, I love interacting with customers directly, and I often find that Twitter is a great source for finding issues people get frustrated about but don’t necessarily get blocked by or get upset enough about to open a support ticket for. It’s opened up a whole new pipeline of feedback for me, and I’m finding it incredibly valuable.

I’ve been doing this for several months now, and I’ve picked up a few tips and tricks along the way I’d like to pass along.

Tip #1 - Twitter Search – Finding those in need of help

Use Twitter’s search feature with keywords related to your product to find people who are discussing and possibly in need of help. You can use a desktop Twitter client like Tweetdeck or Twhirl to keep up with multiple keyword search streams at once. Be careful to make sure you’re responding to the right topics! For example, “tfs” can mean “Team Foundation Server”, “The Fashion Show”, “Transformers”, or simply “Thanks for sharing!” Often, when a tweet shows up in my keyword searches, I’ll view the public stream and/or profile of the person who posted it to make sure they’re talking about what I think they’re talking about.

Tip #2 - Retweet helpful tips

“Retweeting” is when you repeat what someone else has tweeted as a quote. This helps spread useful or interesting information to your followers and can also help the person you’re quoting get new followers. Remember, in a social media environment like Twitter, helping others get visibility is a big part of building up your credibility. When someone tweets something relevant about your product you think others might find useful, retweet it to spread the word.

Use retweeting sparingly though. Some people are really turned off by people who do more retweeting than tweeting original content. The same goes for tweeting links – do it sparingly.

Tip #3 – Don’t Try to have the whole conversation in Twitter

Having an entire customer support conversation in Twitter can be exhausting. Not only are you dealing with a 140 character limit on each tweet, but you’re also dealing with delays between parties in the conversation. Often, I’ll redirect customers to post questions in our support forums, where they can include screenshots, snippets of log files, and a lot more text describing their questions. Then, once an answer is found to their issue, I’ll tweet a link to the thread back to Twitter to help other people with the same problem find the solution.

Tip #4 – Use Screenr.com

If a picture is worth a thousand words, then a screencast is worth a million Tweets! This website lets you or your customers easily record desktop screencasts of up to 5 minutes in length and share them via Twitter. I’ve found it to be an easy way to have customers demonstrate issues or bugs they’re running into and for me to share back screencasts showing how to solve or work around the problems. Since it’s a Java applet, Screenr works on Mac and Windows machines. You can even record audio along with your screencasts. Screenr lets you select the full desktop window (only one monitor though) or resize to capture just the specific window/area you want. Best of all, it’s free!

Tip #5 – Keep it personal

I’ve found that I have a lot more luck getting customers to engage with me on Twitter if I contact them with my personal Twitter account than with a “corporate” account. When customers are frustrated, confused, or angry, having a personal contact to vent to helps put them more at ease.

Tip #6 – Don’t solve every problem

This one may sound counter-intuitive, but you shouldn’t strive to solve every problem. Instead, consider holding back and letting your community of experts have some of the fun too. When they come up with solutions, retweet their answers. If you have a sizable customer base, you certainly won’t be able to handle all the incoming questions yourself, so encouraging others to participate in the social help community is a good thing.

Tip #7 – ‘r’ when replying

Since Twitter changed their rules for visibility on replies, your followers cannot see your replies to others unless they are also following that person. You can work around this to some extent by adding a ‘r ‘ in front of your reply. For example, “r @JasonBarile nice to see you” as opposed to “@JasonBarile nice to see you”. This can work to your advantage too. More often than not, you can have a “semi private” conversation with a customer by simply replying back and forth without resorting to asking them to follow you so you can send them direct messages. When you’re ready to surface the solution, reply back with a ‘r’ and your other followers can see your tweet.

Tip #8 – Coordinate with your other team members

There is such a thing as caring too much! If other people on your team are using Twitter and have their own keyword searches, consider coordinating who will be replying to customers each day on a per-customer basis. Just make sure you’re not deluging your customers with multiple “we want to help you!” messages – it can be a real turnoff.

Another angle of this tip is to make sure you’re not constantly randomizing your team with every little issue you run across in Twitter. Put together a response plan with your team’s leadership for how often you’ll escalate issues to your team and what types of issues you’ll escalate. While it’s tempting to want to be able to help everyone, it can be a time suck, and unless this is your full time job, chances are that you and your teammates have other responsibilities too.

Those are my tips for now. If I think of others I’ll update this post. If you have more tips to share, please leave comments. See you in the Twether!

Some Benefits of “Checkout” in TFS Version Control

2009-08-18T15:18:00Z

One of the more common points of confusion around TFS source control is the checkout model. This typically comes from users who are more familiar with the checkout-less model (e.g. Subversion). I acknowledge the TFS approach is a different model, and there are certain advantages and disadvantages to each approach.

For single users or very small development teams where you don’t have 2 or more people working on the same files very often, I understand the feedback that the checkout model in TFS feels heavyweight at first glance. We’re listening to your feedback and we’re looking at options to improve this experience in future releases. In the meantime, I hope this list helps explain some of the advantages in the TFS approach (as I see them).

1. You can see what other people are working on. When you view source files in the Source Control Explorer under Visual Studio or use the “tf status” command line command, you can see who else has files checked out and what types of pending changes they have. Most often, you’ll see “edit” commands, but occasionally you’ll see someone with a pending delete or rename that could cause headaches for you when you try to merge your changes to the file later (if they commit first, for example). Knowing this in advance helps you know when you need to either commit your changes first or to start a conversation with the other person modifying the files. Also remember that in a team environment, people other than developers might be interested in knowing what changes are coming up. Testers, for example, might want to get prepared for upcoming changes by watching who is currently working on files for features they test. Note that you can only see what types of pending changes other people have on files and folders, but you cannot see the actual changes until they are committed to the repository.

2. Prevent two people from trying to edit the same non-mergable file types. Certain file types such as images, audio files, SQL Express databases, etc. cannot be merged. Many of these file types are configured for “exclusive checkout” out of the box in TFS. This means only one person can check them out for editing at once. This prevents the ugly situation where 2 or more people have modified the file and then try to commit their changes back to the repository. For these non-mergable file types, the only 2 options are to check in and replace the latest version with your own or to discard your changes. A TFS administrator can add or remove file types from the “exclusive checkout” list.

3. Allows an administrator to limit who is allowed to make changes to a file before they make the changes. Rather than finding out when you try to merge your changes back to the repository that you don’t have permissions to edit a file, an administrator can limit who has the “checkout” permission. If you try to check out a file for editing and don’t have this permission, then you’ll find out before you spend any time actually modifying the file.

4. You can easily undo local changes. Since the server knows what you’re working on and what version you started from, you can easily discard some or all of your pending changes and revert back to the state you started from. Use the Undo Pending Changes context-menu command in the Solution Explorer or Pending Changes Window, or “tf undo” from the command line. Issuing an “undo” will revert your local files back to the state they started from, even if other people have committed changes to the server since you initially checked out your files for editing. If you want to catch up to the latest versions on the server, just do a “Get Latest”.

5. (TFS2008 forward) You can “get latest on checkout”. TFS 2008 and later versions have a feature (off by default) that will automatically get the latest version of a file when you check it out for editing. This is handy because you always know you’ll be working on the latest committed version when you start making changes. Of course, other people might come along and commit changes before you commit yours, but in general it should help to reduce the number of merges you need to do by making sure you’re not starting off from an older version of a file. This is especially helpful for users migrating from Visual Source Safe which had a “Get Latest on Checkout” behavior. Note that this could lead to a state where your project doesn’t build after you check out files (because you have the latest version of some and older versions of others), and that’s why it’s off by default.

For reference, here are some related articles and posts that might be helpful to you:

As always, we love to get feedback on what does and doesn’t fit your needs. Feel free to post your thoughts on the checkout model of TFS here or in our forums.

How to undo a pending change in a workspace you no longer have

2009-08-10T18:05:36Z

Not that it’s a huge deal to have stale workspaces lying around, but if you’ve ever wondered how to undo a pending change on a workspace you no longer have (e.g. if you repaved your computer to install Windows 7 and didn’t delete your TFS workspaces first), here’s how to do it:

1. Fire up the Visual Studio command prompt (Start –> Visual Studio –> Visual Studio Tools, Visual Studio Command Prompt)

2. If you have a valid workspace against the server of interest, change into that directory.

3. Run the following tf.exe command:

tf undo /workspace:OLDWORKSPACENAME <filespec…>

For example:

tf undo /workspace:VistaLaptop $/Spark/WidgetBox/ /r

In this example, the name of the old workspace I’m trying to undo changes from is “VistaLaptop”. The filespec for the changes I’m undoing is “$/Spark/WidgetBox”, which is a folder name. To undo all the changes I had pending against that tree, I added the “/r” (recursive) switch.

If you don’t have a valid workspace against that server anymore, you can just add the /server switch to specify the server name or URL.

How to connect to a TFS 2010 server from a 2008 Team Explorer client

2009-08-10T15:10:00Z

In TFS 2010, we’ve added a new organizational concept called Team Project Collections. This abstraction helps with flexibility in administration scenarios. One TFS 2010 server can host multiple collections of Team Projects. When you’re connecting to a TFS 2010 server, think of a collection as a logical server. That is, with TFS 2010 you’ll connect to a collection of projects, whereas with previous releases you connected to the actual server name.

1. To Connect to a TFS 2005/2008 server from a 2005/2008 Team Explorer client – you just enter the server name and change the port (if your server uses https or a non-default port).

In Team Explorer 2008 The “Add Team Foundation Server” dialog box looks like this:

Here, the text “vstfdevdiv” is the name of the TFS 2008 server. When you click OK, you’re presented with list of available Team Projects to choose from.

2. To Connect to a TFS 2010 server from a 2008 SP1 Team Explorer client – you’ll need to enter the full server URL:

Note the differences. Here, the URL refers to the server name, the server’s port number, the web application’s path (“tfs”), and the name of the Team Project Collection you’re connecting to (“VSTFDF”). Once you click OK, you’ll see the familiar list of available Team Projects to connect to. Also, note you'll need to install VS 2008 SP1 on top of Team Explorer 2008 in order to be able to enter the full URL. Otherwise, the dialog will complain that you've entered invalid characters for the server name.

If you’re connecting to a TFS 2010 server from a Team Explorer 2010 client, you only need to enter the server name since 2010 clients know about the new abstraction layer in 2010 servers.

Mining Work Items for Opportunities to Improve Your Engineering Process

2009-06-18T15:07:13Z

One of the things I spend a lot of time doing as a test manager is mining for interesting data in our work item tracking system (TFS of course).

For example, this morning, I went through a query of bugs that had been resolved as “won’t fix” but were also marked as regressions from previous releases. Most of these were correctly resolved because we’ve rewritten some features and the new features have different/improved functionality. But a few of them had truly worked in past releases and were now broken and for whatever reason our feature teams had decided not to fix them. Because we had added the “regression” field to our bug form and because people had correctly filled out these fields, we can easily identify such issues and dig into whether or not these decisions were correct.

Out of the box, the bug forms in the Agile and CMMI processes are fairly sparse (at least compared to our internal bug form). If they don’t have fields to track the information you need, you’ll have to customize the forms. Learn how to customize WIT forms here (TFS 2005, TFS 2008, TFS 2010 Beta)

7 Tips to Help Your Data Mining

Of course, there’s a fine balance to aim for between overloading your bug form with tons of fields and having a bug form that’s simple enough as to not discourage people from actually filling out all the fields properly. Here are some tips I’ve learned to help improve your chances of success:

Work with your project stakeholders to decide which engineering processes you want to improve
Prioritize the list
Determine which bug form fields will give you the necessary insight into how those processes are working today
Determine what length of time you’ll need to look for patterns. Don’t assume a few data points means a trend. Consider observing data during different phases of your development cycle (e.g. feature development vs. stabilization) and across phases.
Do regular spot-checks to make sure the data your team is supplying is valid. i.e. – are they taking the time to fill in the fields properly? are they skipping the fields altogether? check in with your team to get their feedback on the bug form.
Don’t make the bug form part of the process problem by overloading it with too many fields.
For critical process questions, mark the associated fields as required on the bug form.
Understand the normal ranges for each of your metrics and drill down to understand anything that varies from the norm. You could find areas where some teams are working much more efficiently than others and find opportunities to spread those practices to other teams. Alternatively, you could also find areas in need of improvement.

Data Mining Examples

Here are some other interesting queries I’ve run recently, the fields I use to gather data, and some follow-up questions I ask for each.

Example 1 – What is the ratio of bugs in automated tests due to product changes vs. bugs due to poorly coded tests?

Fields:

Issue Type (code defect, test defect)
Issue Level 01 (product change, test bug, infrastructure/lab/network issue)

Follow-up Questions:

Why do we have product changes getting checked in that break tests?
Could those changes have been caught before check-in? How?
Did anyone run the tests before the code was checked in?

Example 2 - Do we have high priority bugs that are regressions from previous releases (points to test holes or cowboy check-ins)?

Fields (values):

Priority
Regression (previous milestone, previous release, not a regression)

Follow-up Questions:

Do we have unit tests for those scenarios we should have run before check-in?
Did anyone run the tests?
Why aren’t we fixing these high priority regressions? Is this the right decision?

Example 3 - Who is finding our bugs and how are they finding them?

Fields (values):

Source (feature tester, feature developer, feature test team, feature developer team, customer, etc.)
How Found (exploratory testing, unit test, integration test, dogfooding)

Follow-up Questions:

Who is finding the high priority bugs?
Are testers/developers finding more bugs in functional units/end-to-end scenarios? Why? Is this the “right” mix?

Example 4 – Which bugs were not fixed in feature crews and added to our technical debt?

This one might take a little explaining. We use a parallel development model called “feature crews”. This means small teams work on new features in branches until the features are “complete”, then they merge those changes up with a reverse-integration into a higher level branch. We guide teams to fix all their feature bugs before integrating their work back into the main lines to avoid accumulating technical debt.

Fields (values):

Bug type (product bug, feature bug)
Feature ID (which feature work item was this bug related to?)

Follow-up Questions:

What types of feature bugs are getting turned into “product bugs” / i.e. what technical debt are we accumulating and why?
Is one particular feature team accumulating more technical debt on average than others? Why?
When were those bugs moved to product bugs? Did the team push technical debt out of their feature crew too aggressively?
Which teams can I reward for consistently not contributing to technical debt?

Wrapping Up…

I hope this post helps ignite some conversations around how to identify opportunities for process improvement in your organizations.

Remember, you get what you measure, so measure what you get!

In testing, you have to cross jurisdictions

2009-06-16T20:40:58Z

The other day on the way to work, I was almost side-swiped by a big rig weaving all over I-40. The truck’s erratic driving continued, and after I watched a few more cars quickly veer out of its way, I decided to call 911 to report the truck. Although I described to the triage operator that I was on the Interstate, I was patched through to the police department for the city I was passing through. They politely explained to me that by the time they could get an officer to general area, the truck would be out of their jurisdiction. Worse, when I asked them how to contact the highway patrol, they couldn’t even tell me. Clearly, they had triaged the problem to someone else’s plate and were not interested in the final outcome.

Unfortunately, I see this same type of mentality repeated all the time in software testing. At the end of the day, customers don’t care (and shouldn’t have to care) whether the feature was owned by tester A or B or whether the bug was created by this developer or that developer. At the end of the day, they care whether their software meets their needs or not. Anything else is just noise.

In testing, we have to cross jurisdictions all the time. We can’t conceptual lines of responsibility keep us from doing what’s right for our customers. For example, when we run into bugs outside our team’s feature areas, we must log the defect, follow up with the other team to make sure it’s properly filed, and then keep a watchful eye on it to make sure the right thing happens. I tell my teams to “aim high” and keep a long term view of their work and think about how the customer will use features from an end-to-end perspective rather than just how they’ll use the single feature they’re currently working on.

Sometimes as SDETs, the boundaries we cross include discipline roles. Many testers at Microsoft have worn the PM or developer hat from time to time to varying degrees. Every tester knows that if they can narrow down a bug to a line of code and provide a verified fix along with the defect report, they stand a pretty good chance of getting the bug fixed. Often too, testers find themselves playing customer advocate to PMs or devs because they’re the ones actually using the software rather than just imagining it from a design perspective.

Of course, there are valid reasons to stay within the lines sometimes, but I think the lines aren’t as always as clear as people perceive them. Yes, we have to manage risk, and we have to use our limited resources appropriately. That said, there are also other ways to make sure the right thing happens in the end without going too far outside the lines. For example, in the case of the runaway big rig, the officer I spoke to could have offered to follow up with highway patrol himself, recognizing that he was at a desk and I was in my car on a mobile phone trying to stay out of this driver’s way. Instead, he took the concept of jurisdiction a little too far (in my opinion) and handed the problem back to me to solve. If you do that with software, your customers will simply hand their dollars to someone else.

So next time you think about handing off a bug to another tester or team, ask yourself whether you should maybe run with it a little bit longer to ensure the right thing happens in the end for your customers.

Help! Files in my bin directory are automatically added to source control!

2009-06-02T05:34:49Z

You’re pulling your hair out. Any file saved to the bin directory (even log files and temporary files you generate) end up getting added to source code control. You’re getting more frustrated by the minute, especially when you try to build and some other developer already has binary files checked out exclusively (because you can’t merge them). What’s going on here?! I am reminded of the pain around website projects nearly weekly on Twitter, so I finally decided to blog about it in hopes someone will read this and save themselves a bit of trouble.

My magic 8-ball says, you’re using a website project.

The solution to this problem is to convert your website project into a Web Application Project. I’m sure this “feature” was initially added as a convenience to website builders, but it’s also the cause of frequent confusion and angst from my observations. Web Application Projects were created to solve this and a slew of other issues with website projects.

Here’s an overview of Web Application Projects with links to more documentation for creating them, building them, and deploying them. Hope this helps!

Yet another reason I love Twitter

2009-04-01T01:08:46Z

If you read this blog, you’re probably already following me on Twitter (@JasonBarile), and you probably already know that I really love Twitter. I stumbled upon a new reason for loving it today – real time crowd sourcing of data for a bug triage session. We were discussing some bugs in meeting today when the conversation turned to speculation about whether or a specific feature was “commonly used”. Of course, that’s a subjective measure, so I decided to take a very subjective temperature check via Twitter. Within 5 minutes, I got replies from 5 users who told me they never used the feature.

Granted, this isn’t a scientific approach at all. I’m positive some users have used this particular feature in the past. Some may even depend on it for critical business needs. That said, the fact that everyone who responded said they haven’t used it tells me it’s not critical for a majority of our users, which was exactly the data point we needed at the time.

This was so much more efficient than saying “I’ll get back to you with some data in a couple of weeks”. It helped us come to a quick decision and move on. We’ll probably still follow up on this by talking with some of our customers to validate the decision, but the urgency of doing that is lower now because we already have a good idea of what the responses will be like.

Twitter brings you closer to more customers more faster.

How to Add a Placeholder Account to Your TFS Bug Form For Pre-Triage Bugs

2009-02-21T00:56:59Z

This question came across Twitter recently, and I had to do a little research to answer it. I thought I’d pass along what I found in case others are wondering how to do the same thing.

The scenario – You want to add a “placeholder” account to the available list of options in the AssignedTo field so you can assign bugs that have not yet been triaged to this value. Ideally, you want this to be the default value. When your team members file bugs, they get assigned to this fake user. Then, bugs that have not yet been triaged by the team can easily be searched.

Note, this is not the only way to solve this problem. Other solutions I’ve seen include adding a new state value for bugs called something like “submitted”. Then, when bugs are accepted by the triage team/process, they’re moved into the “active” or “accepted” state. If there is sufficient interest, I’ll blog about how to do that.

Step 1: Export the work item metadata for the work item type you want to modify. See this page for details on how to use witexport.exe. The command I used to export the “Bug” work item type from my team project called “MovieApp” looked like this:

C:\Program Files\...\IDE>witexport.exe /f bug.xml /t http://jasonba-dev10:8080 /p "MovieApp" /n “Bug”

This command connects to the server jasonba-dev10 and exports the metadata for the “Bug” work item type from the Team Project called “MovieApp” to a file called “bug.xml” in the current directory.

Step 2: Next, open the bug.xml file and find the section of the metadata that defines the “Assigned To” field. Assuming you created your team project using the MSF Agile template, it would look something like this:

      <FIELD name="Assigned To" refname="System.AssignedTo" type="String" reportable="dimension">
        <VALIDUSER />
      </FIELD>

The <VALIDUSER /> tag means that any member of the Valid Users group is a valid option for the “Assigned To” field. Unfortunately, this limits you to just those members. So, since we want to add a placeholder user, we’ll need to remove that tag and change a few other things.

Step 3: Remove the <VALIDUSER /> line (just that line only!) and replace it with the following text:

        <DEFAULT from="value" value="Not Yet Assigned" />
        <ALLOWEDVALUES expanditems="true">
          <LISTITEM value="[global]\Team Foundation Valid Users" />
          <LISTITEM value="Not Yet Assigned" />
        </ALLOWEDVALUES>

Let’s walk through what these new lines mean. First, the <DEFAULT…> line specifies that the field should be get to “Not Yet Assigned” by default.

Next, the <ALLOWEDVALUES…> section defines the set of values that appear in the “Assigned To” list. The expanditems=”true” attribute means that if you specify a group in the list of allowed values, any sub-groups that happen to be members of that group should be expanded and their members should also show up as options in the list. The default value for this attribute is true, so it’s really not necessary, but I include it for completeness.

The first <LISTITEM…> line pulls in all members of the global server group called “Team Foundation Valid Users”. Essentially, anyone with access to the server will now show up in the “Assigned To” dropdown list.

Finally, the second <LISTITEM…> line is what defines our fake user named “Not Yet Assigned” (hopefully you don’t have a real team member with that name!). Note that this text must match the text you specified in the <DEFAULT…> tag in order for the default setting feature to work properly.

Note, you can add other similar values here, such as “Closed” for bugs that have been moved into the “Closed” state.

Step 4: – Upload your template changes back to the server with the witimport.exe command. For example:

C:\Program Files\...\IDE>witimport.exe /f bug.xml /t http://jasonba-dev10:8080 /p "MovieApp"

Step 5 – Finally, if your import was successful, refresh your Team Explorer window to pick up the changes. When you create a new bug, you should see the value “Not Yet Assigned” as the default value for the “Assigned To” field.

Make Sure You Reinstall VS 2008 SP1 After Installing Team Explorer

2009-02-10T17:13:40Z

If you installed Team Explorer into Visual Studio after you applied Visual Studio 2008 Service Pack 1, you’ll need to re-apply the service pack. If you don’t, then you’ll be running an unsupported “mixed mode” installation, meaning the core Visual Studio components will be at the SP1 servicing level and TE will be at the RTM servicing level.

Here’s a quick way to determine if your installation is in this state:

1. Click on Help->About Microsoft Visual Studio

2. On the Help screen, click “Copy Info”

3. Paste the text into Notepad (or your favorite editor)

4. Check the version of Visual Studio:

   Microsoft Visual Studio 2008
   Version 9.0.30729.1 SP <—indicates you have SP1 installed on Visual Studio
   Microsoft .NET Framework
   Version 3.5 SP1

5. Now check the version of Team Explorer. If you see this, then you' have SP1 installed on Team Explorer:

Microsoft Visual Studio 2008 Team Explorer
Version 9.0.30729.1

However, if you see this, then you need to re-apply Service Pack 1 to bring Team Explorer up to the right servicing level:

Microsoft Visual Studio 2008 Team Explorer
Version 9.0.21022.8

You can download the service pack installer here.

Check out the new VSTS Community Website on MSDN

2008-12-12T20:32:20Z

We've just launched a new page on MSDN to help give some visibility to the great contributions from the VSTS community. Check it out at http://msdn.microsoft.com/en-us/vsts2008/bb964396.aspx.

TFS Build Tweeter renamed

2008-11-18T16:40:00Z

TFS Build Tweeter has been renamed to TFS Build Monitor to better refelct its purpose. This cool community project can send out alerts for TFS Build events via Twitter or light up a USB powered "build light". Visit the project's page on Codeplex for more information. Thanks to Steve for the tip!

NotAtPDC - A Conference for the Rest of Us

2008-10-28T16:21:57Z

If you're like me, you're sitting at your desk working today instead of attending PDC '08. Luckily, sessions are available from Channel9 24 hours after each event (tags: PDC 2008, PDC08), so you can still get all the scoop. First up for TFS today will be Brian Harry's talk from yesterday, "Team Foundation Server 2010: Cool New Features". Also be sure to watch Stephanie Saad's talk on how we use TFS at Microsoft later this week.

Additionally, several MVPs and other community folks have put together an ad hoc virtual conference, NotAtPDC, for people who couldn't attend the PDC. The presentations will all be given virtually via LiveMeeting, so you can watch them in real time and participate by chatting or asking questions. Find more information at NotAtPDC.com. The event schedule is evolving constantly as word spreads, so check back often for updates. You can also follow developments on Twitter by following @NotAtPDC.

Enjoy!

Twitter Poll Results – How Testers Define Their Jobs

2008-10-06T17:35:01Z

It’s a bit late, but I’m finally posting the results of my recent Twitter poll. This was definitely an experiment. I only received 4 responses for this poll, but it’s a start. For future polls, I’ll allow blog comments as well.

The 4 responses I received were:

“I'm the person who investigates and reports on the state of our applications compared to software developed by other companies”
“At the moment work consists mainly of trying to find business!”
“Develop Software for Testing Software. Nurse Out-Source staff. Design Low Maintenance Test Automation Solutions.”
“System questioner and information provider”

If I missed any replies, I apologize. Please feel free to leave comments to this post with your job description if you’d like. In particular, I’m interested to know if you think your job stops at reporting defects or if you think your role includes actually driving changes you feel are important in the product. When I ask this question in crowds of testers, I tend to get strong responses on both sides of the fence. Which side are you on?

Thanks to PhilK for pointing me to a similar question posted at the Software Testing Club.