А вам интересно, какие проекты по автоматизации вокруг вас?

меня всегда мучили подобные вопросы:

  • а сколько вообще людей работают автоматизаторами в СНГ?
  • как много вообще проектов по автоматизации?
  • как их выполняют?
  • что у таких проектов общего?
  • какая архитектура используется и почему она выбирается?

я говорил с разными автоматизаторами и компаниями, и спрашиваю вас.

а ВЫ (ваша компания) готовы поделиться такой информацией во благо того, чтобы другие узнали как она в принципе делаете на просторах СНГ?

 

Шаблон, который хотелось бы увидеть:

  1. Почему вы начали автоматизацию? Т.е. цели, которые вам ставили
  2. Что вы автоматизируете? И что не удалось автоматизировать?
  3. Как выбирали конкретный инструмент?
  4. Какой технологический стек вы используете?
  5. Сколько людей задействовано в автоматизации?
  6. Как организованна работа автоматизатора?
  7. Какой подход был выбран и почему? Какая его архитектура?
  8. Как быстро оправдалась ваша автоматизация?
  9. Плюсы вашей автоматизации? Или чем вы больше всего гордитесь?
  10. Минусы вашей автомматизации? Или чем вы недовольны?

У нас WPF\WCF приложение. Автоматизация с использование TestComplete 8. Тесты пишутся в VS2010. Запуск и обновление организовано с использованием Build Sevice. Готов поделиться опытом.

Наша компания занимается интеграционными решениями, поэтмоу используем самописное решение. Если тесируем GUI, то стараемся это делать при помощи RFT, если нет определённых требований от заказчика.

На предыдущем месте работы было очень много автоматизации. Все писали на TestComplete7 / JavaScript

Создал отдельный движок по обработке тестов (которые хранились в базе) и работали по принципу keyword driven test. Тестами занимались в той или иной степени все в отделе. 

 

Сейчас использую WebDrover для GWT портала. (Java) Отлично идет, тоже подход keywork driven с хранением самих тестов и результатов в базе. Все можно отслеживать в online режиме + интеграция в одном отчете атоматизированного и ручного тестов если в том есть необходимость. Сейчас нас 2 человека и оба полностью во все это погружены. Ручками все равно много тестируем, но лишь потому что от нового функционала никуда и никогда не избавишься а старого много. Но постепенно весь регрешн закроем автоматизацией с запуском на CI сервере.

 

Компания, видимо, пока не готова. Ну что ж, расскажу за себя.

 

- Почему вы начали автоматизацию? Т.е. цели, которые вам ставили

Почему начал:  "Машина должна работать, а человек - думать". 

Какие цели:

а) автоматизация рутины. Все, что я хочу видеть сделанным не ручными повторениями.

б) В 2009-2010 году мы (команда) занимались разработкой брендовых мобильных приложений под Windows Mobile для Очень Известной Компании. В требования ОИК входило monkey testing с помощью Microsoft Hopper Test Tool, - инструмента, посылавшего приложению последовательность случайных кликов, движений, клавиатурного ввода и всякого такого прочего. Это "кунг-фу стиля обезьяны" оказалось очень эффективным инструментом для проверки приложения на устойчивость и утечки памяти. 

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

- Что вы автоматизируете? И что не удалось автоматизировать?

а) то самое monkey testing, несколько его разнообразя-"притирая" под текущие приоритеты

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

- Как выбирали конкретный инструмент?

По-моему через alternativeto.net, с прицелом на Free and Open Source, а также кросс-платформенность
 

- Какой технологический стек вы используете?

В данный момент лично я использую  "чистое" Sikuli/Python.  Для выяснения того, "что именно сделала "обезьяна" чтобы завалить приложение" иногда используется видеосъемка на веб-камеру.

Вообще в рамках проекта также используется тестирование серверной части с помощью SoapUI.


- Сколько людей задействовано в автоматизации?

Двое соответственно. Один - SoapUI, я - "дрессировщик обезьяны".


- Как организованна работа автоматизатора?

Подход monkey testing не требует существенных затрат времени на кодирование и организацию. Переписывание скрипта-инструмента под специфическую задачу с пробными пусками теста занимает несколько часов максимум.

По поводу части автоматизации SoapUI - отвечать не готов, но люди, которые знакомы с этим инструментом, все и так знают :)

- Какой подход был выбран и почему? Какая его архитектура?

Как я уже сказал выше, monkey testing оказалось довольно эффективным инструментом тестирования на стабильность: падения и утечки памяти, в том числе в регрессионном тестировании:  если в предыдущей итерации "не падало", а после изменений в этой в случайных тестах пошли падения - определенно где-то что-то "сломали" или плохо (на/пере)писали.
 
Архитектура для "случайных тыков" особо не требуется, но свои хитрости есть, скажем, механизм выведения обезьяны из "тупиков", ситуаций где отношение площади кнопки выхода к общей площади экрана эмулятора очень мало. Позже я усовершенствовал скрипт, добавив возможность выбора с разной вероятностью разных серий действий (общая серия кликов, серия в регионе меню, серия перетаскиваний, серия вперед-назад... всякие).

По причинам выбора Sikuli добавлюто 

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


- Как быстро оправдалась ваша автоматизация?

Быстро.  "Валит" приложение - значит работает и ловит баги :). Ну и, кроме того, скрипт довольно легко приспосабливать под разные проекты, повторяюсь.
 

- Плюсы вашей автоматизации? Или чем вы больше всего гордитесь?

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

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

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

 

- Минусы вашей автоматизации? Или чем вы недовольны?

Как всегда - мало времени, я бы каждый промежуточный релиз гонял бы еще неделю сверх срока минимум :)

Да и сам скрипт можно еще оптимизировать и усовершенствовать.

Движок Sikuli - это продукт beta-качества от небольшой команды, в котором довольно сильно течет память.

1. Почему вы начали автоматизацию? Т.е. цели, которые вам ставили

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

2. Что вы автоматизируете? И что не удалось автоматизировать?

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

Не удаётся автоматизировать только новый функционал, а для всего остального главное найти время и оно благополучно покроется плотным слоем тестов :)

3. Как выбирали конкретный инструмент?

Гугль + форумы + общение с тем, кто в теме :)

4. Какой технологический стек вы используете?

В итоге остановился на Selenium'e, использую его в связке с Python'ом. Тесты крутятся на Jenkins CI.

5. Сколько людей задействовано в автоматизации?

Пока-что только я один, но в скором времени ко мне добавится ещё один боец :)

6. Как организованна работа автоматизатора?

Общее тестирование проекта лежит на мне, поэтому что покрывать тестами в первую очередь решаю я + общаюсь с саппортом и спрашиваю на что чаще всего жалуются люди. 

7. Какой подход был выбран и почему? Какая его архитектура?

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

Это упрощает написание скриптов - один раз сделал скрипт test_mainpage и можешь вызывать его из всех своих скриптов типа test_registeration, test_login, test_forgot_password и т.д.

Это упрощает поддержку скриптов - если вдруг что-то изменилось, то достаточно внести изменения только в один скрипт.

Это уменьшает количество строк кода в скрипте тестирования функционала и улучшает читабельность кода.

8. Как быстро оправдалась ваша автоматизация?

И хоть я только начал более или менее серьёзно писать тесты, но уже они стали находить баги в работе продукта. Уверен, что дальше их КПД ещё более повысится.

9. Плюсы вашей автоматизации? Или чем вы больше всего гордитесь?

Она есть и она работает!

10. Минусы вашей автомматизации? Или чем вы недовольны?

Низкое покрытие функционала ввиду малого количества скриптов, которые ещё не успели расплодиться ввиду малого количества выделяемого времени.