Last week I started to tell you about some of the functionality we are building for Visual Studio Team System 2010.  I wanted to elaborate on that some here

I mentioned that only 20% of the code in most business applications is “new” code.  That makes tracking down bugs in the majority of the application code even more difficult to do.  From the design of the application through to the actual writing of the code, one of the most difficult problems has always been that of the bug that can’t be reproduced – the “no repro” bug. There are a lot of factors that drive these types of bugs and we are working to create tools to isolate the issue and allow faster fixes. One way we will do this is through a tool that can specify the exact state of the build used by a tester (what has been checked in, what has changed in source) and allow a comparison to the state of the build used by the developer when trying to reproduce the bug. It is often the subtle differences between these two that create the no repro state, and a new tool within VSTS 2010 has been designed to specifically address this.

One of the other common blockers to reproducing a bug is the collection of actionable data on the bug. By providing a set of tools designed specifically for testers, we are enabling better documentation of test scenarios as well as more thorough collection of data when a scenario fails. This includes the collection of system data, as well as stack trace information, screen images and even fully indexed video capture of the testers’ screen attached to the bug.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

As developers make changes to the code, it is critical for them to effectively test their changes, not only to prove their code changes work as expected, but also to ensure there is no unexpected downstream effect. By providing developers with a test impact analysis, they can run all the necessary tests to validate the code changes helping developers quickly check-in code with confidence by running only the necessary tests, and reducing the churn created by unexpected breaking failures.

 

 

 

 

 

 

 

 

 

 

 

 

 

Of course, the applications cannot be successful if they are not carefully managed from the initial business problem, through to the code being built, and finally to deployment. Fortunately, we have a powerful collaboration hub at the core of VSTS: Team Foundation Server (TFS). TFS enables all of the roles in the lifecycle to work together on shared requirements, shared code assets, and a powerful build management system.

Customers tell us that one of their biggest challenges is the management of the overall build process and the ability to allow developers and testers to check-in code on a continuous basis. I am happy to report that among the new TFS features in VSTS 2010 are improvements to the source code management system with gated check-in, cross branch history and branch/merge visualization, and distributed build workflow.  These improvements provide the same level of visual capabilities for source code and build management as we provide for architectural design.

More on the rest of the family of products later.

Namaste!