Forum Discussion

Vault76er's avatar
Vault76er
Occasional Contributor
2 months ago

Tuning Testcomplete

Hi, We have a vendor creating automation of our .net based desktop application for us. I am having trouble getting the same results when I run their automation here, as when they run it there. I'm h...
Hassan_Ballan's avatar
Hassan_Ballan
Contributor
2 months ago

Hello,

This documentation page https://support.smartbear.com/testcomplete/docs/working-with/best-practices/index.html touches on the subject. TestComplete by default is fine tuned and works beautifully as is, and as there is no easy answer to your dilemma. I hope the following would help you formulate a course of action. 

You have a lot of variables and nothing you mentioned is specific, computer specs and OS image build as well as network are also something to consider for isolation. Not that they are the reason.

That being said, a large part of automation, as in your situation, is for the developer to run the code in the pipeline on CI/CD machine. It would be the developer responsibility to stabilize the run on the CI/CD machine by debugging each failure one at a time. The fact that the code runs on a developer machine is never an indication that it will run equally on another machine, and hardly accomplished on first try.

TestComplete does a beautiful job in waiting and in logging information to help the debug process, every step has log details as well as screenshot, and what is more important is to trace previous steps leading to the error itself to analyze and understand what prompted such condition. For example: click button did not actually materialize and application is no longer on the correct screen to properly continue or the button is in the background a popup.

Stabilizing a project is sometimes the hardest thing to do, especially when you run the entire test suite that goes for long hours. Back-end servers and network traffic may get bugged down, machine CPU and memory may get overwhelmed, antivirus scan or windows scheduled optimization kicks in, and all that can cause for example a) race condition where automation is running faster than the application responding or b) trying to click on a moving target. 

Debug is an art, and lots of effort goes into automation debug and stabilizing, automation must go as fast as it can and wait as long as is needed. Proper access to objects dictates checking in sequence:

  1. Object exist
  2. Object is enabled
  3. Object is visible on screen not just visible