As stated in this feature request, we work agile and the tester gets new applications versions (almost) on a daily basis.
The tester does not know which objects have been changed/deleted. And does ...
I suppose I kind of already do a scan then?
I have my own framework. Results files. Log files. And I write/update to test suites on TFS. Everything is keyword and data driven to abstract the test code (done by few) from the tests (done by many).
So when I do a run, the first one is always with TFS links switched off. Things get updated/fixed to remove false positives. Second run (or third or more depending on the scale of the changes) is done with TFS links switched on and regarded as the final run. (Against that build version)
We also run "Agile" (or rather, our version of it - as others have said, interpretation of what agile is vary wildly!) but expecting test code to keep up with build code has never been expected, nor asked for. If anything, we tend to use TC for regression tests. So the suitable manual tests are extracted and converted and the regression pack grows.
The application I do most work on at the moment has a large team of devs. Uses several different languages and compilers, and changes quite frequently. There is no way we could keep the test code build up to date, on the same day, as all new application code. It simply isn't feasible.
Based on all the above, and the fact that I wrap all my stuff in enough error handling that a missing object will not crash the test suite (and it's modular so subsequent tests will recover and run), I get the "object not found" messages in my logs and act on them accordingly. At the end of the initial run.
The way I use the name map (high level), Alias Map (condensed high level) and Helper Functions (low level), object updates seldom take me long anyway. 99% of the time I only have to update the name map. The alias doesn't change. That only happens with VERY large structural changes. Which don't happen often.
You're right about time. Some runs, especially large end to end ones, can take hours.
But again, with complexity tends to come dependency. And that is absolutely the case with the stuff I work with. No way you could "simply declare a path" to parts of it. Some parts simply will not be loaded or appear until you do Step A, then apply Action B, then merge it with Step C, and finally press Button D.
I can guarantee you 100%, there is no way you could trigger all the parts of my application without a whole bunch of pre-work. It's a desktop application, not a website. You can't simply jump to a URL in a desktop app ....