Дорожная карта QA-автоматизации 2026: ключевые навыки для трудоустройства

Учить Playwright до JavaScript означает копировать и вставлять код без понимания почему он ломается. Порядок этих девяти навыков намеренный: каждый из них открывает следующий, и пропустить этапы вперёд стоит больше времени чем экономит. Дорожная карта разбирает что и в каком порядке учить, с честными оценками времени на каждый этап и пояснениями что можно отложить до тех пор пока реально не понадобится.

Почему порядок важен

Нельзя писать настоящие тесты без JavaScript. Точка. И нельзя автоматизировать API если никто не объяснил что такое API. И точно нельзя настраивать CI/CD когда ещё нет ни одного теста который стоит запускать.

Каждый навык здесь открывает следующий. Прыгай по списку и потратишь вдвое больше времени в замешательстве.

1. Playwright: твой фреймворк тест-автоматизации

Selenium раньше был ответом. Сейчас нет. Не для тех кто начинает с нуля в 2026.

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

Вот как выглядит настоящий Playwright-тест:

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

test('user can log in', 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();
});

Чисто. Без бойлерплейта. Если это пока непонятно, не страшно: курс по Playwright покрывает именно это.

2. JavaScript/TypeScript: слой языка

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

Playwright: это JavaScript. TypeScript: JavaScript с добавленными типами. Типы ловят твои ошибки до запуска. Playwright по умолчанию настраивает TypeScript и после недели с ним не захочешь возвращаться к обычному JS.

Что реально нужно:

Начни с переменных, типов данных, функций, массивов и объектов, и async/await. Последнее не опционально. Каждое действие в Playwright использует его. Без понимания async/await летишь вслепую.

Затем, когда уже регулярно пишешь тесты: деструктуризация, spread-оператор, модули, обработка ошибок try/catch и классы для Page Object Model.

Не жди пока "закончишь JavaScript" прежде чем трогать тесты. Это ловушка. Выучи основное, начни писать тесты, подхватывай остальное по мере надобности. Тесты дают конкретную причину использовать язык.

3. Практика на реальном сайте

Теория без сайта для автоматизации: просто чтение. Нужны реальные формы, реальные таблицы, реальные граничные случаи.

Большинство практических сайтов либо тривиально простые (одна кнопка, одно поле), либо падают случайным образом и выдают ошибки не связанные с кодом твоих тестов. Оба варианта хуже чем бесполезны для обучения.

Мы создали lab.becomeqa.com для этого. Полный поток логина, сортируемые таблицы, модалы, загрузка файлов, платёжная форма подключённая к Stripe test mode, и API-эндпоинты доступные для прямого тестирования. Поддерживается стабильным потому что ненадёжные практические окружения учат неправильным привычкам отладки.

Другие достойные варианты для разнообразия: SauceDemo, The Internet от Dave Haefner, TodoMVC. Но у lab.becomeqa.com API настроен под упражнения курса.

4. API-тестирование: быстрее и стабильнее UI-тестов

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

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

В Playwright API-тестирование встроено через фикстуру request:

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

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

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

Без браузера. Без страницы. Только HTTP. Полезные инструменты: фикстура request (уже встроена в Playwright), Postman для ручного исследования API, базовые HTTP-методы (рассмотрены в навыке 7).

5. CI/CD: сделай тесты реально полезными

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

CI/CD-пайплайны запускают твои тесты при каждом коммите, каждом PR, каждом деплое. Автоматически. Вот как основные инструменты различаются на практике:

Сначала запусти Playwright-тесты в GitHub Actions. Сделаешь это за день.

6. Основы SQL: проверяй базу данных сам

В какой-то момент нужно будет убедиться что то что показывает UI реально сохранилось в базе данных. Или посмотреть данные которые UI никогда не показывает. Для этого нужен SQL.

Хорошая новость: SQL для QA не сложный SQL. Это примерно пять паттернов запросов которые покрывают 80% всего что когда-либо понадобится:

-- Проверяем существует ли пользователь
SELECT * FROM users WHERE email = 'test@example.com';

-- Проверяем связанные данные в нескольких таблицах
SELECT orders.id, users.email, orders.status
FROM orders
JOIN users ON orders.user_id = users.id
WHERE orders.status = 'pending';

Два SELECT. Один JOIN. Условия WHERE. Это реально большая часть всего. Роли которые требуют "опыт с SQL" почти всегда спрашивают именно это и немногим больше.

7. Как работает интернет

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

Что происходит когда открываешь страницу

Вводишь https://lab.becomeqa.com в браузере и происходят четыре вещи по порядку:

• DNS-запрос. Браузер спрашивает "какой IP у lab.becomeqa.com?" Получает в ответ что-то вроде 104.21.8.42. Доменные имена: просто псевдонимы.
• TCP-соединение. Браузер подключается к этому IP на порту 443, который является стандартным HTTPS-портом.
• TLS-рукопожатие. Браузер и сервер проверяют идентификаторы и договариваются о шифровании. Это буква S в HTTPS.
• HTTP-запрос/ответ. Браузер отправляет GET / HTTP/1.1, сервер возвращает HTML.

Меньше 100мс на нормальном соединении.

Почему это важно для тестирования

"Connection refused", "SSL certificate error" и "404 Not Found": три разные точки в цепочке. Не знаешь цепочку: каждая сетевая ошибка выглядит одинаково и отладка занимает в пять раз дольше.

Основы HTTP: запросы имеют метод (GET читает, POST создаёт, PUT/PATCH обновляет, DELETE удаляет), путь, заголовки и опционально тело. Ответы имеют статус-коды: 200 (всё хорошо), 404 (путь не найден), 500 (сам сервер упал). Каждый клик и отправка формы в Playwright-тесте: один из таких запросов под капотом.

8. Основы Git

Git: способ которым тестовый код передаётся, версионируется и деплоится. Используется для хранения тестов, синхронизации с разработчиками и запуска CI. Не нужно понимать внутренности git. Шесть команд и один конфигурационный файл: весь набор.

Шесть команд

git clone <repo-url>            # скачать проект на машину
git pull                        # получить последние изменения от команды
git checkout -b add-login-tests # создать ветку для новых тестов
git add tests/login.spec.ts     # подготовить изменённый файл
git commit -m "add login tests" # сохранить снимок с сообщением
git push origin add-login-tests # загрузить ветку на GitHub/GitLab

Клонируй один раз. Делай pull перед началом каждого дня. Ветка на фичу. Push когда готово. Это весь цикл.

Файл .gitignore

Playwright генерирует папки со скриншотами, видео и HTML-отчётами при запуске тестов. Ничему из этого не место в репозитории. Создай .gitignore в корне проекта:

node_modules/
playwright-report/
test-results/
.env

Пропусти этот файл и запушишь сотни мегабайт тестовых артефактов. Коллеги узнают кто это сделал.

Отладка ошибок CI

Тесты проходят локально но падают в GitHub Actions. Очень распространённая ситуация. Первое что проверить:

git log --oneline -5     # посмотреть последние 5 коммитов
git diff main            # посмотреть что изменилось относительно main

Обычно либо файл который забыли добавить через git add, либо версия зависимости которая отличается между твоей машиной и CI-окружением. Git log показывает точно что закоммичено, а что нет.

9. Agile/Scrum: говори на языке команды

Самый простой навык в списке. Самый упускаемый теми кто меняет карьеру. Сертификат не нужен. Нужно не выглядеть растерянно на собственном стендапе.

Что реально важно: что такое спринт (двухнедельные рабочие циклы, как правило), как работают стендапы (что делал, что делаешь сегодня, что блокирует), что такое пользовательская история, и что означает "definition of done" с точки зрения QA конкретно, потому что это отличается от того что имеет в виду разработчик говоря то же самое.

Большинство команд используют Jira. Конкретный инструмент меняется от компании к компании. Концепции нет.

Сколько реально времени это занимает

Честный ответ: четыре-шесть месяцев по 1–2 часа в день выводит большинство людей на уровень готовности к позиции джуниора. При условии что реально практикуешься, а не просто читаешь.

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

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

Нужна ли степень CS?

Нет. У большинства QA automation-инженеров нет степени CS. Что помогает найти работу: GitHub-репозиторий с хорошо написанными тестами и умение объяснить что они делают. Степень это не доказывает. Тесты доказывают.

Selenium или Playwright?

Playwright для всех кто начинает с нуля в 2026. Если вступаешь в компанию уже использующую Selenium, учи их настройку. Для свежего обучения: Playwright быстрее осваивается, лучше задокументирован и реально поддерживается командой которой не всё равно.

Сложен ли JavaScript для изучения QA?

Справляемо. Ты не строишь приложения. Ты читаешь и пишешь тесты. Это узкий срез языка. Большинство людей достигают достаточного комфорта за четыре-шесть недель ежедневной практики.

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

lab.becomeqa.com, GitHub-репозиторий с твоими тест-файлами, автоматизация сценариев на публичных сайтах. Портфолио которое можно продемонстрировать в screen share на собеседовании стоит больше любой существующей сертификации.