Все, в целом, уперлось в отсутствие статичных идентификаторов у объектов. В тех же элементах списков любое изменение их иерархии приводило к несовпадению сбою в привязке, т.к. объект был привязан к номеру ячейке в списке, а при изменении иерархии в списке номера ячеек не менялись, менялось их содержимое (текст). Если вместо номера ячейки пытаться привязаться к тексту в ячейке, то ТС уже не мог найти эту ячейку. Та же проблема была с выпадающим списком, т.к. как он формируется не совсем понятно и ТС видел разные списки как один и тот же. С таблицами та же проблема - количество ячеек формировалось исходя из того, что видно на экране в данный момент, и ячейка с номером 1 - это всегда верхняя ячейка.
Соответственно, как я понял, чтобы ТС корректно работал с приложением, необходимо иметь предельно четкое и статичное дерево объектов.
Судя по всему - вы оказались "жертвой" одной из методологий разработки, когда объект генерируется "на лету" динамически, никак уникально не идентифицируется (только некий идентификатор, уникальный для данной сессии существования объекта данного типа) и с внешним миром общается путем отправки сообщений, которые обрабатываются кем-то, кто вполне может не иметь ни малейшего представления от кого он получил сообщение и кому он отвечает.
Возможно, что это и удобно при разработке, но при тестировании это вызывает отмеченные существенные проблемы идентификации целевого объекта тестирования. И это - не проблема TestComplete, а общая проблема, которая будет при использовании любого инструмента тестирования. Что можно сделать, например, если веб-страница постоянно перегенерирует таблицу? Как найти ее требуемую ячейку, если у нее нет определенного и уникального идентификатора? Только либо по известному значению данных в ней, либо по известному ее положению относительно иных стабильных объектов (например, вторая ячейка вниз и на столбец правее от ячейки, в которой находится кнопка "Сохранить").
Суммируя: статичное дерево объектов - не обязательно, но чем легче и уникальней идентифицируются тестируемые объекты - тем проще и надежней работать. Иначе - ищем ближайший стабильный объект (например - панель) и внутри нее начинаем перебор, пока не найдем требуемый объект (например, ищем все таблицы на панели и, для каждой найденной таблицы, перебираем все ячейки, пока не найдем нужную - то-ли по тексту внутри нее, то-ли по ее атрибутам (красный фон), то-ли еще как).
P.S. По хорошему - такая ситуация должна быть доведена до руководства и осознаваться им. По сути, вы являетесь разработчиком, которому для работы предоставлена среда (тестируемое приложение), которая не предоставляет достаточно информации о своем состоянии. Наверное, аналогичный пример, это если-бы при сохранении файла ОС не сохраняла-бы его по определенному и постоянному пути, а, например, где-то, в пределах данного диска. Т.е. даем команду записать файл - ОС отвечает: "записала на диск с:". А как найти? А как хочешь: то-ли сканируй все каталоги, то-ли еще как... Нашли файл. Поменяли в нем что-то. Снова командуем сохранить. ОС отвечает: "сохранила. Но сейчас - на диске d:. А тот, что был на с: - стерла". И снова ищи...
