Как стать QA-инженером в 2026 году: полная дорожная карта (без диплома)

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

Роль бывает двух видов, и выбрать нужно рано

Когда большинство говорит «QA-инженер», они имеют в виду одну из двух разных работ. Ручные QA-тестировщики исследуют ПО вручную, пишут тест-кейсы, заводят баги и передают выводы разработчикам и менеджерам продукта. Инженеры по автоматизации QA пишут код который тестирует ПО автоматически, проверяя каждый деплой без ручного клика.

Ручное тестирование проще войти. Автоматизация платит значительно больше и даёт лучшую долгосрочную карьерную траекторию. Медианная зарплата QA automation engineer в США: $95 000–$115 000 в зависимости от локации и размера компании. Ручное QA обычно на $20 000–$30 000 ниже.

Этот гайд про путь автоматизации, потому что именно туда движется рынок и где накапливается карьерный рост. Если стартуешь с нуля, это тот путь который стоит выбрать.

Хорошая новость: степень в информатике не нужна ни для одной из ролей. Десятки работающих QA automation engineer начинали учителями, специалистами поддержки, проджект-менеджерами и бухгалтерами. Технические навыки учатся. Что ты реально продаёшь на собеседовании: доказательство что ты их освоил.

Единственные технические навыки которые реально нужны для первой работы

Вакансии джуниор-автоматизаторов в 2026 году кластеризуются вокруг одного короткого списка. Если видишь вакансию требующую 15 конкретных навыков, большинство из них wishful thinking. Что реально провезёт через техническое собеседование:

Playwright или Selenium (Playwright настойчиво рекомендуется всем кто начинает сейчас), JavaScript или TypeScript (TypeScript используют большинство современных проектов), базовое API-тестирование, Git и понимание как работает CI. Всё. Остальное: nice-to-have который подбирают на работе.

Реальный пример того что делает джуниор QA automation engineer в первый день. Клонируешь тестовый репозиторий, запускаешь существующий тест-сьют, видишь как одни тесты проходят и несколько падают, и первая задача: понять почему упавшие упали. Это требует Git чтобы получить код, Node.js чтобы запустить, TypeScript чтобы читать и Playwright чтобы понимать ошибки. Ничего больше. Никакой сертификации, никакого чеклиста из 30 навыков.

Начинай с Playwright раньше всего остального

Это контринтуитивная часть роадмапа. Большинство начинает с «изучения программирования» потому что так говорят карьерные гайды. Проблема в том что чистые упражнения по программированию абстрактны и быстро надоедают. Тратишь недели на задачи типа fizzbuzz и манипуляции с массивами, пока реальная причина почему ты захотел учиться (ломать и тестировать ПО) остаётся навсегда в будущем.

Начинай с Playwright первым. Принимай что будешь копипастить код который не полностью понимаешь. Запускай его. Смотри как работает. Ломай намеренно. Смотри какая ошибка возвращается.

Первый тест который стоит написать, используя lab.becomeqa.com:

import { test, expect } from '@playwright/test';

test('login with valid credentials', async ({ page }) => {
  await page.goto('https://lab.becomeqa.com');
  await page.getByRole('button', { name: 'Login' }).click();
  await page.getByLabel('Username').fill('admin@becomeqa.com');
  await page.getByLabel('Password').fill('testpass123');
  await page.getByRole('button', { name: 'Submit' }).click();

  await expect(page.getByText('My Travel Items')).toBeVisible();
});

Запусти это. Посмотри как браузер открывается, заполняет поля и кликает кнопки без твоего участия. Это ощущение когда автоматизация работает в первый раз и держит людей на плаву через более трудные части.

Потом пишешь второй тест с неверными учётными данными и проверяешь что появляется сообщение об ошибке. Затем третий: выходит из системы и проверяет что страница возвращается в состояние логина. Три теста, все на реальном UI, и уже попрактиковал локаторы, проверки и структуру тестов.

JavaScript и TypeScript: учи достаточно, потом продолжай

Как только начнёшь писать тесты, будешь упираться в языковые стены. Видишь async и await и не знаешь что они значат. Хочешь сохранить значение из одного шага теста и использовать в другом, но не понимаешь как работают переменные через await-вызовы. Это моменты чтобы остановиться и изучить языковую концепцию которая тебя блокирует.

Минимальный JavaScript/TypeScript нужный до написания реальных тестов: переменные и const/let, функции, массивы и объекты, async/await и зачем они нужны, базовые операции со строками. Это примерно две-три недели ежедневной практики если никогда не писал код.

Концепции которые подберёшь по мере написания тестов: TypeScript-типы и интерфейсы, деструктуризация, модули и импорты, классы когда дойдёшь до Page Object Model.

Конкретный пример как async/await сбивает в начале. Если написать так:

const text = page.getByText('Welcome').textContent();
console.log(text); // выводит Promise, а не текст

В консоль выводится объект Promise, а не реальный текст. Правильная версия:

const text = await page.getByText('Welcome').textContent();
console.log(text); // выводит 'Welcome'

API-тестирование не опционально

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

Почему его стоит включать в список обучения рано: API-тесты в пять-десять раз быстрее UI-тестов и падают по меньшему числу посторонних причин. UI-тест может упасть из-за того что кнопка переехала, спиннер загрузки взял лишнюю секунду или тултип перекрыл элемент. API-тест падает потому что данные неверны, а это то что тебя реально волнует.

Playwright имеет API-тестирование встроенным в тот же фреймворк который уже используешь:

test('GET /api/items returns travel items', async ({ request }) => {
  const response = await request.get('https://lab.becomeqa.com/api/items');

  expect(response.status()).toBe(200);

  const body = await response.json();
  expect(body.length).toBeGreaterThan(0);
  expect(body[0]).toHaveProperty('destination');
  expect(body[0]).toHaveProperty('id');
});

Никаких новых инструментов. Никаких отдельных фреймворков. Те же функции test и expect которые уже знаешь, только request вместо page.

Потрать несколько часов в Postman. Не потому что будешь использовать его для автоматизации, а потому что ручное исследование API перед написанием тестов экономит время. Отправляешь запросы, видишь формы ответов, понимаешь заголовки авторизации, и код тестов становится понятным вместо слепого копирования из документации.

Строй что-то показываемое, а не только понимаемое

Здесь большинство самоучек застревают. Проходят туториалы, пишут упражнения, чувствуют прогресс. Потом кто-то спрашивает «можно посмотреть на твою работу?» и показывать нечего.

Нанимающие менеджеры смотрят на GitHub-профили у джуниор-кандидатов. Не потому что ожидают полированных тест-сьютов уровня сеньора. Потому что GitHub-репозиторий доказывает что код реально написан, а не просто просмотрено видео о нём.

Портфолио которое даст интервью прямолинейно: один GitHub-репозиторий с Playwright тест-сьютом покрывающим реальный сайт, конфигурация TypeScript, Page Object Model хотя бы для двух страниц, и UI и API тесты, воркфлоу GitHub Actions запускающий тесты при каждом пуше. Вот и всё. Это планка.

Часть с Page Object Model кажется пугающей до того как сделаешь. Концепция: вместо написания page.getByLabel('Username').fill(username) в каждом тесте где нужен логин, создаёшь класс LoginPage с методом login(username, password). Тесты вызывают loginPage.login('admin@becomeqa.com', 'testpass123'). Если форма логина изменится, правишь в одном месте.

// pages/LoginPage.ts
export class LoginPage {
  constructor(private page: Page) {}

  async login(username: string, password: string) {
    await this.page.getByRole('button', { name: 'Login' }).click();
    await this.page.getByLabel('Username').fill(username);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Submit' }).click();
  }
}

Используй lab.becomeqa.com как сайт для автоматизации в портфолио. Там достаточно сложности (логин, таблицы данных, модалки, загрузка файлов, API-эндпоинты) чтобы продемонстрировать реальные навыки, и сайт не ляжет и не заблокирует автоматизированный трафик.

Как применить это в ближайший понедельник

Конкретный план на следующую неделю.

Понедельник: устанавливаешь Node.js и Playwright. Следуешь официальному quickstart. Запускаешь один тест против lab.becomeqa.com. Не двигаешься дальше пока не увидишь зелёный тест в терминале.

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

Среда: нормально разбираешься с концепцией async/await. Читаешь статью MDN о Promises. Смотришь короткое видео. Возвращаешься и перечитываешь свой код тестов. Должен стать понятнее.

Четверг: создаёшь GitHub-аккаунт если нет. Пушишь репозиторий с тестами. README может быть честным: «Учу Playwright, работа в процессе». Это нормально.

Пятница: добавляешь воркфлоу файл GitHub Actions. В документации Playwright есть пример для копипаста. Добиваешься запуска тестов в GitHub Actions. Скриншот зелёной галочки. Сохраняешь.

Вторая неделя: Page Object Model для flow логина. Третья неделя: TypeScript-интерфейсы для данных API-ответов. Четвёртая неделя: откликаешься на одну джуниор-вакансию QA даже если не чувствуешь себя готовым. Чтение описания вакансии скажет точно что изучать дальше.

Люди которых нанимают не ждут пока почувствуют готовность. Они строят доказательства что могут делать работу, размещают их на виду и начинают разговаривать с компаниями пока продолжают учиться.

FAQ

Сколько реально занимает выход на работу?

Четыре-шесть месяцев ежедневной практики для большинства людей без предыдущего опыта программирования. Меньше если идёшь из разработки. Больше если практикуешься только по выходным. Переменная не в таланте. В последовательности и качестве того что строишь для показа.

Нужно ли знать Selenium?

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

Есть ли сертификация которую стоит получить?

ISTQB Foundation Level: самая признанная сертификация в QA. Демонстрирует знакомство с теорией и терминологией тестирования. Некоторые компании фильтруют по ней, большинство не требуют. Если выбор между получением ISTQB и созданием проекта для портфолио: создавай проект. GitHub-репозиторий с работающими тестами более весомое доказательство чем тест с несколькими вариантами ответов.

Что реально писать в резюме без профессионального QA-опыта?

Своё GitHub-портфолио. Указываешь проект со ссылкой, описываешь что построил («Playwright тест-сьют с 40+ тестами покрывающими UI-flow и REST API эндпоинты, запускается в CI через GitHub Actions»), отмечаешь технологии. Рекрутеры видят GitHub-ссылки и реально переходят по ним. Сначала добейся чтобы резюме оказалось перед людьми которые кликнут ссылку, потом беспокойся о формулировках остального.

Ручное или автоматизированное тестирование первым?

Автоматизация. Платит больше, туда движется отрасль, и кривая обучения фронт-загружена. Как только пройдёшь её: становишься трудоустроенным. Начать с ручного QA и переходить в автоматизацию позже означает учиться дважды. Исключение одно: если можешь быстро найти работу ручного QA и использовать её для внутреннего перехода в компании которая оплатит время на развитие.