Ручное и автоматизированное тестирование

«Давайте автоматизируем всё» звучит как хороший план ровно до того дня, когда автотесты начинают падать чаще, чем находить баги.

Автоматизация не заменяет тестирование. Она заменяет повторное выполнение уже придуманных проверок.

Это различие стоит осознать раньше всего остального. Автотест не тестирует — он воспроизводит чужую мысль. Кто-то сначала подумал, придумал проверку, сформулировал ожидаемый результат, и только потом это записали в код. Всё, чего не было в голове у автора, автотест не увидит никогда: у него зелёный статус, а страница отрендерилась белым квадратом — селектор-то нашёлся, текст-то совпал.

Чем они на самом деле отличаются

Вывод из таблицы простой: автоматизация выигрывает на повторении и проигрывает на новизне. Регрессия — её территория. Новая, ещё горячая фича — территория человека.

Что нельзя автоматизировать (или не нужно)

• Юзабилити. «Понятно ли пользователю, куда нажать» — не формализуется. Робот кликает по локатору, он не может запутаться.
• Исследовательское тестирование. Смысл в импровизации: дёрнуть систему туда, куда не предполагали. Автотест по определению не импровизирует.
• Визуальная эстетика. Скриншотные тесты частично закрывают вопрос «не поехало ли», но «красиво/некрасиво» и «уместно ли тут этот отступ» они не решают — зато шумят на каждом изменении шрифта.
• Одноразовые проверки. Проверить миграцию данных, которая случится один раз в жизни, — руками. Автотест окупается повторами; повторов не будет.
• Экраны, которые перекраивают каждую неделю. Автотест на такой фиче умирает быстрее, чем успевает найти первый баг. Ждите, пока интерфейс устоится.
• Капча, СМС-коды, оплата реальной картой, внешние системы без песочницы. Технически иногда можно, но обходные пути (отключить капчу на стенде, тестовые номера, sandbox платёжки) — это уже не тест боевого пути.
• Проверки без формализуемого ожидаемого результата. «Письмо выглядит нормально» — это не результат. «В письме есть номер заказа, сумма 4500 ₽ и ссылка вида /orders/{id}» — уже да.
• Железо. Печать чека на кассе, оплата по NFC, сканер штрихкодов, поведение при севшей батарее.

Критерии выбора кандидата

Перед тем как автоматизировать кейс, прогоните его по чек-листу. Каждый «да» — плюс балл.

ЧЕК-ЛИСТ КАНДИДАТА НА АВТОМАТИЗАЦИЮ
[ ] Проверка выполняется часто (каждый релиз, каждый деплой)
[ ] Функциональность устоялась, интерфейс не переделывают каждую неделю
[ ] Цена ошибки высока (деньги, данные, доступ, юридические последствия)
[ ] Ожидаемый результат однозначен и проверяем машиной
[ ] Руками это делать долго и/или скучно (много однотипных данных)
[ ] Есть доступ к API/базе для подготовки данных и очистки после теста
[ ] Есть стабильные локаторы (data-test-id), а не «третий div во втором span»
[ ] Тест можно прогнать на любом окружении и запустить параллельно

6-8 «да» — автоматизируем в первую очередь
3-5 «да» — в бэклог, вернёмся
0-2 «да» — оставляем ручным, и это нормально

Второй фильтр — арифметика. Автотест окупается, если суммарное ручное время за год больше, чем время на написание плюс поддержку. Посчитаем на трёх типичных кейсах.

cases = [
    ("Вход с валидными данными",        3, 250,  4, 2),
    ("Регистрация: 12 полей формы",    15,  50, 10, 4),
    ("Оценить вёрстку лендинга глазами", 20,   4, 12, 6),
]

for name, minutes, runs, dev_hours, support_hours in cases:
    manual = minutes * runs / 60          # часов ручных прогонов за год
    auto = dev_hours + support_hours      # часов на написание и поддержку
    print(f"{name}: руками {manual:.1f} ч/год, авто {auto:.1f} ч/год, выигрыш {manual - auto:+.1f} ч")

Результат:

Вход с валидными данными: руками 12.5 ч/год, авто 6.0 ч/год, выигрыш +6.5 ч
Регистрация: 12 полей формы: руками 12.5 ч/год, авто 14.0 ч/год, выигрыш -1.5 ч
Оценить вёрстку лендинга глазами: руками 1.3 ч/год, авто 18.0 ч/год, выигрыш -16.7 ч

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

Модель, конечно, грубая. Она не учитывает главного плюса автотеста — обратной связи за 3 минуты вместо трёх дней ручного регресса. Именно поэтому вход в систему автоматизируют даже когда цифры выходят почти в ноль: этот тест гоняется на каждом деплое и мгновенно ловит «всё сломалось».

Как это работает на проекте

Живая схема в большинстве команд выглядит так:

1. Новая фича проверяется руками. Она ещё меняется, автотест писать рано.
2. Фича устоялась и попала в регресс. Проверка повторилась второй-третий раз — вот теперь она кандидат в автоматизацию.
3. Смоук (10–20 самых критичных сценариев: вход, поиск, оформление, оплата) автоматизируется первым и гоняется на каждый деплой.
4. Регресс критичного пути автоматизируется дальше, по чек-листу выше.
5. Всё остальное остаётся ручным. И это не поражение: типично автоматизируют 20–40% кейсов, которые закрывают большую часть рутины.

Освободившееся время ручной тестировщик тратит не на безделье, а на то, что машина не умеет: исследовательские сессии, анализ требований до начала разработки (там самые дешёвые баги), тест-дизайн, разбор жалоб пользователей, проверку новых фич.

Миф: «автотесты заменят ручных тестировщиков»

Этот тезис живёт с начала двухтысячных и до сих пор не сбылся. Почему:

• Автотест — исполнитель, а не автор. Кто-то должен решить, что вообще проверять. Тест-дизайн — человеческая работа, и автоматизация её не касается.
• Автопарк требует ухода. 500 тестов — это отдельный программный продукт со своим кодом, багами и техдолгом. Сэкономленные часы частично уходят на его поддержку.
• Стопроцентной автоматизации не бывает. Если команда покрыла 70% регресса — это отличный результат. Оставшиеся 30% никуда не денутся.
• Самые дорогие баги — те, которых нет в кейсах. Их находят, когда человек «просто потыкал не туда»: ввёл эмодзи в имя, нажал «Назад» посреди оплаты, открыл приложение в самолётном режиме.

Что действительно происходит — профессия меняется. Исчезает не тестировщик, а «кликер по чек-листу»: специалист, который умеет только пройти 40 готовых шагов и поставить галочки. От современного ручного QA ждут работы с API (Postman), запросов к базе, чтения логов, понимания архитектуры и хотя бы базового умения написать и починить простой автотест. Эту планку можно взять — но её нужно осознанно брать.

Частые ошибки

• Автоматизировать нестабильную фичу «пока есть время». Через две недели дизайнер переставит блоки, и тест придётся выкинуть.
• Мерить успех числом тестов. KPI «50 автотестов за спринт» гарантированно порождает пятьдесят бесполезных тестов на то, что автоматизировать проще всего.
• Тестировать через UI то, что проверяется через API. Валидация полей, права доступа, коды ответов — всё это на API-уровне быстрее в десятки раз и не мигает.
• Терпеть flaky-тесты. Как только в команде появляется фраза «перезапусти, оно само пройдёт», доверие к набору начинает утекать.
• Не готовить тестовые данные. Тесты, которые зависят от того, что кто-то вручную создал пользователя на стенде, падают не из-за багов, а из-за среды — и обесценивают всю затею.
• Уволить ручное тестирование после автоматизации регресса. Регресс защищён, новые фичи — нет. Через полгода команда узнаёт о проблемах из отзывов в сторе.

Итоги

• Автоматизация закрывает повторное выполнение уже придуманных проверок; думать за вас она не будет.
• Хороший кандидат: частый, стабильный, с однозначным ожидаемым результатом и высокой ценой ошибки.
• Не автоматизируются: юзабилити, исследовательское тестирование, одноразовые проверки, капризные и часто меняющиеся экраны, железо, всё без формализуемого результата.
• Считайте окупаемость: время на написание и поддержку против сэкономленных ручных часов — плюс ценность быстрой обратной связи.
• Типичная доля автоматизации — 20–40% кейсов; 100% не бывает и не нужно.
• Автотесты не заменяют тестировщиков, но обесценивают чистых «кликеров»: без API, SQL, логов и базовой автоматизации сегодня тяжело.