This is a Windows client which does not require Visual Studio and target the needs of the tester. Here a tester can set up test manuscripts, run tests and report bugs. What was also really interesting is that while running tests, a tester can choose to record his steps and when filing a bug, he can automatically send a film or pictures of the situation. The recording can then also be used when verifying that a bug is fixed: the macro retakes all steps to the failing step, which makes the validation faster.

What also was interesting is the possibility to set up virtual environments for different test scenarios, for example different cultural settings and configurations. Since a test is run in a specific environment, we can keep better track of the environment in which the tests are run and not run. Also, when filing bugs, a snapshot of the environment at the time of the failure is possible.

Lab Management product  is an integrated solution that brings virtualization to the heart of application lifecycle management space.

• Create libraries of virtualized multi-tier test configurations really quickly
• Automatically deploy new builds of your application to these environments
• Seamless integration of our dev and test capabilities with the virtualized environments
• Take the €œno-more no-repro€  theme to the next level by leveraging snapshots

Lab Management  Architecture

The diagram below shows a high level architecture diagram for Lab Management.

On the server side, Lab Management service is one of the many services running inside Team Foundation Server (TFS). This is what makes the Lab Management solution unique for software testers and developers. Now we can map our lab resources, such as, hosts, virtual machines and storage to Team Project Collections and Team Projects; thus aligning lab hardware needs with the business needs for the projects we are working on.

The lab management service in TFS uses System Center Virtual Machine Manager (SCVMM) for management of lab infrastructure and provisioning of virtual machines across multiple virtualization platforms.

On the client side, the €œMicrosoft Test and Lab Manager€ tool is  the tool to manage  virtualized assets. This is a Windows Presentation Foundation (WPF) based rich client that allows you to define test plans, test suites, test cases and run them in physical or virtual environments.

Basic Concepts

Hardware virtualization is a disruptive technology that is changing the face of computing. Therefore, it is important to understand some of the basic concepts around virtualization and how these are used in Lab Management to understand this paradigm shift.

Virtual Machine

A virtual machine (VM) is a computer within a computer, implemented in software. A VM emulates a complete hardware system, from processor to network card, in a self-contained, isolated software environment, enabling the simultaneous operation of otherwise incompatible operating systems on a single physical computer. Each operating system runs in its own isolated software partition.

Virtual Machine look

A virtual machine snapshot is a file-based snapshot of the state, disk data, and configuration of a VM at a specific point in time. A VM snapshot is similar in functionality to laptop hibernation state with the additional flexibility that a VM supports multiple snapshots. You can roll back the VM to any of the previously taken snapshots and continue operating from there. The picture below shows a snapshot tree for a Hyper-V VM.

Host

A host is a physical

computer that hosts one or more virtual machines.

Host Group

A host group is a custom group of virtual machine hosts, which an administrator can create in SCVMM for ease of monitoring and management. Host groups can be used to allocate and determine the resources reserved for various team projects. For example, an administrator could create a host group named €œGlobal Bank Hosts€ for a team that works on €œGlobal Bank€ project and bind it to the corresponding team project in Team Foundation Admin Console.

Library Share

One of the beauties of virtual machines is that you don’t need to tie up a host if you are not actively using a VM. You can store it on a disk and bring it back to life on a host in a few minutes. SCVMM supports the concept of a library share where you can store virtual machines and other resources, such as, ISO images. The library share is nothing but a file share that is accessible to all the hosts. Similar to host groups, you can create multiple library shares for ease of management. For example, you could have a library share for storing pristine or golden OS images. Another library share could be used for storing VMs that have various application software components installed.

Environment

A typical multi-tier application consists of multiple roles, such as, Database Server, Web Server, Client, etc. Each role could be running on one or more computer. You could also have multiple roles running on a single computer. An environment is a set of roles that are required to run a specific application and the lab machines to be used for each role.

Managing environments for multi-tier applications is an error prone task today. Replicating the same environment at same or another site is even a bigger problem.

Lab Management surfaces environments as a first class entity.

Environment brings with it €˜strong’ group notion. That is when you do an operation on an environment, such as, start, stop, take snapshot, etc., that operation is applied on all the virtual machines that are part of the environment.

In this we are going to discuss some point about project management features and discuss what new for that in TFS 2010.

Team Foundation Server provides project management features such as centralized work item management, process management, security and permissions management, project metrics, and reporting to improve your ability to manage development projects in Visual Studio.

The software-development lifecycle has been made an integral part of the tooling to support software project development efforts. TFS provides the MSF Agile and MSF CMMI process templates, which support two very different development methodologies. We can modify the supplied process templates or create one from scratch in order to meet your team’s development process needs.

MSF for Agile Software Development Process Template

The work item types provided by this process template include:

• Scenario €€œ Used to represent a user interaction with the application system. It records the specific steps necessary to reach a goal. When writing scenarios, be sure to be specific as there may be many possible paths.
• Task €€œ Used to represent a unit of work that needs to be performed. Each role has its own requirements for a task. For example, a developer uses development tasks to assign work.
• Quality of Service Requirement €€œ Used to document the system characteristics such as performance, load, availability, stress, accessibility, and serviceability
• Bug €€œ Used to communicate a potential problem in the system.
• Risk €€œ Used to identify and manage the inherent risks of a project.

Work Item Type: Bug

Work Item Type: Scenario

Work Item Type: Quality of Service Requirement

Work Item Type: Risk

Work Item Type: Task

MSF for CMMI® Process Improvement Process Template

The work item types provided by this process template include:

• Requirement €€œ Used to capture the requirements defined during the requirements gathering phase.
• Change Request €€œ Used to capture any change requests subsequent to the gathering of requirements.
• Issue €€œ Used to capture issues to be tracked in the projects.
• Task €€œ Used to represent a unit of work that needs to be performed. Each role has its own requirements for a task. For example, a developer uses development tasks to assign work.
• Review €€œ Used to represent the review work units with in the projects, like code review, design review etc.
• Bug €€œ Used to communicate a potential problem in the system.
• Risk €€œ Used to identify and manage the inherent risks of a project.

Work Item Type: Bug

Work Item Type: Requirement

Work Item Type: Change Request

Work Item Type: Issue

Work Item Type: Review

Work Item Type: Risk

Work Item Type: Task

New in TFS-2010

Updated MSF Agile Template

Terminology €€œ In general, It had adopted common Agile community terminology (Backlog, User Story, Story Points, etc) and moved away from Microsoftish terminology.

Simplification €€œ It had simplified the work item forms, focusing more on the stuff that is immediately relevant. It had eliminated fields people didn’t care much about.

Scenario €€œ> User Story €€œ It had now moved to the Agile User Story model, including tracking User Story size as €œStory Points€.

Hierarchy €€œ Added hierarchical relationships so that User Stories can be decomposed into tasks and tasks can be decomposed into subtasks.

Improved reports €€œ Reports are much nicer.

Testing support €€œNew Team System testing tools added as first class support. The process template contains a Test Case work item type and other features to enable great integration.

Guidance rewrite

User Story:

Task:

Bug:

Updated MSF CMMI Template

New CMMI information model and the supported relationship types.

In addition to that:

CMMI 1.2 compliance

Two new requirement types €€œ Added Business Objective and Feature to the existing set of requirement types.

Improved reports €€œ The reports much nicer.

Testing support €€œ Added the new Team System testing tools as first class support. The process template contains a Test Case work item type and other features to enable great integration.

New Reports

:

Much more attractive and powerful €€œ Taking a dependency on SQL 2008 allowed to leverage the new reporting capabilities there. The result is reports that are much more visually attractive and can represent much more complex data relationships.

Self explanatory €€œ Lot more content put into the reports to help us understand what the report is intended to tell you, what data you are looking at and generally give much better context for interpreting the report.

New Excel reports €€œ For the first time, some of reports are authored as Excel workbooks. If we use MOSS for our portal, we can host them there, otherwise we can open them in Excel. The primary advantage of this is that although they are a bit less powerful than Reporting Services, they are much easier to customize.

Just to give you a view of all the reports its included, here are some screenshots of Team Explorer:

Project Management Features in Team Foundation Server

• Process management. Team Foundation Server process management includes Microsoft Solution Framework (MSF) process guidance as well as process templates that set up new team projects with work item types, reports, a project SharePoint portal, and source control settings.
• Security and permissions. New projects contain default groups and permissions that map to common development team roles.
• Centralized work item management. Work items including bugs, risks, tasks, scenarios and quality of service (QoS) requirements are centrally recorded, managed, and maintained in the TFS work item database. Centralizing their storage makes it easy for all team members to view and access them.
• Microsoft Office Excel® and Microsoft Office Project integration. By using the Office Excel and Office Project integration features, project managers can continue to access the work item repository and schedule information by using tools they already know.

• Metrics and reporting. TFS provides a reporting service which transforms operational data such as work items, build results, and test results into metrics stored within TFS data warehouse. Predefined reports allow you to query a variety of project health and quality metrics.
• Project portals. For every team project, TFS creates an associated project portal that uses Microsoft Windows SharePoint® Services. You use the portal to manage project-related documentation, and to quickly view key reports and assess project’s current status.

Benefits

The project management features of TFS provide the following benefits:

• Centralized management
• High traceability
• Integrated project planning and scheduling
• Improved process control
• Improved team communication and cohesiveness
• Accurate progress reporting

Strategies for Team Projects

Team Project per Application

This is the most common strategy for creating team projects. This approach is useful for both large and small applications, as well as multiple releases of applications being developed in parallel. With this approach, you create one project for each application under development.

Team Project per Release

This approach is useful for large teams who are working on long-running projects. After every major release, you create a new project and have a clean start. With this approach we don’t have to worry about carrying the previous release’s baggage forward, including work items. Also, this approach provides you with the opportunity either to improve the process templates or use new ones based on your newly acquired experience and learning.

Team Project per Team

This approach is useful for large projects that span multiple teams, where central control and activity monitoring is important. With this approach, we create a project for each team. This approach closely aligns a team with the workflows defined in TFS work item types and provides a unit of reporting that spans the entire team.

Team Foundation Server 2010
In this Post I am going to tell the main architectural difference of TFS 2010 with earlier version .In coming post we will go through key feature that will make the developer job easy with TFS .
Team Project Collections
Team Project Collections are a new concept in TFS 2010. They represent a set of projects that are managed together. Each TPC has it’s own set of databases. This enables TPC’s to be backed up, restored or migrated independently of other TPC’s on the same logical or physical TFS implementation.
This is particularly exciting for large TFS implementations. The ability to segment the environment into units based on organization units, clients, product team, etc. is compelling. Also, individual TPC’s can be backed up and archived. In a consulting organization this is huge improvement.

Archive/restore individual project collections €€œ In previous versions, the entire TFS server had to be backed up/restored so if you wanted to recover a specific project from a backed up state, you had to restore the entire server. In TFS 2010, you can separately backup and restore individual Team Project Collections.
Move Team Project Collections €€œ Team Project Collections can be moved between SQL Servers within a TFS farm, between TFS farms in the same network and between TFS farms on different networks (which will be a bit harder than the first two because of no identity continuity between networks).
Server consolidation €€œ In TFS 2010, multiple TFS servers can be merged together into a single TFS farm (a request we are increasingly seeing as organizations want to fold grass roots TFS adoption into a centralized service).
Team Project Collection Split €€œ A Team Project Collection can be split into separate collections each containing a subset of the Team Projects. The primary scenario in which I expect to see this used is migrating from TFS 2005/2008 to TFS 2010. Because you could, essentially, only have 1 Team Project Collection in previous versions of TFS, many customers have accrued 10’s or 100’s of projects on a single server. TFS 2010 will allow them to be broken up.
Team Project Collection Isolation €€œ Each Team Project Collection is a separate administrative entity. This means that you can reasonably do shared hosting of collections with appropriate separation of administration and operations responsibilities and without hosted teams needing to know about each other.

TPC’s can be scaled across a number of SQL Servers as each is now independent database.
These structural changes make TFS much more manageable and vaults TFS into the large enterprise space.
In TFS 2010 this had been sloved by Team Project Collections (TPCs). In TFS 2010 a TFS farm hosts Team Project Collections and not just Team Projects. A Team Project Collection is a group of related Team Projects and a TFS farm can host many Team Project Collections. To try to make an analogy with TFS 2008, it’s as if TFS 2008 could host exactly 1 Team Project Collection per physical TFS server. The key is that Team Project Collections are completely independent of each other. Two Team Project Collections can each have a change set with the same changeset number (but very different contents). They can each have work items with the same work item ID. You used to identify things in TFS by server url + ID. Now you identify them by server url + team project collection + ID.
When you connect to a TFS server in TFS 2008, you get a screen that looks like this. As you can see €€œ you pick the server and then one or more Team Projects to work on.

However, in TFS 2010, the Connect to TFS dialog looks like this:

As you can see on the left hand side, there is now a list of Team Project Collections (currently labeled €œDirectory€) and on the right hand side, you can see a familiar looking list of Team Projects within the selected Collection. The client will only allow you to connect to projects in one TPC at a time.
It is very similar to Sharepoint architecture
Database Changes
As TFS 2010 has Team Project Collections has So it changes TFS databases.
TFS 2008 was composed to databases partitioned by subsystem. There was one for Version Control, one for Work Item Tracking, Work Item Tracking attachments, Project Management, Build, Integration, €¦
Now with the introduction of Team Project Collections, there was changes to various subsystem data to make Team Project Collections easier to manage. TFS 2010 database architecture is as follows:
TFS_Config €€œ The €œroot€ database that contains centralized TFS configuration data, including the list of all Team Project Collections that this TFS farm is responsible for.If you go through Sharepoint terminology its WSS_Config.
TFS_Warehouse €€œ The TFS 2010 data warehouse database that contains reporting data from all Team Project Collections served by this Farm. This means that the data warehouse provides reporting capabilities across all Team Project Collections in the farm.
TFS_* €€œ One database for each Team Project Collection managed by the TFS farm. For example the €œdefault€ one would be TFS_DefaultCollection. Each database contains all of the operational data regardless of sub system (version control, work item tracking, build, etc) for a given Team Project Collection.
IMP:- There are still databases for Sharepoint and Report Server where ever you install those components.
TFS Farms
The introduction of the notion of a TFS farm is another big architectural change in TFS 2010. In TFS 2008, we talked about TFS €œServers€. Even then it was a bit of a misnomer since you can install all TFS 2008 capabilities (TFS, SQL, Sharepoint, Reporting Services, €¦) on a single physical (or virtual) server or distribute them across multiple.
However, it gets even more flexible with TFS 2010 and as such, it’s now really awkward to talk about a TFS €œserver€. That said, it is still possible (and will likely be common) to install all of the TFS components on a single server.
The big changes that constitute €œTFS farms€ are the following:
NLB support for TFS application tiers €€œ With TFS 2010, you can configure multiple TFS application tier machines to serve the same set of Team Project Collections. The primary purpose of NLB support is to enable a cleaner and more complete high availability story than in TFS 2008. Any application tier in the farm can fail and the farm will automatically continue to work with hardly any indication to end users of a problem. It also improves things like the operating system patching story (ATs in the farm can individually be taken offline for patching with out shutting users out of the system). And more.
Scale out for SQL data tiers €€œ TFS 2010 now support use of as many SQL Servers as you like. Each data base can be configured to be on any SQL server and because each TPC is an independent database, this gives administrators a great deal of flexibility to manage their SQL server installations. These features can be used to load balance databases across SQL Servers, manage capacity, retire old SQL servers, etc. A project collection can easily be suspended while it is moved between SQL servers without affecting the operation of any other collections.

This is important architectural difference we had.This post is inspired by bharry’s post one of founder of TFS 2010.The topic is huge I will continue to discuss on this and also some of concept like

1. Protect the quality of your code.
2. Understand parallel development
3. Manage your project
4. Report on your entire portfolio
5. Coordinate across development platforms
6. Admininster TFs in your environment

in the coming Post.