Today, I was working with a customer that was have a performance problem with Microsoft Test Manager. Upon investigation, we found out that the customer had a large number of builds (many thousands in this case), but hadn’t scoped their test plan to a specific build definition. Because of the way the Test->Run Tests view is implemented to support the ‘Run with Options’ experience we load all the builds as filtered by the test plan. If there’s no build definition associated with the plan, we load all builds.
The end result is that with many thousands of builds, merely opening the Test->Run Tests view cause all this information to be transferred from the server. We intend to address this issue in a future release, and are investigating ways we can improve the experience if when there are many thousands of builds in a single build definition.
There are two workarounds today:
a) Remove your old builds. Buck has a post here from 2008 about using drop management to auto-expire builds.
b) Set a Build Definition on your test plan. This will filter the builds we ask for, and reduce the amount of data involved.