История успеха TAF Core — фреймворка для автоматизированного тестирования

TAF Core — это keyword-driven фреймворк автоматизированного тестирования, который можно использовать для автоматизации любого вида приложений и программных продуктов, используя любой инструмент автоматизированного тестирования.

Этот фреймворк был разработан усилиями нашей команды во время моей работы в EPAM Systems. Сейчас он успешно используется во многих проектах, упрощая и ускоряя процесс автоматизированного тестирования, а также увеличивая ROI от автоматизации, делая процесс тестирования более эффективным, работу автоматизаторов более интересной, а наших заказчиков — счастливее :).

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

Всё началось с первых дней моей работы в компании EPAM Systems тогда ещё инженером по тестированию ПО. Первый день моей работы на EPAM’e — 19-го января 2004-го. Тогда я ещё параллельно учился в на 4-м курсе Белорусского Государственного Университета Информатики и Радиоэлектроники по специальности математик-системный программист. Я познакомился с фреймворком для автоматизированного тестирования HTTP API одного из приложений. Идея была такова — в Excel’e писался сценарий, описывающий какие методы с какими параметрами запускать и что ожидать на выходе, а фреймворк выполнял этот сценарий.

Чуть позже я познакомился с фреймворком для тестирования GUI приложения. Там было всё сложнее — весь код был написан на скриптовом языке, включая логику выполнения тестов. Хотя там и использовался метод функциональной декомпозиции, что делало фреймворк более универсальным, его поддержка и обновление могло происходить только людьми с хорошими навыками программирования. На практике же скрипты обновлялись людьми наиболее заинтересованными в их актуальности — тестировщиками, хорошо знающими бизнес-логику приложения. Что и привело фреймворк к постепенному увяданию за счёт увеличивающегося времени на отладку.

Подоспел 5-й курс моей учёбы в БГУИР’e — наступило время выбора темы диплома. Жизнь сама подкинула интересную проблему, которую можно было решить в рамках диплома — необходимость тестирования Web Service’ов. В конце 2004-го года хороших инструментов для автоматизированного тестирования Web Service’ов ещё не было, а те, что были, требовали больших трудозатрат для создания и расширения базы тестов.

В результате мною был создан инструмент, позволяющий проводить тестирование любого вида Web Service’ов, путём создания сценариев в Excel’e, описывающих бизнес-логику в виде ключевых слов. Все технические детали были спрятаны внутри инструмента. Так как полученный продукт, получивший название WSKeyword, был реализован на .NET C#, скорость выполнения тестов была очень высокой — в некоторых случаях сотни тест кейсов выполнялись за несколько секунд. Когда я защищал диплом, WSKeyword уже успешно использовался на проекте.

Следующим этапом была реализация идеи создания keyword-driven фреймворка, который бы можно было использовать для автоматизации тестирования полноценного web-приложения. На тот момент было уже много статей, описывающие keyword-driven подход к организации фреймворка, но они описывали примеры использования с простыми web-приложениями. К тому же предлагаемые форматы сценариев очень ограничивали возможности в описании тест кейсов со сложной бизнес-логикой. Плюс предлагаемые keyword-driven фреймворки выступали как усовершенствованная альтернатива data-driven подходу, убирая его простоту и удобство.

В итоге был создан EPAM SilkTest TAF 0.1 — keyword-driven фреймворк для любых web-приложений, с дополнительными возможностями, такими как:

• работа со сценариями, похожими на сценарии для ручного тестирования.
• поддержка чистого data-driven.
• авто-генерация сценариев полностью удовлетворяющих формат сценариев для ручного тестирования.
• и другие приятные мелочи, делающие автоматизацию более эффективной.

К сожалению этот продукт так и остался применятся только на одном проекте. Попытка внедрить его на других проектах привела к неудаче, так как ядро фреймворка имело сложную структуру и не было покрыта юнит тестами ввиду ограниченных возможностей SilkTest’a и недостаточной моей квалификации в юнит-тестировании на тот момент, что затрудняло внесение изменений в Controller. Хотя если оставить его в том виде, в котором он есть, то можно решить большинство задач по автоматизации Web-приложений.

Другое ограничение было в том, что использовать его можно было только с SilkTest’ом, в то время как существует множество других инструментов, а зачастую компании, заказывающие услуги на автоматизацию, уже владеют лицензией на определённый инструмент и отдают предпочтение ему. Это и привело меня к тому, что я решил описать, каким же мог бы выглядеть фреймворк в идеале.

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

• Product independent. TAF have to be used for automation of testing any product without or with little modifications.
• Manual scenarios. TAF executes scenarios for manual testing without or with little modifications.
• Tool independent. If one tool could not work with specific application, you could change it. QTP, SilkTest, Selenium, TestComplete, any.
• Open source. Anyone could participate in TAF implementation and maintenance.
• Data-driven. Test data could be separated from test case logic and stored in separate files.
• Usage simplicity. Anyone can use TAF, expertise is not required.
• Verbose documentation. This is for automation developers, who would like to implement new features or modify existent.

Через полгода жизнь подкинула возможность реализовать такой фреймворк и начать его использование — так появился TAF Core 1.0 и TestComplete TAF 1.0. В течение несколько месяцев использования он постоянно обновлялся, пока не наступила необходимость создания возможности запускать разные части тестов с помощью разных инструментов. Так появился TAF Core 2.0. Эта версия продолжает развиваться и совершенствоваться на данный момент.

Следующим этапом было реализация Controller’ов для других инструментов и внедрение на разных проектах. Когда количество инструментов и проектов достигло перевалило за цифру 3, стало очевидно, что TAF Core можно использовать с любым инструментом и на любом проекте. Хотя я всегда знал об этом :). Количество поддерживаемых инструментов постоянно растёт, среди них TestComplete, Watir+AutoIt (на Ruby), QTP, Selenium. Также и растёт количество проектов. Наступило время TAF Core 3.0. Каким я вижу его сейчас?

• Перенос части ответственности с Controller’a на TAF Core. TAF Core сам подсчитывает статистику по тест кейсам, занимается всеми вычислениями и подстановкой run-time переменных.
• TAF Core позволяет выполнять ручные сценарии в формате, который сейчас генерируется функцией Manual Test Scenarios.
• У TAF Core есть GUI, который позволяет проводить процесс настройки, запуска и отладки быстро и интуитивно понятно.
• Улучшенная документация, позволяющая создавать полноценные Controller’ы без дополнительных уточнений.
• Инструкция по созданию Unified Test Scenarios.

Некоторые из этих пунктов я даже не знаю, как реализовать на данный момент. Но также было и с описанием требований к TAF Core 1.0 — в итоге они были реализованы процентов на 90. Это значит, можно скоро ожидать TAF Core 3.0 с этой функциональностью.

Всё создаётся дважды: первое творение — мысленное, второе — физическое.