Identify the Test Impact in VSTS 2010

As developers make changes to code, it’s critical for them to effectively test their changes – not only to prove the new code work, but to ensure there’s no unexpected downstream effect. Test impact analysis and test prioritization identify the tests that must be run to validate the code changes. This helps developers quickly check-in code with confidence by running only the necessary tests and reduces churn created by unexpected failures.
The new Test Impact View window enables a developer to view a list of tests that need to be run as the result of a code change. The developer can toggle between an Impacted Tests view and a Code Changes view.
• The Impacted Tests view provides a list of tests that need to be
run and which code changes are covered by each of the tests.
• The Code Changes view provides a list of code changes and which tests must be run in order to validate each of them.

These two views provide a easy way to discover what tests must be run in order to validate the changes to the code base without having to run all of the tests. This ensures that all changes are tested effectively.

Eliminating “No-Repro” Bugs in VSTS 2010

From designing an application through developing code, finding bugs that can’t be reproduced is a common problem – the “no-repro” bug. Many factors drive these types of bugs, and we’ve worked to create tools to help isolate the issue and enable faster fixes.
One way this is solved in Visual Studio Team System 2010 is with the use of a tool that can specify the exact state of the build used by a tester 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 Visual Studio Team System 2010 has been designed to specifically address this.
This tool – the Microsoft Test Runner – is a standalone tool that a tester uses to guide them through a series of steps to complete a test case. When the test case is started the Microsoft Test Runner takes a snapshot of the system data, including OS version and Service Pack and other pertinent system data. As the test is being run the tester can use the tool to capture images of the application under test, or even partial or full screen video of the test being run. If an issue is discovered, the tester can create a new bug in Team Foundation Server and attach these artifacts. When attached, the screen capture video is fully indexed with the test steps as bookmarks, making it easier for the developer to see what went wrong on the tester’s machine. All of these artifacts help to eliminate the no-repro scenario, and help build a better bridge between development and test.

Product Overview of VSTS 2010

The marketplace has begun to mature and accept Application Lifecycle Management (ALM) as a proven discipline for creating high-quality applications. However, existing solutions in the marketplace have not kept pace with the changing needs of technical users and the expanding inclusion of non-technical users as part of the lifecycle.
Every customer today faces a similar set of business problems:
• How do we build high quality applications that deliver
real business value?
• How do we embrace the Application Lifecycle Management model effectively?
• How can we ensure that all members of the team – both
technical and non-technical – are part of the process?
• How can we get the most value from our existing code assets?
• How do we make powerful modeling tools available to
everyone in the application lifecycle?
The third generation of Visual Studio Team System – Visual Studio Team System 2010 – will be a robust and streamlined solution that addresses these needs and concerns.
We are evolving Application Lifecycle Management by:
Building quality into the lifecycle
• Ensuring architectural consistency through the lifecycle
• Eliminating “No-Repro” bugs
• Ensuring smooth build handoffs and high quality builds
• Incorporating performance in the lifecycle
Driving efficiency into the test effort
• QA Team aligned with Business Analysts,
Architects, and Developers
• Eliminating tedious tasks
• Improving setup and deployment of tests
• Choosing the right tests
Ensuring Complete Testing
• Focused test planning and progress tracking
• Transparently see the quality of requirements and level of testing
• Finding the gaps in testing and fill them
• Ensuring changes are properly tested

Microsoft Web Application Stress Tool 1.1

------------------------
Installation Notes
------------------------

Microsoft Web Application Stress Tool requires Microsoft
Windows NT version 4.0 Service Pack 4 or above and Microsoft
Internet Explorer version 4.0 or above.

------------------------
Online Support
------------------------
To check for the latest news and updates regarding this tool
you can go to the web site http://webtool.rte.microsoft.com.
This web site contains a knowledge base that provides
in-depth answers to performance testing questions and
additional information on the most frequently asked
questions.

------------------------
Known Issues
------------------------
Web Application Stress Tool only supports stress against one
server or DNS name at a time.
To use authentication, you must add users with valid user
names and passwords.
To record, you will need to modify your browser settings if
using a browser other than, or prior to, IE 5.0. See online
help for more information.
Webtool respects the "user-agent: stress-agent" directive in
the ROBOTS.TXT file on a web server and will not start a
stress test against a server or domain that contains this
file with this directive. This file should be located in
the root directory of your web site

In general, you should NOT install the WebTool service on
the web server you are testing since this may interfere with
your results.

The Web Application Stress Tool object model can be used to
start, stop, and configure a test run.  However, this feature
cannot be used to modify a running test in this version of
the tool.

Web Application Stress Tool is year 2000 compliant.

IMPORTANT: Start your test with a small number of
Concurrent Connections and then work your way up to the
desired stress level slowly, watching the processor
utilization on the clients and web server. If the
processor utilization is consistently above 90% on one or
more machines, the test is probably invalid. If this
occurs, decrease the number of concurrent connections or
add more client machines to handle the desired stress load.

On-line help contains a discussion of performance testing
techniques.

Although there is no hard limit on the number of script
items you can have in one script, the most practical limit
is 3000 script items. Beyond that you will find that it
takes an inordinately long time to start and stop tests.