But then my tests fails, It says ‘Object not found’,
I downgraded backI to:
And it works. This is legacy software I seldom touch. This is the only error I find.
It is unable to find a windows that holds the config. It is in my *.tcNM.
Ind if I use objectspy and click the window it surely says it already exists.
(I do not have it here because I do not have older testcomplete, So I did not save it)
So I’m wondering is there a way to get more info from testexecute runs?
Or a way to traverse the namemapping to see what exists and what do not exists at a given time?
There is definitely something wrong regarding object recognition in the latest TC version. Our tests (web-based), which worked flawlessly in previous version, started to fail with “element not found” errors, while the element is clearly visible on screen.
Also, the failing action (typically Click) seems to ignore default timeout and fails well before reaching it. I had to add WaitAliasChild here or there before performing an action on “failing” elements. But this is definitely not acceptable solution. The problem is the random nature of this issue. So while I may add WaitAliasChild on certain actions, it may fail with some other in next run. And so far, I cannot reproduce it with something generic, like SmartBear page, so I have no project to send to support.
So I found the reproducible steps and created a ticket. Smartbear folks are looking into it. The workaround is to go back to 15.71. My guess is that they broke it with this fix in 15.72:
Changed the wrong timeout on an unsuccessful WaitAliasChild
I used https://my.smartbear.com/downloads/TestComplete15XX.exe download and found that 15.71.4.7.x64 works fine while 15.72.x.x do not work. So there are changes between 15.71 and 15.72 that break my object recognition. I just use this version.
15.73 was *not* the best thing ever. However, 15.74 was just released. Maybe the Qt bug is fixed in it. I know it was causing problems for a number of people.
I’m afraid, there seems to be no change with the described “element not found” error in 15.74. I can still reproduce the problem with my simulation project. So we will probably have to wait for another release.
Similar problem on our side on the 75 version.
Had been waiting for a fix of another defect since February (stayed on 15.70). Updated and got the broken version again.
Hi folks, just released TC 15.76 may eventually (finally) fix the problem with WaitAliasChild! I can’t test it right now, but I hope the problem is solved
Fixed regression that caused errors when using WaitAliasChild().Exists on non-existent windows. It restores behavior from version 15.71.
Unfortunately, 15.76 did not fix the problem. And there is no news regarding this issue from support. Guys, if you are experiencing these random “element not found” errors, please contact TC support regarding this problem and link this post. We need to make a pressure on them. I even provided a reproducible sample project showing this issue. It’s absurd that such critical bug is not fixed after 4 months of reporting it.
I just replied to the last support’s answer to my ticket with “slightly unhappy” tone, demanding escalation of the issue to someone responsible. It’s absurd that we are paying a premium price for crippled product, which forces us to use several versions old release. Not to mention that we are wasting our time trying every single new release, only to find out that the bug is not fixed yet.
I just found this thread. I have been having issues for months as well. it started on Websites and would only find certain items if I put a debugging pause, then right-clicked on that step and chose “Highlight on screen.” It would highlight, and then if I resumed the test it would work fine (unless it got to another item it didn’t like).
15.71 was the only version that worked. I put in a ticket.
15.76 fixed the website issue for us, but now our Windows app is broken and doing the same thing. I let them know in the ticket but they said it is a different issue now, so I need a new ticket.
So I put one in last week, but not much has happened with it yet.
Now with the Chrome/Edge update breaking all of the web tests, we are going to need to update to 15.77 to fix those and I am assuming our Windows apps are going to break again.
Originally posted by antonns on September 11, 2025
I stay on 15.70. Which was released 11 december 2024. That means that I have no working version for nine month. And it much easier to stay on old version then get new potential defects in new releases.
I’m trying not to comunicate with Smartbear support. Because mostly I feel like I’m being taken though the typical long process wich leads to “We can not reproduce, unless you send us your app, your test project, etc.”.Often I have to spend hours and even days to get some result of such comunications.
But regulary I got emails like “let’s book a time so we can discuss the product price increase, because of new features we included (wich I do not require)”.
Originally posted by pkudrys on September 11, 2025
The problem of using old TC versions is, that they does not support recent browsers. And in our corporate environment, our browsers are managed by the company policy and they are simply updated as soon as the new version is out. Which makes the old TC versions practically useless.
It’s outrageous that they are unable to fix such critical issue for such a long time. We even provided reproducible steps and sample project several months ago! They are pretty agile when it comes to increasing prices and calling us to upgrade earlier to “save” money. But they seem to be quite incompetent, when it comes to bug fixes. We are really disappointed and seriously considering lowering number of TC licenses.
Originally posted by rraghvani on September 12, 2025
I totally agree and understand your frustration, as I feel the same too. However, end-users need to understand, that TestComplete typically supports Chrome and Edge versions that are 2–3 versions behind the latest release due to the following reasons:
Browser internals change frequently - each browser update can introduce changes to the DOM, JavaScript engine, and debugging APIs, which may break existing functionality.
Stability and compatibility testing - SmartBear needs time to test and validate each new version to ensure stable integration and prevent test failures.
Enterprise alignment - many enterprise environments lock browser versions for consistency, so supporting slightly older versions aligns with real-world usage.
Reliability over recency - prioritising stability helps avoid flaky tests and ensures a predictable testing environment.
Changing APIs (CDP) - Chrome and Edge use the Chromium DevTools Protocol, which evolves frequently. TestComplete must adapt its internal mechanisms accordingly before offering support.
In short, this delay is intentional to ensure reliability and consistency across different environments.
Many organisations use locked or controlled browser versions in their environments to ensure consistency and compliance. TestComplete’s support for slightly older browser versions aligns with these enterprise practices, ensuring stable, predictable testing across teams. However, it seems like many organisations do not implement to this rule!
