Когда автоматизировать, а когда не стоит

Вопрос про автоматизацию задают даже тем, кто не пишет код: он проверяет экономическое мышление, а не знание фреймворков.

Автоматизация не находит новые дефекты — она дёшево повторяет уже придуманные проверки. Новое находит человек: исследовательское тестирование, тест-дизайн, здравый смысл.

Вопрос 1: «Что вы будете автоматизировать в первую очередь?»

Что на самом деле проверяет интервьюер

Умеете ли вы выбирать, а не автоматизировать «всё подряд, начиная с первого тест-кейса в списке».

Развёрнутый ответ

Кандидаты на автоматизацию:

  • Часто повторяемое: регрессия, smoke на каждой сборке — то, что прогоняется десятки раз.
  • Критичное для бизнеса: авторизация, оплата, оформление заказа. Цена пропуска дефекта максимальна.
  • Рутинное и монотонное: проверка сотни комбинаций расчётов, где человек ошибается от усталости.
  • Стабильное: функциональность, которая не переписывается каждый спринт.
  • Подготовка данных: создание пользователей, заказов, состояний — часто самая выгодная автоматизация, хотя это и не «тесты».

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

Считаем окупаемость

manual_min = 6 * 60    # ручной прогон регресса, минут
auto_min = 12          # прогон автотестов, минут
dev_hours = 80         # разработка автотестов, часов
runs_per_year = 40     # прогонов регресса в год

saved_per_run = (manual_min - auto_min) / 60
print("Экономия за один прогон, часов:", round(saved_per_run, 1))
print("Окупаемость после прогона №", round(dev_hours / saved_per_run, 1))
print("Экономия за год, часов:", round(saved_per_run * runs_per_year))

Вывод:

Экономия за один прогон, часов: 5.8
Окупаемость после прогона № 13.8
Экономия за год, часов: 232

Вывод, который стоит озвучить вслух: автотесты окупаются примерно с четырнадцатого прогона. Если релиз раз в полгода, а функциональность переписывается каждый квартал, автоматизация этого набора убыточна — и грамотный тестировщик скажет об этом прямо. В модель, кстати, нужно добавить стоимость поддержки: в реальности она съедает от 10 до 30% времени разработки тестов ежегодно.

Вопрос 2: «Может ли автоматизация полностью заменить ручное тестирование?»

Что на самом деле проверяет интервьюер

Не повторяете ли вы маркетинговый лозунг. Правильный ответ — уверенное «нет», с аргументами.

Развёрнутый ответ

Автотест проверяет ровно то, что в него заложили. Он не удивится странной формулировке, не заметит, что кнопка уехала на 200 пикселей, если проверка идёт по локатору, и не задаст вопрос «а зачем эта фича вообще нужна». Автоматизация — это регрессионная страховка и ускорение обратной связи, а не источник новых находок.

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

Полезно добавить про пирамиду и стоимость уровня: если автоматизировать всё через UI, поддержка съест выгоду — сначала автоматизируют API и unit, а через интерфейс оставляют ключевые сквозные сценарии.

Типичные ошибки кандидатов

  • Говорят «автоматизировать надо всё» — и не могут ответить, кто будет поддерживать эти тесты через год.
  • Считают целью «100% покрытие автотестами». Метрика бессмысленна: важен не процент, а покрытие рисков.
  • Забывают про стоимость поддержки и про то, что автотест — это тоже код с собственными багами.
  • Автоматизируют нестабильный интерфейс на стадии редизайна и потом переписывают тесты каждый спринт.
  • Обещают заменить ручное тестирование автоматизацией.

Как ответить кратко

В первую очередь автоматизирую то, что часто повторяется и критично для бизнеса: smoke, регрессию, авторизацию, оплату, а также подготовку тестовых данных. Не автоматизирую нестабильный интерфейс в разработке, одноразовые проверки, юзабилити и сценарии с капчей. Решение принимаю по окупаемости: если ручной прогон занимает шесть часов, автоматический — двенадцать минут, а разработка стоила восемьдесят часов, набор окупится примерно к четырнадцатому прогону; плюс закладываю 10–30% времени в год на поддержку. Полностью заменить ручное тестирование автоматизация не может: автотест проверяет только заложенное и не находит нового — исследовательское тестирование, юзабилити и приёмка остаются за человеком.

Проверьте себя
1. Какой набор проверок автоматизировать выгоднее всего?
AЮзабилити-проверки нового интерфейса на стадии редизайна
BРегрессионный набор по стабильной критичной функциональности, который гоняется каждый релиз
CОдноразовую проверку миграции данных перед разовым переездом
DСценарии с капчей и ручной подписью документа
2. Ручной прогон регресса занимает 6 часов, автоматический — 12 минут, разработка автотестов заняла 80 часов. Что это означает?
AАвтоматизация окупится примерно после четырнадцатого прогона, и при редких релизах может быть невыгодной
BАвтоматизация окупается сразу после первого прогона
CОкупаемость не считается — автоматизировать нужно всегда
DАвтоматизация никогда не окупится
3. Почему автоматизация не заменяет ручное тестирование полностью?
AПотому что автотесты работают медленнее человека
BПотому что автотест проверяет только заложенные в него ожидания и не находит новых, неожиданных проблем
CПотому что автотесты нельзя запускать в CI
DПотому что автоматизация применима только к API