Скорее всего у вас неправильно установлен фокус окна, попробуйте следующим образом:

Window SetContext, "CurrentWindow", ""
Result=SQAFindObject("Type=HTML;HTMLId=errorText")

Путь, к директории с библиотеками, правильно указан в Tools->General Options->Preferences, поле SQABasicPath?

Имя скрипта совпадает с наименованием библиотеки (т.е "my")?
Если совпадает, то попробуйте изменить или имя библиотеки или имя скрипта. Перекомпилировать все и запустить скрипт снова.

Странно, я попробовала создать библиотеку с телом процедуры, заголовочный файл с объвлением процедуры и скрипт с вызовом той же процедуры и все заработало...
Возможно буква "y" где-то написана в кирилице?? Может попробуй перенабрать наименования процедуры, библиотеки и заголовочного файла в латинице...

Ну судя по коду у вас там как раз процедура.. хотя для данного случая разницы нет.

Вот пример:

Скрипт - "MyScript"

'$include "mylib.sbh"
Sub Main
   Dim Result As String
   Result = MyFunc
End Sub

Библиотека (*.sbl) - "mylib"

Function MyFunc As String  
   MyFunc = "test"
End Function

Заголовочный файл библиотеки (*.sbh) - "mylib"

Declare Function MyFunc BasicLib "mylib" As String

Компилируем, запускаем - ну просто обязано работать.

А фокус вы устанавливаете в браузер, прежде чем выполнять в нем какие-то действия?

Было бы здорово, если бы вы привели фрагмент кода.

А вы изменяли в самом *.rsp файле проекта (на удаленном компьютере) пути (Location, Path, TestUserGroupDatastorePath, TestDatastorePath) на сетевые пути?

Спасибо Tiana!
Ваш совет помог, но осталась одна проблема - локальный Rational Administrator не "видит" TestUsersAndGroups (эта папка на удаленном расшарена и сетевой путь к ней прописан в .rsp).
И, следовательно, невозможно работать с проектом из приложений (в моем случае RRobot).
Не сталкивались с такой проблемой?

Мне не совсем понятен вопрос. В чем проявляется то, что Rational Administrator не видит TestUsersAndGroups директорию? Выскакивают ли какие-то сообщения об ошибке, при запуске проекта в Rational Robot?

Да, и кстати в свойствах проекта (в Rational Administrator) не отображается почему-то путь к TestUsersAndGroups, ко всем другим папкам есть - а к этой нет...

В свойствах проекта (Rational Administrator, версия 2003.06.15) не предусмотрено отображение пути к этой директории, только Path, Location и TestDataStorePath. Возможно у нас разные версии?..

К сожалению, мне приходилось работать только со скриптами написанными на Visual Basic и в Rational Robot. Там все просто, объект может быть найден в пределах окна, в котором установлен фокус. Окно может быть идентифицировано по заголовку, к примеру, или как текущее активное окно. Т.е. прежде чем выполнять какие-то действия над объектом или группой объектов, надо определить фокус в окно (где расположены объекты) и затем, выполнять какие-то действия над объектами. Вот простенький пример:

'устанавливаем фокус в окно
Window SetContext, "Caption=Test Window", ""
'нажимаем ссылку Test Link в окне
HTMLLink Click, "HTMLText=Test Link", ""

Не знаю, с чем это связано, но если вместо '$include "mylib.sbh" написать '$include "mylib.sbl", то все заработает. Во всех моих скриптах так написано.

В этом случае, вы не сможете в пошаговом режиме проверять выполнение процедуры/функции, описанной в теле подключаемой библиотеки.
Если же вы подключаете *.SBH файл, то вы можете отслеживать выполнение процедуры/функции по строкам.

Для того, чтобы писать "нормальные здоровые скрипты" Вам потребуется время, терпение и желание, собственно, как и во всем другом..
Мой совет, ставить перед собой реальную задачу и решать ее и не гнаться за тем, чтобы охватить все и сразу.
Для начала попробуйте детализировать функциональность программы, выделить основную часть, которую чаще всего выполняется, и написать (средствами записи Rational Robot) скрипт, а затем проанализировать его на предмет - какие команды и когда вызываются, что позволяют делать (Помощь в Rational Robot содержит подробное описание команд и примеры использования).
Потом попробуйте улучшить свой код - выделить входные/выходные данные для выполнения функциональности, организовать процедуру или функцию.
Таким же образом, напишите процедуру для другой функциональной части программы, чтобы потом объединить их в единое целое (скрипт).
Создайте скрипт и попробуйте вызывать процедуры последовательно и т.д.
Успехов!

В "General Options -> Object Mapping" попробуйте прописать класс объекта соответствующему типу объекта. К примеру, тип объекта EditBox и класс объекта TEdit.

Вам помогут:
- найти объект: SQAFindObject ()
- определить значения его свойств: SQAGetProperty ()

Мне кажется, что уделять внимание интерфейсу и качеству его выполнения, с точки зрения эргономичности, аккуратности внешнего вида, соответствия некоторым общепринятым условностям, важно.
Но, как всегда накладываются сроки. Зачастую клиентам требуется, для начала, функционирующее приложение (выполняющее основные функции), а когда оно начинается продаваться или дело идет к этому - приходит понимание того, что оно должно не только функционировать, но и выглядеть так, чтобы его было приятно и удобно использовать.
Весомым аргументом, для переубеждения руководства сделать изменения в GUI, может быть тот факт, что недочеты в GUI влияют на корректное функционирования приложения.

Абсолютно согласна:

Ваше дело зафиксировать эту ошибку. Далее пусть принимает решение об исправлении этой ошибки человек за это ответственный.

С другой стороны,

Если пользователи (к примеру, люди среднего возраста) привыкли в течении например 5 лет что какая-то кнопка расположена там-то, красным шрифтом выделяется одно, а зеленым другое...

имеет ли смысл, настаивать на изменении GUI, если на данном этапе развития проекта, какая-то кнопка расположена не так, как привычно пользователю и красным шрифтом выделяется то, что должно быть выделено зеленым, а то что должно быть выделено красным, к примеру, вообще не выделяется?..

Может многое зависит от того, есть ли прототипы данного программного продукта (которые бы определяли принятые стандарты к интерефейсу в данной области разработки), находится ли продукт в использовании или это новая разработка?

1. Выполнить действие.
2. Анализ текущей ситуации.
3. Оценка текущего и желаемого результата. Оператор IF и описание дальнейших действий для каждого условия.

Чтобы скрипт, как вы выразились, не глохнул, нужно выбрать опцию Continue Execution в Tool/GUI Playback Options/Error Recovery.

Тут я не совсем согласна. Если функциональность в приложении взаимозависима, т.е. нельзя перейти к следующему шагу без корректного завершения предыдущего или сложно спрогнозировать результат, то выбор опции Continue Execution/Skip Current Script/Abort Playback зависит от степени связности выполняемых процедур/функций.
На мой взгляд, опция Skip Current Script может быть более удобна при соответствующей организации скриптов. Т.е в пределах одного скрипта вызываются взаимозависимые функции. Если где-то происходит сбой, ошибка записывается в лог, затем начинается выполнение следующего скрипта, успешность выполнения которого, не зависит от сбоя в предыдущем скрипте.

Насколько мне известно, аналога try-catch в SQABasic нет.

Можно покопаться в "On Error Statement".

Nadezhda, а чем отличается этот подход:

Для того, чтобы "попробовать" что-то сделать, можно предположить, что может вам помешать это сделать. Например, вы не уверены, что элемент, по которому вам нужно кликнуть, присутствует. Тогда нужно использовать функцию SQAFindObject, и только если она даст положительный результат, продолжать действовать. Это предупреждающий подход.

от этого:

1. Выполнить действие. (к примеру, загрузить страницу)
2. Анализ текущей ситуации. (страница загружена или нет)
3. Оценка текущего и желаемого результата. (проверка контента страницы, наличия объектов, значений их свойств). Оператор IF и описание дальнейших действий для каждого условия. (продолжать действовать, но то, как действовать, зависит от каждого случая/результата).

По-моему суть одна, а по-вашему выходит, что подхода два

С другой стороны,

Если пользователи (к примеру, люди среднего возраста) привыкли в течении например 5 лет что какая-то кнопка расположена там-то, красным шрифтом выделяется одно, а зеленым другое...

имеет ли смысл, настаивать на изменении GUI, если на данном этапе развития проекта, какая-то кнопка расположена не так, как привычно пользователю и красным шрифтом выделяется то, что должно быть выделено зеленым, а то что должно быть выделено красным, к примеру, вообще не выделяется?..

Может многое зависит от того, есть ли прототипы данного программного продукта (которые бы определяли принятые стандарты к интерефейсу в данной области разработки), находится ли продукт в использовании или это новая разработка?

Я привел пример. Написал что это довольно специфично (т.е. в каждом проекте по своему и тут вряд ли кто поможет). К чему вопрос-то?

Вопрос по приведенному примеру, т.е что делать в этом конкретном случае:
если

пользователи (к примеру, люди среднего возраста) привыкли в течении например 5 лет что какая-то кнопка расположена там-то, красным шрифтом выделяется одно, а зеленым другое...

но

какая-то кнопка расположена не так, как привычно пользователю и красным шрифтом выделяется то, что должно быть выделено зеленым, а то что должно быть выделено красным, к примеру, вообще не выделяется

Т.е. кривой интерфейс существовал и стал удобным на протяжении 5 лет. Но потом стал выглядеть иначе (красивее, но стал непривычным и как следствие, неудобным). В этом случае стоит ли поднимать эту тему?
Согласна с вами, что понятие удобства - это специфично для проекта, но зафиксировать предложение, донести до менеджера - обязанность тестировщика. ИМХО.
На счет "настаивать на своем предложении". Мне кажется, что "настаивать" не стоит, необходимо развернуто донести информацию, т.е. для чего и кому это надо.
Если менеджер проекта (который за него отвечает) принимает решение о нецелесообразности реализации предложения, то настаивать не стоит. Но само предложение должно быть зафиксировано, возможно отложено.
Если же отказывается разработчик реализовывать предложение, а менеджер подтвердил необходимость его реализации, то опять таки - это взаимоотношения менеджера и разработчика.

Т.е. получается сначала пункт 2 - анализируем ситуацию, потом 3 - сравниваем ожидаемый и полученный результаты

Сами себя запутали :) Обычно анализируется ситуация, после выполнения действия, для возможности выполнения следующего действия (цикл). Вроде такого - мы же не можем анализировать была ли корректно загружена страница до того, как мы выполнили действие "загрузить страницу".
Мы анализируем корректность загрузки страницы и возможность входа в пользователя в систему (к примеру), и затем уже выполняем вход пользователя в систему и проверяем выполнение входа и т.д.

Обсуждение напоминает мне "что раньше было яйцо или курица".

Обычно анализируется ситуация, после выполнения действия, для возможности выполнения следующего действия (цикл).

Здесь вы объединили оба варианта

Здесь я описала более детально описанный мною выше подход. Что сначала все-таки есть действие. Ведь с чего вы начинаете выполнение ваших скриптов, сразу с проверки или все-таки с действия (загрузка браузера/страницы)? Думаю, что с загрузки браузера. После чего будет следовать набор проверок и соответствующих последующих действий.

Я предлагала проверить, есть ли на странице ссылка, на которую надо кликнуть, чтобы нужная страница загрузилась. И эту проверку как раз можно сделать до того, как собственно выполнять действие "загрузить страницу".

Было ли какое-то действие перед тем, как ссылка появилась? Думаю, что было. Т.е. сначала все таки "действие", которое привело к появлению необходимой Вам ссылки.

Тут бы я немного перефразировала:

Мы анализируем корректность загрузки страницы

Это анализ после выполнения действия "загрузка страницы"

и возможность входа в пользователя в систему

а это - до выполнения действия "вход пользователя".

вот так:
Анализ корректности загрузки страницы - это анализ после выполнения действия "загрузка страницы". Возможность входа пользователя в систему - это анализ после действия "загрузка страницы" и до действия "вход пользователя в систему".

Например, для анализа корректности загрузки мы можем проверить название страницы или окна браузера, а для проверки возможности входа пользователя в систему - наличие и доступность полей ввода логина и пароля и кнопки "Войти". Причем не обязательно корректная загрузка страницы будет обозначать возможность выполнения входа пользователя.

Я написала выше "возможность входа пользователя", а не успешный вход. Успешность выполнения входа пользователя в систему, конечно же, будет проверяться после выполнения действия "вход пользователя в систему".

Да, только каких усилий это стоило!

Мне приходилось "сочинять" функциональные требования, но не потому что кто-либо требовал, а скорее, для упрощения процесса понимания бизнес-логики проекта другим тестировщиком (неопытным) и экономии времени. Т.е. чтобы не писать набор тестовых примеров, мне было проще написать требования, затем на нескольких из них привести примеры выполнения тестовых примеров, т.е. объяснить как тестируются требования и затем координировать ход тестирования проекта. После этого, человек оказывался "готов" для самостоятельной работы. На мой взгляд, это была эффективная форма обучения, когда на нового человека не обрушивалось все сразу, а постепенно приходило понимание системы от частного к общему, а также понимание процесса тестирования в компании.
Бывает также, я записываю (для себя) функциональные требования к наиболее сложным функциональным частям проекта, чтобы постоянно на них ориентироваться.

Yuliya, а вы пробовали говорить об этой проблеме с командой разработчиков?
Необходимо выделить сервер для тестирования и с заранее обговоренной периодичностью выкладывать туда версию.
У нас была такая проблема, когда просили тестировать версию на машине разработчика, т.е на версии которая постоянно изменялась. В таком случае, невозможно гарантировать качество выпускаемой версии.

Tiana, у нас разработчики и тестировщики работают на одном сервере

По опыту работы в нашей компании могу классифицировать выпускаемые версии следующим образом:
1. локальная версия продукта (у разработчика на машине).
2. версия для тестирования на локальном сервере.
3. версия для тестирования на удаленном сервере (таких серверов может быть несколько, к примеру, с различной конфигурацией).
4. Production версия.

Версия 1 - это внутренняя версия и тестировщики (у нас в компании) ее не тестируют. Это неудобно ни разработчикам, ни тестировщикам.
Версия 2 - планируется т.е. заранее известно какие изменения в ней будут, оценочное время проведения изменений и следовательно, дата выпуска такой версии; может выкладываться на тестовый сервер 1-2 раза в неделю (хотя может и реже и чаще, все зависит от характера изменений и работоспособности текущей тестируемой версии).
Версия 3 - также планируется, выкладывается после того, как проведено тестирование на локальном сервере, если результаты тестирования удовлетворительные. При наличии других удаленных серверов, мы последовательно выкладываем версию на каждый из них, для дальнейшего тестирования.
Версия 4 - работоспособная версия для Production Server.

Как видите, много этапов. Данный подход не претендует на статус универсального, но нам он подходит и решает проблемы, связанные с совместной работой программистов и тестировщиков, непредсказуемостью результатов тестирования.