Новая сравнительно крупная задача, поставленная перед A1QA, потребовала недорогого и в тоже время полнофункционального решения в области автоматизации. Выбор пал на TestComplete 4 как на недорогое средство, пользующееся популярностью среди пользователей, о чем свидетельствует достаточное количество положительных отзывов.

В действительности средство имеет определенные недостатки:

1. Есть дефекты, сообщения о которых поступили от пользователей в службу поддержки.
2. Переход на ежемесячные версии TC затруднён из-за возможных дефектов.
3. Быстродействие Object Browser заметно падает, когда на веб-странице очень много элементов.

Помимо этого обнаружено много более мелких недостатков.

Положительные стороны:

1. Видит практически всё и видит удобно.
2. Свободное подключение .NET библиотек через CLR Bridge.
3. Возможность использования TestExecute — отдельного продукта для исполнения тестов.
4. Множество удобных функций, облегчающих разработку и, наконец, наличие свойств, делающих ТС похожим на средство разработки.

На деле средство оказалось достаточно удобным, учитывая все трудности, с которыми пришлось столкнуться:

• Проблемы с DataGrid, несмотря на их сложность, решены при помощи реализующей его dll-библиотеки. Возможность организации такой обратной связи гарантирует положительное решение проблемы.
• Удобная внутренняя система регистрации, упаковки результатов и отсылки писем использована на полную мощность.
• TestExecute позволил организовать прозрачный программный запуск извне.
• Удалось безболезненно повторно использовать разработки заказчика благодаря диагностике системы после установки.

На одном из проектов для web-тестирования обнаружена утечка объектов. Связана она с тем, что на протяжении тестов значения объектов браузера и страницы хранятся в переменных в течение всего времени выполнения скриптов. При обновлении страницы старый объект теряется в Object Browser. Иногда такого не происходит. Именно из-за этого «иногда» существование проблемы не было выявлено на ранних стадиях разработки.

Однако решение найдено. При каждом поиске объекта используется полный путь к родительскому объекту, ссылка на который в данный момент может быть некорректной:

eval(“parent = ” + parent.FullName)

Архитектура автоматических скриптов претерпела незначительные изменения, позволяющие исправлять подобные ситуации в одной функции для всего объёма скриптов.

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

Единственная сложность – ограничения, накладываемые конфигурационным файлом приложения на отображаемую информацию. Например, не все созданные записи могут быть отображаемыми. Проделав определенную работу, сложности конфигурации удалось решить.

Что касается базы данных, то могло показаться, что встроенная поддержка ADO решает проблему, но для проектов, поддерживающих различные платформы для хранения данных (для систем работы с документацией это могут быть Documentum, SharePoint, внутренняя база данных), это недостаточно подходящий механизм. Кроме того, язык скриптов не обладает достаточной мощностью для решения задач такого уровня.

Потенциальная возможность таких запросов даёт начало развитию коннектора к базам данных различных типов, реализуемому отдельно от TestComplete и подходящему для разных приложений и средств автоматизации, но это уже другая область задач.

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

Было проведено давно ожидаемое бета-тестирование пятой версии. Интересует практически каждое улучшение, особенно:

• поддержка Vista, IE 7.0, FireFox для увеличения количества сред тестирования;
• безболезненный переход скриптов, написанных на 4.XX для пятой версии.

Особенно актуальны изменения в интерфейсе разработки. Там многое можно было бы сделать лучше, например, организовать группировку кода по папкам, что позволило бы выносить тест кейсы в отдельные модули, складывая в отдельные папки и не влияя на размеры дерева.

Некоторые приложения используют изменённые элементы управления. Практически одновременно столкнулись с такой ситуацией на двух проектах (standalone). Базовые свойства таблиц доступны, но значений получить не удаётся.
В одном случае задача решилась обходным путём – косвенное определение по состоянию других элементов управления,  в другом – команда разработчиков внесла изменения в приложение, сделавшие доступными нужные данные.

Таких проблем можно избежать, привлекая тестировщиков на самых ранних этапах разработки приложения, когда проводить изменения гораздо дешевле.

Для автоматизации веб-тестирования был опробован Selenium. Достаточно новое интеллектуальное и, что немаловажно, бесплатное решение. Из множества преимуществ Selenium можно выделить следующие:

• Возможность использования языков высокого уровня (Java, C#) для создания тестов. Это позволяет избежать многих типичных проблем, которые возникают при разработке и использовании скриптов. Это повлияло и на скорость разработки, т.к среды высокого уровня более интеллектуальны.
• Кроссбраузерность и мультиплатформенность. То, что один и тот же сайт можно тестировать одним и тем же кодом под разными браузерами и в разных операционных системах, значительно увеличивает эффективность автоматизации.
• Selenuim-тесты выполняются значительно быстрее, чем разработанные с помощью альтернативных веб решений.

Создатели Selenium советуют использовать системы модульных (unit) тестов для автоматизации, в частности TestNG. Связка Selenium – Java – TestNG показала себя с очень хорошей стороны. Автоматизация стала проще из-за следующих преимуществ TestNG:

• Встроенная система отчётов. То, что раньше приходилось разрабатывать отдельно, идёт готовым формализованным решением.
• Тестовые сценарии создаются в виде xml-файлов, а тестовые данные доставляются отдельно, что значительно упрощает создание тестовых данных.
  

Всё чаще появляются задачи автоматизации приложений, в которых пользовательский интерфейс сделан на Infragistics. Внешне простой интерфейс, на самом деле сложная и запутанная система взаимодействующих окон.

Test Complete работет с Infragistics достаточно неплохо. Однако неизбежно то, что на поиск свойств уходит больше времени, усложняется структура обращений.

Все больше и больше продуктов, поступающих к нам с целью тестирования, предусматривают интеграцию с другим ПО. Ранее тесты взаимодействия входили в состав функционального тестирования. Теперь же, в связи с возрастающей сложностью программного обеспечения, возникла необходимость выделить тесты взаимодействия в отдельную группу. 

Итак, новым направлением в развитии стало тестирование интеграций с внешними приложениями. Самый первый и, наверное, самый распространённый случай – MS Office.