Eating more dogfood...
Our QA team has recently committed to converting all of our automated tests to VSTT-style tests. You might be shocked to learn they're not already all implemented with VSTT, but please remember that we were all building our pieces of Team System at the same time in v1. We have a lot of test automation that was written before VSTT was ready to use. Many of those tests are still running daily today and providing lots value in spotting regressions & proving the basics "just work".
So if we have all this automation that already works & provides value, then why are we considering porting it?
I can offer multiple reasons:
1. We love dogfooding our own products. What better way to find bugs in a product than to live with it every day? Besides, it helps our team members learn more about other parts of the Team System suite of tools when they'd be otherwise heads-down in TFS feature work all day long. The key to Team System is "Team"; if we're not helping each other succeed, why bother?
2. Our old tests have certain dependencies that makes it difficult to run them outside our test lab. Long story, don't ask... bottom line is that porting to VSTT is making it much easier for our developers to run our tests before checkins, for us to gather on-the-fly code coverage data as we automate our tests, etc.
3. Better integration with TFS, especially for reporting. While our legacy tests generate log files indicating their results, they don't report these results to our internal TFS warehouse. Currently, I can only get a partial picture of our product quality through TFS without building custom adapters to pump data into the data warehouse. Completing our port will make it much easier for us to dogfood even more of TFS's reporting features for our day-to-day operations.
and most of all...
4. It's a great product!
This effort is part of a larger venture we've undertaken to reduce overall test maintenance costs and decrease our test pass execution time. I'll share a bit more about that in future posts.