Hi David,
In addition to Julia's answer, I would like to add my two cents. :) (This also will be relevant to your
http://community.smartbear.com/forum/post/?mode=singleThread&thread=292c9e02-30b5-45c6-9f32-9056da5e88d7 thread and Stephanie's comment.)
The problem you are seen is quite common for the software developed using certain technologies and development patterns. One of the worst cases I've seen so far was with .Net WPF technology and view-controller model.
The case is that such software generates UI controls during runtime and does not assign unique names (IDs) to the generated controls. This results that instead of using these IDs to map controls within the NameMapping scheme and use them later to identify controls during test run, TestComplete resorts to secondary NameMapping algorithm/method/template scheme. This secondary approach uses Window Class, Window Title and Index properties as identification criteria for the control. And here is the trap: the case is that usually dynamically generated controls of the same type (e.g. buttons) have the same Window Class and the same (usually empty) Window Title. And this is not TestComplete's fault, but the same problem will exist for any tool just because Window Class and Window Title are system properties assigned by the operating system (OS). So the Index property appears to be the only one left that makes it possible to distinguish one control from another of the same type (e.g. one LitRadioButton button from another one). But the Index property is a dynamic 'artificial' one that indicates the order in which controls of the same type were created during runtime, i.e. it is not persistent and may (and usually does for the dynamically generated controls) change between different runs of the tested application.
For example, from the user point of view, your software may have two buttons with OK and Cancel labels on top (not captions, but for the end user looking like button's caption!). But within the software these buttons may be identified as Button('LitRadioButton', '', 1) for the OK and Button('LitRadioButton', '', 2) for the Cancel button during the first run, but for the second run the order or their generation may change with the result that OK button will be identified as Button('LitRadioButton', '', 2) and Cancel as Button('LitRadioButton', '', 1). Obviously this will break your tests.
To make the situation even worse, WPF applications are using a lot of panels with the same Class name and empty Title inserted by the runtime engine.
The best approach to overcome the above problem is to talk with Development and ask them to assign unique ID to every UI element that your tests need to interact with. But the talk may be not successful because: a) Development may not need ID for some controls and thus forget to assign ID to this control; and, more serious, b) assigning IDs to controls may contradict to some development patterns used to develop the given software (for example, the mentioned view-controller model) and Development may refuse to break the pattern.
One of the best Best Practices :) I've met was recommendation from Christian Ekiza (
http://blog.smartbear.com/software-quality/bid/169929/) posted here several years ago. He recommended not to record the test from scratch and let TestComplete to generate NameMapping according to its default algorithms, but instead execute the test manually, without recording and examining every UI control used in the test in TestComplete's Object Browser. The goal of this examination is to identify what properties are accessible from the Object Browser for this or that control and what properties have unique and stable values that can be used for reliable control's identification. Once such properties are identified, the new NameMapping template (mentioned in Julia's message) should be created and only then you may record the test.
One more possible approach is to use the recorded test (recorded as a script, but not as a keyword test) as a skeleton and use different Findxxx() functions (e.g. FindChild, FindNamedChild, etc. -- see TestComplete's help for more details) to search for the needed controls.
I would recommend the 'Creating Reliable Tests For Dynamic Objects with Name Mapping' (
http://support.smartbear.com/support/screencasts/testcomplete/reliable-tests-for-dynamic-objects/) video from the TestComplete Webinars and Videos page (
http://support.smartbear.com/screencasts/testcomplete/) - it might inspire you with better understanding of what's going on behind the scenes in the tested application and ideas of how this may be solved for your particular tested application.
