Prevent TestExecute dialog to Confirm Save in silent mode
When a particular project is run via silent mode, if the tests completes successfully or if it fails, Test Execute in both UI mode and silent mode will ask to save changes. In the silent log the below entry is shown ". 05/03/2026 07:16:40:411 Tried to open the Save dialog. The default value: YES. When all test Pass, still the Jenkins job is s Fails as TE returns an exit code of -1/ This is only the case for a specific project, other projects don't have this issue.
Playback - On Error: Stop and Rerun Current Items Not Working.
Hello, can someone help me why Stop and Rerun Current Items on Errors is not working as before. When an error occurs, it is now continuing to run the whole test and then rerunning it, instead of stopping and then rerunning it. This is causing the execution to run very long and its very inconvenient. I have checked that my execution plan is using "Use project's On Error property" and that my project setting is set to "Stop and Rerun Current Items" when an error occurs. I have reinstalled test complete and it's still the same, how can I fix this?
Stop Skimming PDFs, Start Automating PDF Testing
On the surface, PDFs look simple, but testing them is a whole different story. Invoices, contracts, statements, compliance reports… they’re often the last thing that lands in a customer’s hands. That also means even the smallest issue, like a missing field or a misplaced decimal, can turn into something big. The challenge is that PDFs aren’t like web pages or apps where you can easily inspect elements. They’re containers packed with content, layout, images, and data from different systems. When you add in dynamic content that changes for every customer, formatting that has to stay perfect, and the regulatory risks in industries like finance or healthcare, you start to see why manual testing just doesn’t cut it. It’s slow, inconsistent, and doesn’t scale. This is where automation becomes essential. With automation, you can make sure data is always accurate, layouts stay consistent, and testing scales across thousands of documents without slowing down your team. Instead of spending hours opening PDFs by hand, QA can focus on higher-value work while still knowing that every report or statement going out the door is right. That’s exactly where TestComplete comes in. It’s built to handle the tough parts of PDF testing so you don’t have to. You can validate content down to the last character, run visual checks to keep layouts consistent, and plug it all straight into your CI/CD pipeline. The result is faster releases, fewer headaches, and a lot more confidence that the documents your customers see are exactly as they should be.
TestComplete Test Adapter
We are using this task 'InstallTestCompleteAdapter@1' in my pipeline. Version: 1.15078.28 Till 12/11, there was no issue. Nothing changed on our side, and starting from yesterday (13/11), the task execution failed with this error: Any suggestions on how to fix this? Thank you!TestExecute logs out before tests run
Running our tests on Azure Pipelines using VMs that we disconnect from for the tests to run at night. Sometimes when tests run at night they cannot because TE needs to get logged back in. Is there a way to make sure it stays logged in or to have the pipeline sign in? I'm guessing this is just a standard login time out but this affects our nightly runs when it does time out. When they run and it logs out it just has this login page open when we check them.Basic actions taking significantly longer when run as part of ADO pipeline
Our nightly CI/CD ADO pipeline runs tests on a dedicated VM solely for running these tests. We have ~140 tests which run over a period of 6-7 hours. When we execute tests as part of the release pipeline via ADO, the tests take on average 20% longer than they do when they are run manually via TestExecute on the exact same machine. Regardless of whether we run just 1 or all ~140 tests through the pipeline, the result is the same. The tests are executed using the tscon disconnection method to run headless, and the same script is run before the comparisons so it isn't related to that. Investigating further into the details, the execution time difference seems to come from extremely basic actions. An action that would take 1 second, can often take 15 seconds when the test is run as part of the pipeline. Some examples of these actions are: A click with no key pressed. Tested object: Aliases.Application.MainForm.buttonMenu.wItems.Item["Browse"].Items.Item["Search"] (Sys.Process("Application").WinFormsObject("MainForm").WinFormsObject("buttonMenu").wItems.Item["Browse"].Items.Item["Search"]) A click at point (10, 10) with no key pressed. '^[F4]' was sent as a keyboard input to the following window or control. Selecting values in combo boxes takes up to 7 seconds. Even just giving focus to Edge takes 10 seconds: 'The window got focus' -Tested object: Aliases.browser.BrowserWindow (Sys.Browser("edge").BrowserWindow(0)) I've tried searching the community for similar threads but have had no luck. Any suggestions or help would be greatly appreciated.
