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

Экономика: автоматизация — это инвестиция

Главное, что нужно понять: автоматизация — не волшебная кнопка, а проект внутри проекта, со своими требованиями, кодом и планами. В ручном тестировании основное время уходит на выполнение проверок; в автоматизированном картина переворачивается: долгая разработка и отладка тестов — и потом быстрые прогоны.

Отсюда простая логика окупаемости. Затраты на разработку и поддержку автотестов окупаются экономией на каждом прогоне — значит, выгода зависит от трёх вещей:

  • Сколько времени экономит один прогон — разница между ручным и автоматическим выполнением тех же проверок.
  • Сколько раз проверки будут повторяться. Типичная картина: автоматизация окупается не с первого прогона, а к десятому-пятнадцатому билду — и только дальше начинает приносить пользу.
  • Сколько стоит поддержка. Самый недооцениваемый пункт: при заметных изменениях требований или интерфейса тесты приходится переделывать, иногда — с нуля.

Поэтому автоматизация сильна там, где проверки повторяются часто и меняются редко: регрессия, дымовые прогоны на каждый билд, проверки без интерфейса (API, консольные утилиты), перебор больших наборов данных и конфигураций, нагрузка. И слаба там, где нужно думать или где повторов не будет: придумывание проверок, оценка удобства, разовые проверки, продукт с нестабильными требованиями. Два афоризма из практики: «автоматизация хаоса даёт автоматизированный хаос» — если ручной процесс не выстроен, автоматизировать нечего; и «лучше руками протестировать хоть что-то, чем автоматизированно — ничего» — в цейтноте автоматизация не спасает, она сначала только потребляет время.

Лестница подходов

Технологии автоматизации выстраиваются в лестницу — каждая ступень решает проблему предыдущей:

  • Частные решения. Отдельный скрипт под отдельную задачу. Быстро и просто, но «кустарно»: переиспользовать почти невозможно, понимает только автор.
  • Запись и воспроизведение (Record & Playback). Инструмент записывает действия тестировщика и умеет их повторять. Освоение за минуты — потому с этого часто начинают учиться. Но записанный тест линеен (ни условий, ни циклов), набит конкретными значениями и хрупок. Скелет теста — да; готовый тест — нет.
  • Тестирование под управлением данными (data-driven, DDT). Данные выносятся из кода теста наружу — в таблицу или файл. Один тест прогоняется на сотнях наборов входных значений; добавить проверку = добавить строку в таблицу.
  • Тестирование под управлением ключевыми словами (keyword-driven, KDT). Наружу выносятся не только данные, но и сами действия: «открыть», «заполнить», «проверить». Наполнять такие таблицы может человек без навыков программирования — это переломный момент, с которого нетехнические специалисты участвуют в автоматизации.
  • Фреймворки. Готовые конструкторы, объединяющие лучшее из предыдущих подходов: семейство xUnit для модульных тестов, Selenium/Playwright для веба. Мощно и гибко, но требует программирования и времени на изучение.
  • Тестирование под управлением поведением (BDD). Проверки описываются бизнес-сценариями по формуле given — when — then: «При условии, что пользователь авторизован; когда он добавляет товар в корзину; тогда счётчик корзины увеличивается на один». Такую запись читают и обсуждают все — заказчик, аналитик, тестировщик, — а инструменты вроде Cucumber превращают её в исполняемые тесты. Цена: высокоуровневые сценарии пропускают низкоуровневые детали, поэтому классические тесты они дополняют, а не заменяют.

Кейсы для автоматизации: что можете сделать вы

Автоматизируют чаще всего обычные тест-кейсы, написанные вручную. И вот тут ручной тестировщик прямо влияет на успех:

  • Предельно чёткий ожидаемый результат. «Загружается стандартная страница поиска» человеку понятно, машине — нет. Нужно: «заголовок = "Search page", есть поле ввода и кнопка "Go!"». Признаки корректности — конкретные и проверяемые.
  • Ожидание состояния вместо ожидания времени. Не «подождать 5 секунд и кликнуть», а «дождаться, пока список станет активным». Тесты, зависящие от таймингов, падают на исправном приложении — и подрывают доверие ко всей автоматизации.
  • Независимость кейсов — как и в ручных наборах, но жёстче: нельзя предполагать, какие тесты выполнятся до и после вашего.
  • Без привязки к инструменту и платформе. «Кликнуть и дождаться загрузки», а не команды конкретного инструмента в шагах кейса.

И самое опасное в автоматизации — ложноположительные тесты: тест зелёный, а приложение сломано. Классика — проверили не то свойство (чекбокс «доступен» вместо «отмечен») или вместо проверки значения случайно изменили его. Такой тест хуже отсутствующего: он прячет дефекты, внушая команде ложную уверенность.

Где это применяется

Даже на «ручной» позиции вы соприкасаетесь с автоматизацией ежедневно: читаете отчёты прогонов, разбираете упавшие тесты (баг или тест устарел?), пишете кейсы, которые потом автоматизируют. А принципы автоматизации применимы и вне тестов: скрипт, раскладывающий тестовые файлы, шаблон, генерирующий данные, — всё это экономит часы рутины без всяких фреймворков.

Где спотыкаются начинающие:

  • Меряют автоматизацию количеством тестов, а не тем, что они ловят. Сто ложноположительных тестов — это минус, а не плюс.
  • Верят, что Record & Playback — это и есть автоматизация. Это её детская ступень: записанное нужно превращать в поддерживаемый код.
  • Предлагают автоматизировать всё подряд, не спросив «сколько раз это будет повторяться?». Разовая проверка руками — быстрее и дешевле.

Что учить дальше. Куда двигаться, если автоматизация заинтересовала как направление, — в статье куда расти дальше; что именно выносят в автоматический регресс — в статьях про тест-план и качество кейсов; проверки API, с которых часто начинается автоматизация, — в статье про Postman.