← назад к разделу

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

два вопроса к проверке — и она сама встаёт в свой квадрант стоимость поддержки дорого чинить дёшево чинить редко часто частота прогона регресс оплатысюда первый автотест форма заказа в UIсначала стабилизировать отчёт раз в кварталвыгода мелкая разовая миграцияпроверяем руками

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

Обязательно

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

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

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

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

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

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

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

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

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

живой пример

наборы = [(1000, 300, 300), (1000, 800, 500), (999, 400, 400), (500, 0, 0)]
for сумма, баланс, ожидаем in наборы:
    списано = min(баланс, сумма // 2)
    print(сумма, баланс, списано, "OK" if списано == ожидаем else "FAIL")
Запустить

Запуск примеров доступен в платном доступе. Там этот же код выполняется прямо в статье: редактор, запуск и проверка рядом с абзацем. Три дня бесплатно →

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

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

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

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

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

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

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

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

Глубже: BDD и Cucumber, TDD и сдвиг влеворасширенноеспросят на собеседовании

Три слова, которые встречаются в вакансиях рядом с автоматизацией. BDD, разработка через поведение, это способ описывать проверки на языке, понятном заказчику: «Дано: в корзине товар за 1000; Когда: применяю промокод; Тогда: итог 900». Такие сценарии пишут на Gherkin, а Cucumber или Behave превращают каждую строку в вызов кода автотеста. Польза в общем языке с аналитиком, цена в двойной работе: сценарий и код под него. Берут там, где заказчик читает тесты, и не берут ради красоты.

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

Сдвиг влево, shift-left, это перенос проверок на ранние стадии: ревью требований до кода, тесты вместе с разработкой, а не после, автотесты в конвейере на каждый коммит. Чем раньше найден баг, тем дешевле его починить, и вся первая фаза курса про это.

Коротко

  • Автоматизация — проект внутри проекта: выгода приходит с повторных прогонов, а не с первого.
  • Считают три числа: экономию на прогоне, число повторов, стоимость поддержки. Последнее недооценивают чаще всего.
  • Первыми автоматизируют то, что повторяется часто и меняется редко: регресс, дымовые прогоны, проверки без интерфейса.
  • Ступени лестницы чинят хрупкость предыдущей: частный скрипт → запись действий → данные снаружи → ключевые слова → фреймворки → given-when-then.
  • Кейс годится для автоматизации, когда ожидаемый результат проверяем машиной, а ожидание идёт по состоянию, не по секундам.
  • Ложноположительный тест хуже отсутствующего: зелёный на сломанном приложении, он прячет дефект.
  • BDD: сценарии «Дано, Когда, Тогда» на Gherkin, Cucumber связывает их с кодом; TDD: тест раньше кода у разработчика; сдвиг влево: проверки как можно раньше.

Что почитать дальше