Could you show example of incorrect namemapping? What properties and values are wrong do you think?
Anything mapped using a property that contains some sort of version number as an identifier has no chance.
Reliable long term name maps, in my experience, require a bit of donkey work up front. Choose rock solid, reliable properties. If you can, make sure your dev team know that you're using these properties. A helpful dev team will give you properties which work well with automated tests.
But I map everything manually and am very selective of the properties I use.
Making good use of the Alias map can make maintaining the integration of mapped objects into scripts much, MUCH, easier as well.
I have lost track of how many times I've said it on here but ......
If you are using Aliases which are a straight copy of a mapped object, complete with big horrible long name as captured by the system ..... YOU'RE DOING IT WRONG!!!!
The Alias objects should be shortened, human readable, and have a MUCH more direct mapping to how THE USER sees the application.
Systems need lots of invisible layers to build themselves. Users don't know, or care, about most of these invisible layers. You Alias map should reflect that.
eg.
screenCFS1911.frame-x371bv4.panelz51a.container1.container2.buttonbar.containerb1z3922yy.button1xSV
... is NOT a good alias.
CustomerPage.ButtonBar.Save
... IS a good alias.
Which also has the advantage that if container layers change (as they often do) but the logical layout of a screen does not (at least, as far as the end user is concerned) then you fix the object map. Make sure the Alias is still tied to the fixed object, and you scripts don't need any updating.
ie. Aim to only have to update the low level (object) map. Not the high level (alias) one. Obviously, it's impossible to guarantee you'll never have to update both. But a little careful planning and prep keeps it to a minimum.
One thing to consider in how you think about name mapping... in some automated frameworks, especially with things like Selenium and Maven and so forth, there's the concept of a "Page Object Model". This is something you build very deliberately and very carefully so that your tests that you execute have a good reference model to be able to interact with the UI.
NameMapping is just such a thing, but it is built into the TestComplete tool rather than something you need to build by hand in C# or Java. So, the same amount of care and deliberation that you would take in building a POM for a Selenium framework you should use with NameMapping. The Automatic mapping is a good start, but just like doing record/playback test scripts, you don't want to just leave those as is... Use the automatic mapping to give you reference points of the objects that you are interacting with and then, as Colin_McCrae pointed out, spend time in picking good, solid, reliable properties for your more permanent maps. Use features like the "Extended Find" and "Required Children" to handle some of the variability... use wildcards where they are useful but not too much as this could cause your name mapping to get confused between two similar objects. AND.. as Colin_McCrae also mentioned, don't be afraid to ask your developers to add a few little properties to components to make them easier to find. I did this with a web application I was testing once (and they are NOTORIOUS for having constantly changing components and object trees) and it made a HUGE difference. No matter how the application changed, those custom properties NEVER did and it made my NameMapping MUCH more reliable..
