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 ...
(Much of this discussed in the forum thread but to summarise my thoughts ....)
Conceptually, I kind of like the sound of a "scan" feature.
I would NEVER want an automation tool to start updating object maps etc without me checking the changes it wants to make first.
So having it update/guess missing object, on the fly, during a run, I would NEVER risk using.
Which brings me back to the main blocker from my perspective ....
How does it do a "scan" without doing a run? Many object will only be loaded and/or triggered as a result of other actions (which will happen during a test). So you pretty much have to do a test run in order to do the "scan" anyway?
I usually do this anyway. First run finds the broken bits and failures. I go through these, find the areas that failures are dues to changes (ie - not actual failed tests) and the ones that are due to bugs (not always obvious until you update for changes - these come out more often in run 2) and the subsequent run then finds the actual failures.
I just don't see how you do a scan without a run?
Except on really simple applications with very little complexity or variation in behaviour.
Having it scan and update Object/Alias names in script when you change the mapped object (I can avoid this being a problem most of the time already my using Aliases well/properly) would be handy though.