Вам еще автоматизируют? - Гоните их в лес.

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

---

Введение

Автоматизация, выполняемая разработчиками (модульные и интеграционные тесты), так же как и автоматизация нагрузочного тестирования нужна – даже обсуждать не буду...
Автоматизация же функционального тестирования, написанная тестировщиками – «ф топку». Посмотрите кто ей занимается – тестировщики. В самом названии их профессии написано что они должны делать, а они в автоматизаторы хотят. Для многих из них это всего лишь утопическая мечта «сидеть и смотреть, как одна программа тестирует другую», и хотят они заниматься ей либо из-за незнания того, что их там ждет дальше, либо из-за того что они просто ошиблись в начале пути и пошли в тестирование вместо программирования.
Много раз на интервью встречал кандидатов, которые с огоньком в глазах говорили, что хотят стать автоматизаторами. Но при этом никогда не программировали, и никогда не видели автоматизацию в лицо. Всегда хотелось протрезвить их и навсегда отбить желание даже думать о ней. Идешь в тестирование – занимайся тестированием.
А вы, программисты-тестировщики, занимаетесь не тестированием, а фреймворки строчите один за другим. А кому они нужны? Как часто вы их меняете, работая на одном проекте, в одной компании? Вы не осознавая поднимаете планку автоматизации так высоко, что потом сложно найти кого-то кто бы мог поддерживать ваш код. Хотите программировать, идите работать программистами.
Заказчикам же не важно, автоматически вы тестируете или руками. Им важна стоимость проекта, которая будет зависеть от многих факторов, таких как инфраструктура, ресурсы привлекаемые для разработки, потраченное время, качество конечного продукта, скорость разработки.
Постараюсь сейчас разложить по полочкам основные факторы, и то как внедрение автоматизации влияет на их конечную стоимость.

Инфраструктура

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

Ресурсы

Проблему ресурсов можно рассмотреть с двух сторон:

1. На рынке проще найти ручного тестировщика, чем автоматизатора, а если вам нужен автоматизатор со специфическим опытом (инструмент, фреймворк, язык программирования), то это может стать проблемой.
2. Автоматизаторы как правило обходятся дороже ручных тестировщиков. Таким образом стоимость проекта вырастет, если к нему привлечь автоматизаторов. (При этом не факт, что они окажутся хорошими тестировщиками)

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

Время

Время разработки проекта увеличивается с внедрением автоматизации. И вот почему:

• Начиная проект с автоматизацией тестирования, вы должны осознавать, что автоматизация как таковая – это программный продукт. Получается, что на выходе у вас будет не одно, а два приложения. Первое будет делать то, что просил заказчик, второе – тестировать первое. В принципе, без второго первое работает так же как и работало, возникает резонный вопрос зачем оно надо, ведь его надо будет постоянно дорабатывать параллельно с изменениями в основном приложении, что будет требовать больше времени при поддержке.
• При использовании автоматизации требуется больше времени на разработку каждой отдельной функции (feature), так как в проектной команде у тестировщиков появляется еще одна активность помимо написания тест кейсов и тестирования – это автоматизация: разработка и поддержка фреймворков, написание, дебаг, анализ результатов и поддержка тестов (не говоря уже об интеграции с CI). Как следствие - стоимость рвется вверх.
• Также, возвращаясь к проблеме ресурсов, в случае необходимости найти замену, у вас появятся риски, задержки в разработке, так как нового человека надо найти, ввести в курс дела, дать время изучить имеющуюся автоматизацию и подождать, пока он начнет продуктивно работать, что отнимет значительное количество времени.

Качество конечного продукта

Пользователи всегда будут находить баги, использовали вы автоматизацию или нет.
Тут кто-то скажет, что с автоматизацией он патч быстрее выдаст, так как автотесты быстрее пробегут, чем тестирование ручками. Спорно (тест может упасть, на его починку может понадобиться время, не факт что не придется еще что-то и в фреймворке менять, что потребует перезапуск большего количества тестов), возможно («Раз в год и палка стреляет»), однако при грамотном анализе влияния изменений (Change Impact Analysis), руками может выйти даже быстрее.
Они не угомонятся и скажут: «А что делать с проверкой на разных конфигурациях?». Ответ будет: «Тоже самое, что и с одной конфигурацией. Анализируем, где что может не работать, проводим тест на всего на одной конфигурации, а остальные проверяем исходя из результатов анализа». Риски пропустить баг будут всегда, автоматизация нам тут никак не помогает, а иногда дает ложную уверенность в отсутствии багов.
Вывод: автоматизация на качество не особо влияет. Тем более, что некоторые вещи никак не проверить автоматически, например: удобство пользования (а клиент зачастую именно на это и смотрит). Вот пользователи клиента уже потом начинают придираться ко всему, то цифра не та, то кнопка запала, то статус неверный. И что? Делаем патч релиз, все равно он был бы.

Скорость разработки

Разрабатывать проекты можно быстро, а можно медленно. Иногда скорость – это основной критерий заказчика, который позволит ему первым выйти на рынок, а иногда важнее качество. Поэтому рассмотрим наиболее распространенные требования заказчиков к скорости реализации проекта.

1. Наиболее быстрый и распространенный способ: «Хуяк, хуяк и в продакшн!». Вы видите здесь автоматизацию? Я нет: «Беру, заверните». Заметьте и стоит не много – Good deal.
2. «Хочу быстро и качественно», - «Ручное тестирование тебе в помощь, мил человек.»
3. «Мне чтобы работало, и чтобы все были счастливы», - «Ооо, у нас есть автоматизация для вас». Работать в результате оно конечно же будет, а вот счастливы будут только исполнители – "втюхали" автоматизацию, подсадили на иглу и довольны.

В автоматизации есть только один «плюс», который еще пока никто не смеет превратить в «минус». Быстрый прогон регрессионных тестов. Однако, тут в голову приходит народная мудрость «Поспешишь, людей насмешишь». Да мы быстро гоняем регрессионные тесты, но сколько времени, сил и денег, тратим на то, чтобы они гонялись более менее стабильно? Закрыли глаза на день, а завтра опять что-то не так, неделя в отпуске, а там уже с десяток непонятных фейлов. И опять и снова в бой – «the never-ending story» или проще сказать «Сизифов труд».

Помните мультик «Крылья ноги и хвосты» и фразу «Лучше день потерять, а потом за 5 минут долететь»? Она как нельзя лучше характеризует автоматизированное тестирование.

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

Вывод

Автоматизация - это модно, поэтому сейлзы «вливают в уши», что без нее никак и никуда. А на самом деле им просто надо продать как можно больше сервисов и прокачать как можно больше ресурсов, сидящих на скамейке и получающим ЗП за простой. Конторам выгодно за счет заказчика обучать на реальных проектах своих сотрудников, вот они и втюхивают вам сервис выгодный им, зачастую продавая под видом работников уровня «PRO», людей уровнем «NULL», в лучшем случае – «So So». И что потом? Эти товарищи, прокачавшись за ваши деньги деньги, уходят на другой проект или в другую контору и вам дают опять кота в мешке, мол вот вам новый перспективный сотрудник.
Не верьте сейлзам - покупайте ручное тестирование! Заставляйте разработчиков писать тонны модульных и интеграционных тестов, а тестировщиков – документировать тест планы и тест кейсы, и тестировать готовый продукт руками. Ничто не ускользнет от зоркого глаза тестировщика, а то что ускользнет от него, автотест пропустил бы и подавно. А на сэкономленные деньги закажите лучше у сторонней компании аудит проделанной работы.
Поэтому, уважаемый заказчик, не покупайся на сладкие обещания сейлзов, когда вам предлагают автоматизацию функционального тестирования на проекте, которая уменьшит его стоимость и увеличит качество.

«Все лгут» (с) Доктор Хаус.

Лично я за свою карьеру, видел немало больших проекта, которые отказывались от автоматизации, когда состав первоначальной команды начинал меняться, изменения в продукте требовали практически полной переписки имеющейся автоматизации, а также стоимость её поддержки значительно возрастала (например: 1 час баг фикс + 3 часа на изменение, отладку и проверку автотестов, и это не включая времени на само тестирование).

Заключение

Автоматизация, о которой я говорил, – это раздутый мыльный пузырь, который лопнет, как только люди, в конце концов осознают, что она не дает вам особых преимуществ. Единственное, что полезного я в ней вижу, так это образование новых рабочих мест на IT рынке, что может и не плохо для мировой экономики и для автоматизаторов в целом, но для каждого отдельного заказчика, попавшего на её удочку, это дополнительные лишние расходы.
Обращаясь же к тестировщикам желающим автоматизировать, хочу сказать, что полезнее заняться автоматизацией рутинных рабочих процессов, а не самого тестирования. Что это значит? А вот что:

1. Используйте удобные тест менеджмент системы и инструменты, которые, например, могут генерировать вам тест план или при прохождении тест кейса могут автоматически сгенерировать баг репорт, или же при изменении в требованиях покажут какие тест кейсы надо обновить и т.д.
2. Хотите программировать? Пишите хелперы, для генерации тестовых данных, анализа логов приложения, скрипты для соединения с серверами, установке приложения на разные виртуалки, для выгребания данных из БД и т.д.

Короче, автоматизируйте рутинные операции, а не ту часть работы, ради которой вас брали на проект.
Да прибудет со всеми нами Сила.