Автоматизатор тестирования — это не «ручной QA, который прошёл курс Selenium». Нанимают человека, который умеет выбрать, что автоматизировать, встроить прогон в поставку и не превратить пайплайн в красную стену из флаков. Курс с десятком UI-сценариев на демо-сайте этого не доказывает. Доказывает репозиторий, где тесты гоняются в CI, падения разбираются, а зона покрытия названа честно.

Ниже — путь из manual QA (и редкий вход без ручного контура): какой язык и стек выбрать, какой один проект закрывает сомнение, когда резюме уже можно подписывать automation, как не прыгать в SDET-вакансии с тремя месяцами практики. Два рабочих плана: 90 дней из ручного тестирования и вход для разработчика, который уходит в тест. Вакансии смотрите в каталоге automation QA, не в общей куче «тестировщик».

Коротко:

  • Сначала ручной контур и тестовый дизайн, потом код. Иначе вы пишете хрупкие клики без понимания риска.
  • Один язык (часто Python или Java/JavaScript под стек команды) плюс API-тесты важнее пяти фреймворков в резюме.
  • Артефакт: репозиторий с CI, отчётом, README «что покрыто / что нет / как гонять».
  • Не называйте себя SDET, пока нет поставки тестов в чужой пайплайн и разбора стабильности.
  • Резюме под эту роль собирайте отдельно: резюме автоматизатора QA.

Чем automation отличается от «написал UI-тесты»

Ручной QA отвечает на вопрос «сломалось ли». Автоматизатор — на вопрос «какой риск мы можем ловить на каждом коммите без человека». Это про приоритеты: критический путь, API контракта, регресс, который уже надоел. Это про инженерию: селекторы, данные, ожидания, изоляция, артефакты прогона. Это про продукт поставки: ночной прогон бесполезен, если красный билд все игнорируют.

Вакансии путают названия: QA Automation, AQA, SDET, Test Engineer. SDET чаще ближе к разработке тестовой платформы и коду на уровне продукта. Junior automation чаще = API + узкий UI-критический путь + CI. Читайте задачи, не титул. Вход в ручной QA, если его ещё нет: как стать QA-инженером. Карта навыков без культа инструментов: что должен знать QA.

Какой стек выбрать, чтобы не распылиться

Смотрите 15 живых вакансий под ваш рынок (СНГ remote / ваш город) в automation QA и соседнем QA. Выпишите языки и уровни: UI, API, мобилка, нагрузка. Выберите один основной язык так:

  • Команда на Java — Java + REST-assured / аналог, JUnit, пайплайн.
  • Команда на Python / много API — Python + pytest + requests/httpx, не обязательно сразу Playwright.
  • Фронт на JS/TS — TypeScript + Playwright часто стыкуется с разработкой.
  • Мобилка — отдельная ветка, не мешайте в первый квартал с вебом, если нет оффера под мобилку.

SQL почти всегда нужен: проверить данные после API, не только «статус 200». Postman как клики в GUI — не навык автоматизации; коллекции с тестами и выгрузкой в CI — уже ближе. Docker на уровне «поднять зависимости для прогона» полезен, Kubernetes на junior automation — редко обязателен. Roadmap языка, если берёте Python: Python roadmap. Контейнеры как гигиена: Docker roadmap.

Что собрать за 90 дней: один контур, не десять курсов

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

  1. Недели 1–3. Язык до уровня: функции, коллекции, исключения, чтение чужого теста. Параллельно: повторить тест-дизайн на одном учебном сервисе (регистрация, заказ, оплата). Без этого UI-автотесты будут случайными.
  2. Недели 4–6. API-тесты критического пути: создание сущности, негатив, идемпотентность если уместно, проверка поля в ответе и, если есть доступ, строки в БД. Это сильнее десяти UI-кликов.
  3. Недели 7–9. Узкий UI-слой: 3–7 сценариев на тот же сервис, Page Object или аналог, стабильные селекторы, без «sleep(5)» как архитектуры. CI: GitHub Actions / GitLab CI, артефакт отчёта, README.
  4. Недели 10–12. Стабильность: выкинуть флаки, пометить known issue, написать, чего нет (нагрузка, мобилка, визуальные регрессии). Короткое демо 5 минут: как упал тест, как вы это увидели в CI.

Если вы уже manual QA в штате — не копируйте учебный интернет-магазин. Автоматизируйте свой критический путь: кусок регресса, который гоняете руками каждую неделю. Даже 5 стабильных тестов в боевом CI весят больше пет-проекта. Согласуйте с командой, что можно положить в портфолио (часто — только обезличенный форк или описание без кода под NDA).

Когда резюме уже automation — и когда ещё нет

Ещё нет, если: курс без репозитория; тесты только локально на ноутбуке; «писал автотесты» = записывал клики в IDE; нет ни одного падения, которое вы разбирали.

Уже можно, если: есть CI; есть API или узкий UI; вы можете рассказать, почему не автоматизировали остальное; есть цифра или факт стабильности («прогон 8 минут, флаки вычищены, падения разбираем в тикете»). Формулировки — в материале про резюме автоматизатора, не копируйте «осуществил внедрение фреймворка с нуля», если вы прикрутили 6 тестов к готовому шаблону курса.

Вакансии с 5 годами SDET, нагрузочным тестированием и своим тест-фреймворком — не ваш первый слот. Ищите junior/middle automation, «manual + готовность писать тесты», «API automation». Чтение описания: что скрыто в вакансии.

Пример 1. 90 дней из manual QA

Светлана, 2 года ручного QA веб-сервиса заказов. Цель: не уволиться в никуда, а вырасти в текущей команде или уйти на automation junior.

План. Месяц 1: Python + pytest, три API-теста на наш стейджинг (согласовано с лидом): создание заказа, повтор оплаты, отмена. Месяц 2: эти тесты в CI ночного прогона, отчёт в канал. Месяц 3: два UI-сценария на критический путь оплаты, без попытки покрыть весь регресс.

В резюме потом: «API-регресс оплаты в CI, прогон N минут, зона: happy path + один негатив. UI — только оплата. Нагрузку не делала». Не: «разработала фреймворк автоматизации с нуля».

Разговор с руководителем на неделе 2: «Хочу забрать кусок регресса в пайплайн. Нужен доступ к стейджу и 20% времени. Вот три сценария, которые мы гоняем руками каждую пятницу».

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

Пример 2. Разработчик уходит в AQA

Кирилл, 1,5 года frontend, выгорел от фич, хочет тесты. Риск: вакансии ждут тестовый дизайн, а не только Playwright.

Пробел: мало баг-репортов и риск-анализа. Закрытие за 6 недель: взять учебный сервис, написать 15 кейсов вручную, 8 баг-репортов в шаблоне, затем автоматизировать API + 4 UI. На собеседовании первым говорить про риски и приоритеты, код — вторым.

Письмо на junior automation: «Есть коммерческий JS, но роль нужна тестовая. Вот репозиторий с CI и таблица, что покрыто. Ручного штата не было — приложил тестовую документацию, чтобы было видно, что не кликаю вслепую».

Ему не стоит откликаться на SDET с нагрузкой и Kotlin, пока нет тестовой базы. Смежный путь «из QA в разработку» — обратный и другой: из QA в разработку.

Собеседование: что спросят кроме кода

Типичные блоки: тест-дизайн (как режете сценарии), баг vs enhancement, API (код ответа vs контракт), флаки, что не автоматизировать, простой код на языке стека, SQL. Иногда — почитать упавший лог. Готовьте одну историю: «тест красный → причина → фикс или тикет на продукт». Вопросы по ручному контуру всё ещё валидны: собеседование QA. Живой код: live coding. Общая подготовка: interview prep.

Тестовое на автоматизацию часто = написать 3–5 тестов к чужому API. Ограничьте время. Если просят фреймворк «как в проде» на 20 часов — это уже работа, не отбор: тестовое задание и когда отказаться.

Типичные ловушки первого года

Большинство сорванных переходов в automation выглядят одинаково. Человек проходит курс, добавляет в шапку «Selenium, Cypress, Playwright, JMeter», откликается на SDET middle и решает, что рынок закрыт. Рынок не закрыт — файл врёт про уровень, а вакансии выбраны на два грейда выше.

Вторая ловушка — автоматизировать всё, что кликается. UI-сьют на 80 сценариев без API и без стабильных данных краснеет каждую ночь. Команда выключает джобу. В резюме остаётся «написал автотесты», на собеседовании — история про игнор пайплайна. Лучше 12 тестов, которые блокируют релиз, чем 80, которые все mute.

Третья — секретность и NDA. Если прод нельзя показать, учебный контур тем же языком и тем же типом проверок обязателен. Иначе вы просите поверить словам. Четвёртая — бросить ручной дизайн. Автоматизатор, который не может накидать риски на фичу без кода, на интервью выглядит как человек, который переносит клики в репозиторий.

Как не размазать поиск, пока учитесь: не откликайтесь «на все QA». Две кучи в трекере: manual (пока кормит) и automation junior с API. Конверсии не смешивать. Тишина на SDET при учебном GitHub ожидаема. Тишина на junior automation с живым CI — уже повод чинить README и заголовок, не добавлять пятый фреймворк. Воронка: почему не отвечают на отклики.

Как читать вакансию за три минуты

Выпишите: язык, UI vs API vs мобилка, CI, домен, грейд, формат. Если языка нет в вашем плане на квартал — не «быстро выучу за выходные» в письме. Если 70% текста про нагрузку и Gatling, а у вас API-регресс — это не ваш слот. Если написано junior, а в требованиях 5 лет SDET и свой фреймворк — тоже не ваш: это middle, которому сэкономили грейд в заголовке.

В письме повторите их контур своими словами: «у вас API-регресс оплаты в пайплайне — вот мой сьют на заказы плюс CI». Не «я командный и люблю качество». Шаблон: короткое сопроводительное. Черновик: генератор, затем вычитка. Живые слоты снова сверяйте с файлом: automation QA.

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

Можно ли стать автоматизатором без ручного опыта?

Можно, если вы закрываете тестовый дизайн артефактами и понимаете продукт. На рынке СНГ чаще берут из manual: дешевле проверить голову. Без ручного контура придётся сильнее доказывать, что вы не «разработчик, который не любит фичи».

Python или Java?

Тот, что в ваших целевых 15 вакансиях и в текущей команде, если растёте внутри. Язык не профессия. Смена языка на middle уже возможна, на входе — дорогая.

Нужен ли Playwright, если в вакансиях Selenium?

Инструмент вторичен. Принципы: локаторы, ожидания, данные, CI. Если все слоты про Selenium — сделайте 3 сценария на нём, не спорьте с рынком в README.

Сколько тестов достаточно для портфолио?

Не гонитесь за сотней. 10–20 стабильных с CI и честной зоной покрытия сильнее 80 флакающих. Рекрутер не гоняет ваш сьют целиком — он смотрит README и два теста.

Стоит ли идти на курсы «AQA с нуля за 2 месяца»?

Как расписание и ревью кода — иногда да. Как замена артефакту — нет. Работодатель открывает GitHub, не диплом школы.

Когда цель — SDET?

Когда вы уже поставляете тесты, читаете код продукта, пишете утилиты, а не только сценарии. До этого отклик на SDET middle — шум в воронке.

Что сделать сейчас

Откройте 15 вакансий в automation QA и выпишите язык и тип тестов. Выберите один язык. Заведите репозиторий с README «покрыто / не покрыто». На этой неделе — не новый курс, а первый API-тест в CI. Если вы в штате manual — согласуйте кусок боевого регресса. Параллельно перепишите заголовок резюме, когда появится прогон, не заранее: резюме автоматизатора и проверка файла в разборе резюме.

Первая роль — не «покрыть всё». Первая роль — стабильный узкий контур, который команда не игнорирует в пайплайне.