Visual Studio's web and load testing features are really targeted at developers rather than testers. We had a demo from a Microsoft expert and he confirmed this when I asked.
For some uses it is easy and straightforward (e.g. if you can test with just a list of URLs, or if your web site happens to be testable with a record-and-playback method), but if you have a more complex web app with:
- user authentication
- a lot of client-side processing (your test may have to mimic some of this)
- frames or multiple asynchronous requests per page
- old-style ASP partial page updates (heaven forbid)
then you are in for a world of hurt.
The builtin extraction and validation capabilities are quite weak, and there is basic rather than rich support for dynamic tests (i.e. deciding at runtime what to do). There simply isn't support out-of-the-box for a lot of things you'll encounter, or want to do within your test. It also doesn't help that they are really picky and stingy with what bugs they choose to fix. Even if a bug is glaringly obvious, if it's not a crash there seems little point in reporting it.
All that being said, if you have programming skills and solid understanding of http, html, javascript and whatever other particular web technologies your web app uses, you can do some pretty cool things, because the testing framework is super-extensible and wide-open to whatever C# wizardry you can conceive. But sometimes it really feels like you're finishing someone else's job on a product you already paid for.
The problem with missing "hidden fields" appears to be the single most common problem all over the web, and in many cases there isn't a simple fix. When you do a test recording, Visual Studio records all the hidden fields that were present in the page. Well, when you run the resulting test, there are all kinds of reasons why one of those hidden fields might no longer be in the page. Maybe the recording missed an ajax request; maybe the page does something with javascript (whereas VS does not run javascript); maybe there are subtle variations in the page content based on a different user account, or previous actions, or the time of day or perhaps other factors outside your control. If your website or app is very static, it is more easily testable. But if it is very dynamic then you may face a stiff challenge.
To summarize my experience: after taking advantage of three great third-party libraries and then writing my own support library consisting of 95 classes and some 2700 lines of code (including very rich and powerful extraction and validation rules), I have covered most of the major difficulties that I have previously stumbled over
But I pity the poor lone tester who is given VS and told to "write some load tests".
