История успеха 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 с этой функциональностью.

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

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

  1. Уведомление: webnovosti.com
  2. Где можно найти TAF модуль для TestComplete?
    Возможно его сорцы, для расширения.

    Заранее спасибо.

Добавить комментарий для Миша Субоч Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.