Инженер по автоматизации тестирования: чем занимается, какие навыки нужны и как учиться

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

Чем занимается инженер по автоматизации тестирования

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

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

Заметная часть недели уходит на поддержку. Разработчики поменяли структуру страницы или добавили поле в форму — и десяток тестов краснеет, хотя продукт работает. Хороший тестовый код устроен так, чтобы правка вносилась в одном месте. Для этого применяют шаблоны вроде Page Object: описание страницы и её элементов выносят в отдельный класс, а сами тесты обращаются к нему.

Учебный пример: тест, который иногда падает

Ситуация учебная. В сервисе бронирования переговорных есть сквозной тест: пользователь входит в систему, выбирает дату в календаре, выбирает комнату и нажимает «Забронировать». Локально тест проходит всегда, а в CI падает примерно в одном запуске из десяти с ошибкой «элемент не найден». Разработчики уже привыкли перезапускать сборку.

Автоматизатор включает скриншоты или трассировку при падении и смотрит, на каком шаге споткнулся тест. Выясняется, что после выбора даты список комнат подгружается отдельным запросом, а на загруженной CI-машине ответ иногда приходит позже, чем тест пытается нажать на комнату. В коде стоит sleep(2): кто-то когда-то подобрал паузу, которой хватало на ноутбуке.

Жёсткая пауза плоха в обе стороны: если сервер ответил за 200 миллисекунд, тест всё равно ждёт две секунды, а если за три — падает. Правильнее ждать конкретного условия: появления нужного элемента или готовности к нажатию.

Здесь многих подводит устройство ожиданий в Selenium. В WebDriver есть неявное ожидание (implicit wait), которое действует на всю сессию, и явное (explicit wait), которое задаётся для конкретного условия. По документации Selenium неявное ожидание по умолчанию равно нулю: если элемента нет на странице в момент поиска, драйвер сразу возвращает ошибку. Там же прямо сказано, что смешивать два вида ожиданий нельзя: при неявном ожидании 10 секунд и явном 15 тайм-аут может наступить только через 20 секунд. Получается, что «на всякий случай» добавленное глобальное ожидание делает время падения непредсказуемым и маскирует настоящую причину. Документация рекомендует в большинстве случаев использовать явные ожидания.

Playwright решает ту же задачу иначе: перед нажатием он сам проверяет, что локатор указывает ровно на один элемент, элемент виден, не анимируется, не перекрыт другим и доступен для действий. Если условия не выполнились за отведённое время, действие завершается ошибкой TimeoutError (раздел Actionability в документации Playwright). Автоожидание не снимает вопрос синхронизации целиком, но избавляет от большинства ручных пауз.

В нашем примере автоматизатор убирает sleep, заменяет его ожиданием появления списка комнат и заодно замечает, что проверка стоимости брони тоже шла через браузер. Её он переносит на уровень API: запрос с параметрами, проверка ответа, без календаря и кликов. Сквозной тест становится короче, а сборка — стабильнее. Результат работы — не «починенный тест», а то, что красная сборка снова означает поломку продукта.

Пирамида тестов: что проверять на каком уровне

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

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

Нестабильные тесты (flaky) — отдельная тема. Некоторые фреймворки прямо выделяют их в отчётах: Playwright при включённых повторных запусках делит тесты на прошедшие, упавшие и нестабильные — те, что упали с первой попытки, но прошли при повторе (документация Playwright о повторных запусках). По умолчанию повторы выключены. Включить их легко, но если не разбирать список нестабильных тестов, повторы превращаются в способ спрятать проблему.

Какие знания и инструменты нужны

Основа — язык программирования на уровне поддерживаемого кода: функции, классы, коллекции, исключения, модули и зависимости. Выбор языка обычно следует за продуктом: в Python-проектах популярны pytest и Selenium или Playwright, в Java — JUnit или TestNG, Selenide, в JavaScript и TypeScript — Jest, Playwright, Cypress, WebdriverIO. Переходить между языками потом можно, но первый нужно освоить всерьёз.

Помимо языка понадобятся:

• HTTP и REST: методы, коды ответов, заголовки, формат JSON, работа с Postman и библиотеками для запросов;
• локаторы в браузере: CSS-селекторы, XPath, инструменты разработчика;
• SQL на уровне выборок с условиями и соединениями, чтобы готовить и проверять данные;
• Git: ветки, коммиты, пул-реквесты, код-ревью;
• CI-системы (GitHub Actions, GitLab CI, Jenkins) и Docker, чтобы тесты запускались одинаково на любой машине;
• отчётность, например Allure, чтобы по отчёту было понятно, что и где упало.

Чтобы представить, как эти темы складываются в программу, можно посмотреть обзор курса Skillbox «Инженер по автоматизации тестирования»: курс длится девять месяцев, на выбор Java, JavaScript или Python, Selenium WebDriver с CSS- и XPath-локаторами, Git, встраивание тестов в CI/CD и параллельный запуск, два проекта для портфолио. В обзоре отдельно отмечено, что программа рассчитана на тех, кто уже знаком с ручным тестированием, и не заменяет эту базу.

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

Чем профессия отличается от соседних

С тестировщиком ПО автоматизатора объединяет цель — найти проблемы до пользователя. Но тестировщик в первую очередь придумывает проверки и исследует продукт, а автоматизатор превращает устоявшиеся проверки в код и отвечает за его надёжность. Автотест проверяет только то, что в нём записано, поэтому новые сценарии и неожиданные ошибки по-прежнему находит человек. О ручном тестировании на сайте есть отдельная статья «Тестировщик ПО».

SDET (software development engineer in test) ближе к разработчику: он строит тестовые фреймворки, инструменты для генерации данных, иногда вносит правки в сам продукт ради тестируемости. Во многих компаниях граница размыта, и вакансия «QA automation» может означать и то, и другое — описание обязанностей важнее названия.

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

Что может оказаться трудным

Первое — объём программирования. Многие приходят из ручного тестирования, рассчитывая выучить пару команд Selenium, но тестовый код подчиняется тем же правилам, что и продуктовый: его читают на ревью и рефакторят. Второе — поддержка: написать тест интереснее, чем в пятый раз за месяц чинить десяток после редизайна. Если вам скучно разбирать логи CI и чужие изменения, работа будет утомлять.

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

С чего начать обучение

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

Первые шаги можно сделать бесплатно. Установите Python и pytest, напишите тесты для собственной функции, затем подключите Playwright или Selenium и автоматизируйте вход на учебный сайт для тренировки автотестов. Выложите код на GitHub и настройте GitHub Actions, чтобы тесты запускались при каждом коммите. Такой цикл «код — запуск — отчёт» уже показывает, нравится ли вам эта работа.

Возможность пройти обучение с нуля лучше проверять по программе, а не по рекламе. На курсе Хекслета «Автоматизатор тестирования на JavaScript» начинают с основ JavaScript, ООП и функционального программирования, затем идут модульные тесты на Jest, HTTP и тестирование API, Docker, CI в GitHub Actions и сквозные сценарии на Playwright; длительность — от шести до десяти месяцев в зависимости от тарифа. В обзоре оговорено, что порог входа выше, чем на курсах ручного тестирования, а тем, кто уже тестирует, будет проще.

Как показать первые результаты

Работодателю важно увидеть код. Портфолио автоматизатора — это репозиторий, в котором есть понятная структура проекта, README с инструкцией запуска, тесты разных уровней (API и немного UI), настроенный CI и отчёт о прогоне. Проверяющий откроет пару тестов и сразу увидит, есть ли в них жёсткие паузы, дублирование и хрупкие локаторы.

Хорошо, если проект тестирует не абстрактную страницу, а приложение с логикой: авторизацией, формами, API. Учебные проекты онлайн-курсов для этого подходят, если в них вы сами принимали решения, а не копировали шаблон. Например, на курсе Яндекс Практикума «Автоматизатор тестирования на Python» по обзору семь проектов: модульные тесты на pytest с параметризацией и фикстурами, UI-тесты на Selenium с шаблоном Page Object, отчёты Allure, тесты API, Docker и CI. Курс рассчитан на ручных тестировщиков, которые переходят в автоматизацию, а основы Python в нём даются с нуля.

Сколько зарабатывает инженер по автоматизации тестирования

Профессия наёмная, поэтому ориентир — зарплата. «Хабр Карьера» опубликовала данные по тестировщикам за первое полугодие 2026 года на основе анкет своего зарплатного калькулятора, то есть фактических зарплат, которые указали сами специалисты, а не предложений в вакансиях. Медианная зарплата инженеров по автоматизации тестирования по всей России: у джунов — 108 тысяч рублей в месяц, у мидлов — 197 тысяч, у сеньоров — 307 тысяч, у лидов — около 372 тысяч. У ручных тестировщиков тех же уровней медианы ниже: 83, 143 и около 221 тысячи рублей.

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

Первые профессиональные шаги и выбор обучения

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

Выбирая программу, проверьте, сколько в ней именно программирования, на каком языке, есть ли код-ревью от практикующих инженеров, настраивается ли CI и сколько проектов останется в портфолио. Сравнить школы по этим признакам поможет рейтинг онлайн-школ по тестированию и QA: он охватывает и ручное тестирование, и автоматизацию на разных языках, поэтому смотрите на конкретные программы по автоматизации. Если после первого самостоятельного теста на pytest или Playwright вам хочется разобраться, почему он иногда падает, — это хороший признак, что профессия вам подходит.