Share your TestComplete knowledge!

Wow... let's see...

I started using the tool before it was called TestComplete. AQTest, I believe, was the tool name back in the day, put out by some weird little company called AutomatedQA Corp. :)

I cut my teeth on the tool doing a modified capture/playback test suite, taking the automated macros that we had implemented in house and converting them into DelphiScript procedural scripts. One of the things I discovered while doing this is that automated tests are VERY sensitive when it comes to timing, position, etc., and I was finding myself rather frequently having to do heavy maintenance on these test routines.

Sometime later, after TestComplete became TestComplete (I think around version 2 of the tool), myself and another team-mate started working on the concept of having a set of tests where we would "drive" the tests with one data file and have another data file (or set of data files) that would contain the details for each test. This table driven framework relied very heavily on the DDT objects for CSV files for reading through CSV files that contained all the necessary data for our tests.  This reduced, IMMENSELY the amount of maintenance we needed to do on our tests because, rather than having to fix the same thing in hundreds of different places, we only needed to correct a single code routine and it would be fixed for all others. Also, this framework allowed for an easier expansion of our code coverage because all we would need to do in order to add more tests is create a new test type and then add records to our various CSV files to execute that new test type via the driver file and reference the details elsewhere.  We implemented this framework first with a group sales order entry product for testing a number of test cases and then we generalized and expanded it even further for a number of other scenarios in the larger product suite.

But I wasn't done yet. I moved on to a different position at another company and had some time to do some further development. I was not satisfied with the driver and the data tables.  They were too cumbersome because we ended up with literally dozens of different secondary data tables and so, while we corrected our problem of code maintenance, now we had a nightmare of multiple data tables that, in order to add a new test case, we needed to add records in minimal 3 files but, on average, 6 or 7. So, I took some time and changed my code base to JScript, started working with some more OOP code and created a whole framework.  The general concept was the same in that I had a driver file as the initial file that indicated the different tests to execute. However, the details for each test case were reduced to a single CSV file of test details and I started making the specific code more generalized. Steps like "Open web browser" and "Click button" replaced the more specific routines. The idea was to separate even further the data from the code so that the code was as application agnostic as I could make it. 

Honestly, if anyone is curious as to this framework, I have it available on bitbucket at https://bitbucket.org/tristaanogre/tabledrivenframework. I've licensed it under a CC BY-SA 4.0 license so feel free to use it if you want. Unfortunately, I haven't had time to do the documentation I want to on it.

So, nowadays, the company I recently left and the ones I'm looking at for new employment don't advertise TestComplete as a necessary skill. However, I've found that these same concepts are being utilized in a number of testing tools. I attribute TestComplete and SmartBear as giving me the tools I need to be able to implement these complex concepts.