Forum Discussion

DanaRogo's avatar
DanaRogo
Icon for Alumni rankAlumni
9 years ago

Share your TestComplete knowledge!

Are you a TestComplete expert?  Have you been using the tool for years and lead a team internally at your organization on the tool?  Please share with us your experience!  

 

We would love to hear from TestComplete users in the community that would like to be a potential future guest trainer alongside SmartBear engineers and Product Owner.

 

In addition any future topics you would like us to cover in Q4's 201 & 301 TestComplete SmartBear Academy sessions share your comments here.

 

Our next monthly 101 TestComplete Training will be on August 23rd  - Register here https://attendee.gotowebinar.com/register/5074663252858221825

 

Thanks!!

4 Replies

  • cshukusky's avatar
    cshukusky
    Contributor
    9 years ago

    I have been using TestComplete for about 5 years now.  I currently lead a team of 3 other full time employees and 1 to 4 interns (depending on the time of year).

     

    My team and I attended Q3's 201 and 301 courses.  We did not attend the 101 course as it didn't appear to cover anything we didn't already know and we work solely with scripts, but 101 was focused on keyword testing.

     

    While we were already familiar with the bulk of the content of the 201 course, we did pick up a few useful tidbits here and there.  Overall, I thought it was a good topic, it was well organized, and well taught.

     

    The 301 course, I was less pleased with.  I had high hopes that, similar to the 201 course, even if we were already familiar with a bulk of the content, there would be some new useful information scattered in there, but unfortunately I did not find that to be the case.  The first part of the course I felt was below the level I would expect of a course with 301 in its name.  The first 20 minutes or more were wasted recording scripts and talking about dividing code into smaller routines.  I would consider that 101 level stuff, or if you want to consider keyword testing 101, then 201 at the highest.  

     

    Once the 301 course got into the content of actually creating a framework, it got better, but I think that is where the course should have started.  One note of confusion we initially had, was when defining the add, edit, and delete steps in excel was referred to as keyword testing.  Since TestComplete already has keyword tests, a different nomenclature would have been preferred to avoid confusion.

     

    Overall, the 301 course felt more disorganized, and less coherent than the 201 course.

     

    As for future topics, the most common questions I get from my team regard 1 of 2 things.  The first being how to consistently identify an object under test (Namemapping, Aliases, FindChild, etc), which I think the 201 course in Q3 covered pretty well.  The second his timing: What methods are available to wait for something to occur or an object to appear. Ex: WaitProperty, WaitAliasChild, etc.  I think an in depth course on different ways to wait for your tested application to be in a desired state before moving on would be helpful for most people.

    • DanaRogo's avatar
      DanaRogo
      Icon for Alumni rankAlumni
      9 years ago

      Hi cshukusky thanks so much for your detailed response!  We appreciate the feedback as we begin to grow and build our free training and resources to our valued TestComplete users.  

       

      I have added your requests to our future topic list to be reviewed with the Product Team :  

      1. How to consistently identify an object under test (Namemapping, Aliases, FindChild, etc)

      2. Timing - What methods are available to wait for something to occur or an object to appear. Ex: WaitProperty, WaitAliasChild, etc.

      3. Different ways to wait for your tested application to be in a desired state.

       

      Thanks again as always anything you need please reach out to us as we continue to fine tune our new customer training process and offerings.

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        9 years ago

        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.