Компания, видимо, пока не готова. Ну что ж, расскажу за себя.
- Почему вы начали автоматизацию? Т.е. цели, которые вам ставили
Почему начал: "Машина должна работать, а человек - думать".
Какие цели:
а) автоматизация рутины. Все, что я хочу видеть сделанным не ручными повторениями.
б) В 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-качества от небольшой команды, в котором довольно сильно течет память.