Данные из 140вакансий · 12 августа 2026

Как стать инженером по автоматизации тестирования: путь от нуля до первого оффера

Не «стань разработчиком за 3 месяца» — реальный путь входа на основе данных по 140 вакансий.

Мурадов ЮрийАвтор·Мурадов Юрий·Аналитик SkillStat
БАПроверено·Баранцев Алексей·Технический редактор·эксперт по тестированию ПО
Junior-вакансий сейчас
9
6% от всех 140 вакансий
Сложность входа
Высокая
6% junior-вакансий
Senior / Junior+Intern
5.1x
На каждого junior+intern — 5.1 senior
Навыков / вакансия
13
медиана по вакансиям
Всего вакансий
140
активных в Москве
Можно ли с нуля Короткий план Roadmap Junior-рынок Портфолио Резюме Собеседование Ошибки Обучение FAQ

Можно ли стать инженером по автоматизации тестирования с нуля

Да. По данным SkillStat, 6% вакансий инженера по автоматизации тестирования — уровня junior или стажёр. Это 9 вакансий прямо сейчас.

«С нуля» у инженера по автоматизации тестирования почти никогда не значит «из ниоткуда». Обычная траектория — год ручного тестирования, потом код: тест-дизайн уже в голове, остаётся научиться выражать его программой. Прямой вход возможен, но требования собраны как у разработчика — язык, Git, SQL, CI/CD, Docker — плюс то, чего у разработчика нет: понимание, где продукт ломается. Медиана требований в вакансии — 13 навыков.

Трудность входа не в синтаксисе. Автотест пишется за час, а живёт годами, и всё это время кто-то разбирает его падения. Junior-позиций 9 из 140, на одного новичка приходится 5.1 senior-вакансии: команде дешевле нанять того, кто сразу отличает баг продукта от бага теста, чем чинить набор, который краснеет через раз. Платят за доверие к отчёту, а не за строчки кода.

Как стать инженером по автоматизации тестирования: короткий план

Пять шагов от первой проверки на pytest до набора, отчёту которого команда верит.

01
Тест-дизайн
Порядок обратный интуиции: сначала умение отобрать проверки, потом код. Автотест без тест-дизайна повторяет клики и краснеет не там, где ломается продукт.
02
Язык и фреймворк
Python — в 52.1% вакансий инженера по автоматизации тестирования, Java — в 35%. Один язык, дальше pytest (30%): фикстуры, параметризация, читаемые проверки.
03
API и данные
REST — в 47.9% вакансий, SQL — в 50%. Начинай с API-тестов: они быстрее, стабильнее и ловят больше, чем браузерный сценарий.
04
UI и окружение
Playwright (28.6%) или Selenium (29.3%), Docker (37.9%) для повторяемого стенда. Ожидание — по состоянию, а не по таймауту.
05
Пайплайн и отчёт
CI/CD — в 51.4% вакансий, GitLab CI — в 22.1%, Allure — в 25.7%. Тест, который гоняется только на твоём ноутбуке, работой не считается.

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

Не всё сразу. Вот очерёдность по частотности в вакансиях — от самого нужного к менее срочному.

Навык Все вакансии
Python 52.1%
CI/CD 51.4%
SQL 50%
REST 47.9%
Git 47.9%
Docker 37.9%
Java 35%
GitLab 34.3%
pytest 30%
Jenkins 30%

«Все вакансии» — доля из 140 вакансий. Обновлено 12 августа 2026.

Полный список навыков с частотностью, связками и зарплатной премией — навыки инженера по автоматизации тестирования →

Roadmap инженера по автоматизации тестирования: от нуля до junior

Порядок опирается на частотность навыков по данным вакансий. Первые 4–5 этапов — минимум для первого оффера.

  1. 01
    Основы тестирования

    Виды тестирования, тест-дизайн, тест-кейсы, баг-репорты — фундамент профессии.

  2. 02
    SQL 50% вакансий

    Проверка данных на уровне БД — без этого нельзя полноценно тестировать backend.

    Подробнее →
  3. 03
    API-тестирование

    HTTP/REST, Postman, Swagger — тестирование backend-интерфейсов.

    Подробнее →
  4. 04
    Баг-трекинг и документирование 23.6% вакансий

    Jira, Confluence, TestRail — работа с задачами и тестовой документацией.

    Подробнее →
  5. 05
    Автоматизация тестирования 29.3% вакансий

    Selenium, Playwright, PyTest — автоматизация регрессионных и e2e-тестов.

    Подробнее →
  6. 06
    CI/CD для тестов 22.1% вакансий middle+

    Интеграция тестов в пайплайн: запуск по PR, репорты, артефакты.

    Подробнее →
  7. 07
    Нагрузочное и безопасность middle+

    JMeter, k6, OWASP — производительность и базовые знания ИБ.

Junior-вакансии инженера по автоматизации тестирования: что реально требуют работодатели

Срез построен на 140 активных вакансий.

Junior-вакансий
9
inc. стажировки
Доля junior
6%
от всего рынка
Senior / Junior+Intern
5.1x
соотношение
Навыков / вакансия
13
медиана
Распределение вакансий по грейдам
Intern — 0.9% (1)
Junior — 7.1% (8)
Middle — 37.5% (42)
Senior — 41.1% (46)
Lead — 13.4% (15)
Что значат эти цифры. 9 вакансий уровня junior из 140 — вход конкурентный. Рынок здесь устроен иначе, чем в ручном тестировании: автоматизацию заводят там, где регрессия уже болит, то есть в зрелых командах, а зрелая команда не хочет учить новичка на своём наборе тестов. Отсюда и перекос в сторону опытных. Практический вывод: короткий путь — не отклики на junior-позиции, а ручное тестирование в команде, где автоматизация уже есть, и переход внутрь.

Какие проекты сделать для портфолио

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

Набор API-тестов с отчётом о прогоне
Средняя · 1–2 недели
Стек: Python, pytest, REST, Allure
GitHub: Репозиторий: фикстуры, параметризация негативных сценариев, отчёт Allure в артефактах, README с одной командой запуска
Ценность: Главный артефакт: pytest — в 30% вакансий, Allure — в 25.7%
UI-набор на Playwright
Средняя · 2 недели
Стек: Playwright, Python, Docker
GitHub: Тесты со скриншотами и трейсами при падении, стенд поднимается через Docker Compose
Ценность: Playwright — в 28.6% вакансий инженера по автоматизации тестирования: показывает работу с ожиданиями и состоянием
Прогон в пайплайне
Средняя · 3–5 дней
Стек: GitLab CI, CI/CD, Git
GitHub: Файл пайплайна, артефакты прогона, отчёт по ссылке, статус сборки в README
Ценность: CI/CD — в 51.4% вакансий: тест вне пайплайна релиз не защищает
Разбор хрупкого теста: было и стало
Лёгкая–средняя · 3–5 дней
Стек: Playwright, pytest, Git
GitHub: Два коммита и абзац в README: почему тест падал через раз и что заменило ожидание по таймауту
Ценность: Тот самый навык, за который платят: отличить баг продукта от бага теста
Проверка данных за интерфейсом
Средняя · 1 неделя
Стек: SQL, PostgreSQL, Python
GitHub: Тесты, которые после запроса к API сверяют состояние в базе, и фикстура очистки данных
Ценность: SQL — в 50% вакансий инженера по автоматизации тестирования, самый частый навык профессии

Как оформить GitHub и резюме

Профиль GitHub
  • Pinned repositories: 2–3 своих тестовых проекта, а не форки курсовых репозиториев
  • README с одной командой запуска: если проект не поднимается за пять минут, его закроют
  • Отчёт Allure выложи статикой по ссылке — смотрящий не станет разворачивать твой стенд ради картинки
  • Стенд и тестовые данные — в Docker Compose рядом с тестами: повторяемость и есть предмет профессии
  • Читаемая история коммитов: по ней видно, как ты чинил хрупкий тест, а не только «add tests»
  • В README каждого набора: какой риск закрывает, почему этот уровень проверки, что делать при красном прогоне
Резюме без коммерческого опыта
  • Раздел «Проекты» вместо «Опыт работы»: репозиторий с тестами описывается как рабочая задача
  • По каждому проекту: что проверяется, на каком уровне, чем поднимается стенд, где смотреть отчёт
  • Навыки — только рабочие: Python, CI/CD. «Знаком с Playwright» без репозитория читается как ноль
  • Опыт ручного тестирования — не балласт, а половина ценности: напиши, какие сценарии отбирал и почему именно их
  • Числа про набор говорят громче списка инструментов: сколько тестов, сколько идёт прогон, как часто он падал ложно
Слабое резюме

«Изучил Python и Selenium, писал автотесты, знаком с CI/CD и Docker»

Сильное резюме

«Собрал набор из 60 API-тестов на pytest для сервиса заказов: фикстуры с очисткой данных, параметризация негативных сценариев, сверка состояния в PostgreSQL. Прогон в GitLab CI на каждое слияние, отчёт Allure в артефактах — 4 минуты вместо часа ручной регрессии. Заменил ожидания по таймауту на ожидание состояния, ложные падения ушли. GitHub: [ссылка]»

Самостоятельно, курсы или вуз — какой путь выбрать

Самостоятельно
Язык, pytest, Playwright и Docker закрываются по документации, а тренироваться можно на любом публичном API
Никто не покажет, что твой тест хрупкий: это выясняется только на длинной дистанции регулярных прогонов
Если уже работаешь в ручном тестировании: рядом живой продукт, известны больные сценарии и есть кому показать код
Курсы с ментором
Ревью тестового кода — единственное, что реально ускоряет: хрупкость видна чужим глазом, не своим
Дорого; часть программ учит писать тесты и молчит про данные, окружение и разбор падений — то есть про бо́льшую часть работы
Если входишь без опыта тестирования: сам не поймёшь, какой сценарий стоит кода
Вуз / колледж
Программирование, базы данных, сети, Linux — база, на которой автоматизация строится без пробелов
Четыре года; тестированию там не учат вообще, тест-дизайн придётся закрывать отдельно
Если выбираешь первое образование и держишь разработку как запасной вариант
Ловушка автоматизации: курс учит инструменту, работа требует решения. К концу программы ты умеешь написать тест на Playwright — и не умеешь ответить, надо ли его писать. Команде не нужен ещё один браузерный сценарий там, где хватило запроса к API: он в разы медленнее и падает от любой перерисовки кнопки. Проверяй программу по одному признаку: разбирают ли там выбор уровня проверки и причины падений или только синтаксис.

Что спрашивают на собеседовании

Выбор сценариев и уровней
Типовые вопросы
  • ·Почему этот сценарий в UI, а не в API
  • ·Что не надо автоматизировать
  • ·Пирамида тестирования — где она врёт
  • ·Регрессия идёт час, надо десять минут — твои действия
Как показать проектом

Репозиторий: объясни, почему часть проверок осталась ручными

Код и фреймворк
Типовые вопросы
  • ·Фикстуры в pytest: области видимости и очистка данных
  • ·Как параметризовать негативные сценарии
  • ·Где хранить тестовые данные
  • ·Как вынести повторяющийся код, не убив читаемость теста
Как показать проектом

Набор API-тестов: покажи фикстуру подготовки и очистки

Хрупкие тесты
Типовые вопросы
  • ·Тест падает через раз — с чего начинаешь
  • ·Чем ожидание состояния лучше ожидания по таймауту
  • ·Как отличить баг продукта от бага теста
  • ·Тесты зависят от порядка запуска — что не так
Как показать проектом

Разбор хрупкого теста: покажи коммит до и после

Пайплайн и отчёты
Типовые вопросы
  • ·Как запускаешь набор в GitLab CI
  • ·Что кладёшь в артефакты прогона
  • ·Прогон красный каждое утро — что делаешь
  • ·Зачем Allure, если есть вывод в консоль
Как показать проектом

Пайплайн из портфолио: покажи артефакты и отчёт

Данные и окружение
Типовые вопросы
  • ·Как поднимаешь стенд в Docker
  • ·Как проверить побочный эффект в PostgreSQL после запроса к API
  • ·Что делать с тестами, которые пишут в общую базу
  • ·Зачем набору параллельный запуск и что он ломает
Как показать проектом

Docker Compose из проекта: покажи, как готовятся данные

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

Минимум
5–8 мес
Из ручного тестирования: тест-дизайн уже есть, добавляются язык, Git, фреймворк и пайплайн
Медиана
15–20 мес
С нуля, самостоятельно, по 2–3 часа в день: сначала ручное тестирование, потом код
Реалистично
20–28 мес
При совмещении с работой и без команды, где можно увидеть живой набор тестов

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

Скорость решают три вещи: есть ли рядом продукт с живой регрессией; гоняется ли твой набор регулярно (без регулярных прогонов хрупкость не проявляется); показывает ли кто-то твой тестовый код на ревью.

Ошибки новичков

Хрупкие тесты и ожидания по таймауту

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

Как исправить: Ожидание состояния, а не времени: ждать появления элемента, статуса в ответе, записи в базе. Каждое падение разбирать до причины, а не перезапускать

Автоматизируют то, что легко, а не то, что рискованно

Почему мешает: Двести проверок формы регистрации и ноль проверок оплаты. Красивая цифра покрытия — и дефект там, где поломка стоит денег

Как исправить: Начинай с вопроса: где поломка дорого обходится. Оплата, права, расчёты, интеграции — туда код, остальное чек-листом

Пишут e2e там, где хватило API

Почему мешает: Браузерный сценарий в разы медленнее запроса и ломается от любой перерисовки кнопки. REST — в 47.9% вакансий инженера по автоматизации тестирования не случайно: проверка логики дешевле на уровне API

Как исправить: Правило простое: UI-тест — только там, где проверяется именно интерфейс. Всё остальное — уровнем ниже

Тесты зависят от вчерашнего запуска

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

Как исправить: Каждый тест готовит свои данные и убирает за собой. Стенд — в Docker (37.9% вакансий), а не один общий на всю команду

Набор гоняется только локально

Почему мешает: CI/CD — в 51.4% вакансий инженера по автоматизации тестирования, GitLab CI — в 22.1%, Jenkins — в 30%. Тест, который никто не запускает автоматически, релиз не защищает — он украшает репозиторий

Как исправить: Пайплайн на каждое слияние, артефакты, отчёт по ссылке. Это первое, что смотрят в портфолио

Отчёт — красная галка без причины

Почему мешает: Allure — в 25.7% вакансий, и нужен он не ради картинки. Если по падению нельзя понять, кто чинит, разбор целиком ложится на автора теста и съедает его время

Как исправить: В отчёт — шаги, запрос и ответ, скриншот, трейс, лог. Цель: разработчик понимает причину, не открывая твой код

Не отличают баг продукта от бага теста

Почему мешает: Каждое красное падение объявляется дефектом, разработчики теряют доверие к набору и начинают его игнорировать — вместе с настоящими дефектами

Как исправить: Перед заведением задачи воспроизведи руками. Не воспроизвелось — чини тест, данные или ожидание

Учат инструмент вместо тест-дизайна

Почему мешает: Playwright изучается за две недели. Умение отобрать проверки — нет, и именно оно отделяет инженера от переписчика кликов в код

Как исправить: Тест-дизайн первым, инструмент вторым. Пришёл не из ручного тестирования — начни с него

Как SkillStat считает данные

Источник: 140 вакансий в московском сегменте. Навыки и грейды извлекаются автоматически из текста каждой вакансии.

Грейды: определяются по требованиям вакансии — уровню опыта, упоминанию «junior», «intern», «стажёр». Это рыночная оценка объявления.

Сложность входа: рассчитывается по доле junior-вакансий и медиане навыков на junior-уровне. Это индикатор, а не гарантия.

Обновление: данные пересчитываются регулярно. Текущий срез — 12 августа 2026.

Частые вопросы

Можно ли стать инженером по автоматизации тестирования с нуля?
Можно, но прямой путь длиннее обходного. Junior-позиций 9 из 140, а требования собраны как у разработчика: язык, Git, SQL, CI/CD, Docker. Обычная траектория — год ручного тестирования и переход внутри компании: тест-дизайн уже есть, добавляется код. Так устроен рынок: автоматизацию заводят зрелые команды, а они не хотят учить новичка на своём наборе.
Чем QA Automation отличается от ручного тестировщика?
Предметом решения. Ручной тестировщик решает, что проверить. Инженер по автоматизации решает, что из этого стоит кода: сценарий, который гоняется каждый релиз и ломается дорого, — да; разовая проверка нового экрана — нет. Стек тоже другой: здесь на первом месте SQL (50% вакансий), CI/CD (51.4%) и язык программирования — Python в 52.1% вакансий. Автоматизация не заменяет ручное тестирование, а снимает с него повторяемое.
Какой язык выбрать: Python или Java?
Оба живые: Python — в 52.1% вакансий инженера по автоматизации тестирования (73 из 140), Java — в 35%. Python быстрее в освоении и идёт в паре с pytest (30%); Java чаще там, где продукт написан на Java и тесты живут рядом с кодом. Выбирай по языку команды, в которую целишься, — переучиваться потом дешевле, чем кажется.
Playwright или Selenium?
Playwright — в 28.6% вакансий инженера по автоматизации тестирования, Selenium — в 29.3%. Playwright новее и берёт на себя ожидания, трейсы и запись экрана — с ним меньше хрупкости из коробки. Selenium — большой унаследованный парк тестов, который кто-то поддерживает. Для портфолио бери Playwright, но не удивляйся Selenium на работе.
Нужен ли SQL инженеру по автоматизации?
Да, это самый частый навык профессии: 50% вакансий (70 из 140), PostgreSQL — в 22.1%. Нужен для двух вещей: подготовить тестовые данные и проверить побочный эффект — что запрос к API реально записал в базу. Тест, который верит только ответу сервиса, проверяет половину.
Нужен ли Docker?
Да. Docker — в 37.9% вакансий инженера по автоматизации тестирования (53 из 140). Смысл — повторяемость: стенд поднимается одинаково у тебя, у коллеги и в пайплайне. Для первого оффера хватает уметь поднять зависимости через Docker Compose и объяснить, зачем это тестам.
Зачем нужен Allure?
Allure — в 25.7% вакансий инженера по автоматизации тестирования. Отчёт нужен не для красоты: по падению должно быть понятно, что чинить, без чтения твоего кода. Шаги, запрос и ответ, скриншот, трейс, лог — и разбор берёт на себя тот, чья это зона, а не автор теста.
Нужен ли CI/CD?
Обязателен: CI/CD — в 51.4% вакансий инженера по автоматизации тестирования, GitLab CI — в 22.1%, Jenkins — в 30%. Набор, который запускают руками, релиз не защищает. Минимум для входа — пайплайн, который гоняет тесты на каждое слияние и складывает отчёт в артефакты.
Нужны ли Kubernetes и Kafka?
Не для входа. Kubernetes — в 23.6% вакансий инженера по автоматизации тестирования, Kafka — в 25.7%, Microservices — в 25.7%: это описание продукта, а не входной билет. Начинать обучение с Kubernetes — потеря времени. Научат на месте, когда понадобится проверить сообщение в очереди.
Что такое хрупкий тест и почему это главная боль профессии?
Тест, который падает через раз без изменений в продукте: ожидание по времени вместо ожидания состояния, грязные данные от прошлого прогона, зависимость от порядка запуска, тормозящий стенд. Опасность не в самом падении, а в привычке: команда привыкает к красному прогону и перестаёт его читать — вместе с настоящими дефектами. Разбор причины падения спрашивают почти на каждом собеседовании.
Что показать в портфолио?
Репозиторий с тестами и отчётом о прогоне, который поднимается одной командой. Используй ключевые навыки профессии: Python, CI/CD, SQL. Отдельная ценность — коммит «до и после» по хрупкому тесту: он показывает то, за что платят, а зелёный прогон — нет.
Сколько времени нужно, чтобы стать инженером по автоматизации тестирования?
Из ручного тестирования — 5–8 месяцев: тест-дизайн уже есть, добавляются язык, Git, фреймворк и пайплайн. С нуля, самостоятельно — 15–20 месяцев, и это честная медиана: половина срока уходит на ручное тестирование, без которого умение отбирать сценарии не появляется.
Когда начинать откликаться?
Когда набор гоняется в пайплайне, отчёт читаем без тебя и ты можешь объяснить, почему каждый тест на своём уровне. Прямо сейчас junior-позиций 9 вакансий — смотри параллельно гибридные вакансии «ручное плюс автоматизация» и переход внутри своей компании.
Что писать в резюме без коммерческого опыта?
Проекты как опыт: что проверяет набор, на каком уровне, чем поднимается стенд, где смотреть отчёт. Инструменты — только рабочие: Python, CI/CD. Опыт ручного тестирования выноси наверх: он объясняет, почему сценарии отобраны именно эти.
Сколько зарабатывает начинающий Инженер по автоматизации тестирования?
Ориентир для junior — 94 500–136 500 ₽ при медиане по профессии 210 000 ₽. Разбивка по грейдам и динамика — на странице зарплат инженера по автоматизации тестирования.
Где посмотреть навыки инженера по автоматизации тестирования?
На странице навыков инженера по автоматизации тестирования — частотность по 140 вакансий, разбивка по грейдам и связки инструментов.