TFS can be configured to fine degree to specify how much data is captured whilst the tester is executing manual tests (event log, intellitrace, system information, test impact, video recorder, etc. can be turned on and off, and various settings tweaked for each of them). This could be very useful in avoiding massive bloat. Worth noting is that if you're not careful you'll capture all activity in all applications - not just the application being tested.
I'm so looking forward to Intellitrace - the ability to wind forwards and back through the code whilst debugging is going to change everything. TFS also allows you to enable this whilst the testers are testing, so the developers can replay the code execution later.
(When using Intellitrace, it's important to access websites by machine name, rather than localhost, otherwise the recording won't work correctly.)
TFS has a new feature called Test Impact Analysis. This records which lines of code are executed by each test case. This means that when you start testing against a new build, it will highlight which tests should be rerun. If you change something that isn't managed code (such as html), you can manually record which tests this impacts.
You can specify configuration information for manual tests - for example you can list the browsers that the test should be run against. The tester will see this as multiple tests - one for each configuration.
TFS has hierarchical work items - you can break tests down into test cases, and link the tests to work items that are user stories, for example.
You can specify test steps for a test case: you can be as granular as you like with this (either "create an account" or "click on account, click register, type your name", etc.). Granular steps are a pain to write, but mean you can track more accurately where the test fails.
You can put parameters in the test steps by prefixing with an @ (e.g. "type @FullName"). You can then specify lists of values for these parameters that will then appear as multiple iterations of the same test. The test script tool that the tester will send these values to the application being tested with a single button click, avoiding typos.
Test steps can be marked as verification steps. You can specify the expected result, and this will oblige the tester to mark whether this step succeeded or failed.
When running tests, the tester has the option to record their actions. These can be played back later (in whole or in part) to speed things up when they redo the test later. This works across different iterations of the same test.
These action recordings can then be converted into Coded UI Tests. The code it generates is nice and clean - each granular step becomes a separate method in the generated code. It's impressive stuff - if a step involves clicking a link on a webpage, and you later change that link's id, the test will still try pretty hard to find the right link, by name or by inner text, etc.
The Coded UI Tests can (and in most cases should) be tweaked by the developer to add assertions that match the verification steps in the original manual test. There's a tool that allows you to pick DOM elements directly from the browser, and add assertions as to what properties those elements should have in order for your test to pass.
When specifying build processes in TFS, you can have it deploy your application onto a virtual environment of a number of virtual machines in a virtual environment - one VM to host the application and another to host the database, for example. All automated tests (including the the Coded UI Tests) can then be run automatically against these. As the Coded UI Tests actually open a browser to run them, these can also be run on VMs in the virtual environment, testing various browsers on various OSes.
Damn, this is good!
The Web Platform Installer is a smart new tool that makes it very easy to get a web server up and running very quickly. It can install anything you choose from a massive range of products: all you need from Microsoft (.NET, IIS, etc.), plus a whole bunch of third party items (DasBlog, DotNetNuke, Wordpress, etc.). It can be used again later to fetch new tools and add-ons.
Server Core is a cut-down version of Windows that has a minimal GUI (just a command line interface) - almost all configuration has to be done remotely. (You have to explicitly turn on remote configuration for IIS though, as you'd expect.) .NET is now available on this platform. They've removed some components (WPF, of course) to keep the overall size of Server Core minimal, but ASP.NET is there.
IIS 7.5 supports secure FTP! At last!
IIS has a URL rewriter that can transform nice-looking URLs (example.com/user/foo) to the ones your application requires (example.com/user.aspx?username=foo). This gives you a nice way to smarten up the URLs of an existing application without having to change the source code of the application. The tool to set this up is pretty cute: you only have to give an example URL and it will figure out the regex to use to create the transformation.
Now that more devices that access websites are using H.264/AAC encoding, it's good to see that Silverlight now supports this too, though DRM isn't currently supported (which is either a good or a bad thing, depending who you are.).
GPU acceleration is supported now (though you have to opt-in for your application: it's not turned on by default). This doesn't include 3D support just yet, though it should be out in a later version. The setting EnableCacheVisualisation will highlight the parts of your Silverlight app that will benefit from GPU acceleration.
However, you can simulate 3D using Silverlight's perspective 3D function. This uses plane projection transforms to give the 3D effect.
On animation, they've built in a bunch of easing functions - the ones available will look very familiar if you use jQuery's easing plug-in.
Pixel shaders can add effects to the visual display. There are two out-of-the-box ones: a drop shadow and a blur. You can write your own if you're not afraid of HLSL. As an easier alternative, you can use the ones made for WPF, available at wpffx.codeplex.com. Only one effect can be applied at a time, so if you want a drop shadow and a blur, you have to fudge it by containing your control in a canvas, then applying one effect to the canvas and one to the control itself.
You can take a snapshot of Silverlight controls as bitmaps. This can be handy to show reflection effects, a ghosted item whilst dragging and dropping, or for more reliable printing.
Silverlight now has a messaging system that allows multiple instances of Silverlight to communicate with one another. They don't have to be in the same browser window, nor even the same browser: an instance of IE can communicate with an instance of Firefox.
Windows Azure is great at supporting massively scalable applications, but there are a number of concerns that will need to be addressed for most such line-of-business applications.
The first is Multi-Tenancy. If your application is to branded by multiple companies, it's important that tenant A cannot access tenant B's data. If you're using Azure tables for your data storage, you can easily create a new table for each tenant. Access to these are very fast, and having separate tables ensures each tenant's data is held entirely separately.
If you're using SQL Azure you could create a new database for each tenant. Though this would be a maintenance nightmare for the DBA in traditional computing, Azure takes away this overhead: creating a new database is quick and hassle-free.
Another issue is customisation and extensibility: each customer might want to skin the UI according to their brand; they may also need to alter the business logic within their slice of the application. This lends itself well to Azure tables: as the table can hold entirely heterogeneous data, adding additional properties to rows is no problem. The developer only has to remember to handle to case where the value is missing on older records.
Microsoft have made extensive use of their own tools to develop their software, so they've learnt a lot along the way.
One interesting point they raised was that by deferring fixing bugs, they never got round to it. Though it's more fun to be developing new code, the bugs mount up like the debt you don't want to think of. They found a much better way was always to fix all known bugs before moving on to the next implementation task. (A nice new feature of TFS is that you can set it up so that it will reject a check-in that doesn't compile or pass all unit tests.)
Obviously Microsoft is a far bigger company than we are, so the scale of their development doesn't compare that well with us. However, it was interesting to note that they prefer to form Feature Crews: a team of no more than five developers and five testers, dedicated to producing a single feature over 6-10 weeks. This size compares well with the sort of development team that we find works as well.
They've dropped their policy of 70% code coverage for unit tests, as they found that having too many led them to spending too much time maintaining unit tests and not enough time developing features. Instead, they try to target the most common usage path of the application. Interesting: we're currently wrestling with the balance of test coverage versus maintenance overhead.