I've been a satisfied user of TestComplete since 2002 (up to the recent takeover, at any rate).
Lately, I've also branched out into writing web application unit and performance tests in Visual Studio
If you're looking for advice about how to capture certain components in your application or you want to know how to use a particular feature of some test tool, please google somewhere else.
What I want to talk about is automating the process of testing. Not just capture-replay but test set-up, measurement, reporting and the other things.
Having said that, I'm not an unreasonable man and there are a few things that I have learnt about TestComplete and VisualStudio that I am willing to pass on.
It should be noted that I started out with TC2 using DelphiScript as it had the best feature-set. A few years ago I began to dabble in VBscript, to make it easier for new members of the team.
Now I am trying to maintain an all-Javascript lifestyle, so I develop scripts in C#/C#script/JScript/Javascript (which I will just refer to as JS). I make no apologies for not translating my older scripts - I simply cannot be bothered
Using an automation tool like TC or VS isn't just limited to capture-replay and data-driven tweaking of the subsequent scripts.
When you ask yourself why you are testing, it's to help the team make decisions. The decisions may be about design, resourcing or release dates but they all depend on the information you can provide as a result of your testing.
Accepting this role, you soon find yourself spending more time shuffling facts and figures than breaking software. That's where automation steps in again to help you:
The data your tests have generated
Think carefully about what you can glean about the AUT from your tests, not just individual bugs, but trends that can emerge over time or by concentrating on certain areas of functionality
By maintaining a database of test conditions and test results, you can cross-reference the data to check:
To perform this sort of analysis, you need to understand joins and sub-queries in SQL. This is beyond the scope of this article, MSDN is a good source.
In addition, you may not be able to glean all the information you need to classify the AUT from the specs, but you can also use automated scripts to parse information out of the AUT itself. Regular expressions may come into play here, so it's well worth your while becoming familiar with those.
If you're keeping all your test results in source control (and you should), you may want to automate the process of maintaining them.
This is especially relevant if a major change to the AUT requires mass updates to the master results.