План на 90 дней: как получить первую работу QA

Большинство тех, кто учится QA, проводят месяцы за туториалами и к 90-му дню имеют концепции, но не портфолио. Этот план строит 90 дней вокруг конкретных результатов: рабочий Playwright-тест к 4-й неделе, сьют из 20+ тестов с CI на GitHub Actions к 8-й неделе, активные заявки на работу к 12-й неделе.

Дни 1–30: Фундамент

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

Неделя 1: Основы ручного тестирования

Первая неделя про то, как выглядит структурированное тестирование. Основной артефакт ручного QA: тест-кейс. Это задокументированный набор шагов, предусловий, ожидаемых и фактических результатов. Напиши пять тест-кейсов для потока авторизации на lab.becomeqa.com вручную, в Google Sheets или Notion. Используй колонки: ID тест-кейса, Предусловие, Шаги, Ожидаемый результат, Фактический результат, Статус.

Шаги не должны быть расплывчатыми. Вот что такое тест-кейс: «Перейти на страницу входа, ввести email admin@becomeqa.com, ввести неверный пароль, нажать Submit, убедиться что сообщение об ошибке содержит текст Invalid credentials». «Проверить что вход работает» тест-кейсом не считается. Вся суть именно в точности.

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

Когда найдёшь баг (а найдёшь), оформи его как полноценный баг-репорт. Минимальный баг-репорт содержит: заголовок, окружение (браузер, ОС), предусловия, шаги для воспроизведения, ожидаемое поведение, фактическое поведение, серьёзность. Серьёзность (severity) это не степень раздражения. Critical: приложение сломано для всех. Major: ключевая функция не работает. Minor: что-то выглядит неправильно, но ничего не блокирует. Trivial: опечатка.

Неделя 2: Agile и роль QA в команде

Реальная QA-работа происходит внутри Agile-спринтов. Разберись на этой неделе как QA-инженер вписывается в этот процесс. Нужно понять что такое пользовательская история (user story) и как критерии приёмки связаны с тест-кейсами, что такое «определение готовности» (definition of done) и почему QA входит в него, и как выглядит обзор спринта с точки зрения QA.

Практическое задание: возьми три пользовательские истории из публичной доски (шаблоны Trello подойдут, или придумай сам на основе функций lab.becomeqa.com) и напиши критерии приёмки для каждой. Затем конвертируй эти критерии в тест-кейсы. Это реальный рабочий поток: история приходит, ты пишешь тесты до того как разработка заканчивается, затем проверяешь когда разработчик говорит «готово».

Разберись с разницей между верификацией (правильно ли мы построили?) и валидацией (правильное ли мы построили?). Эти термины встречаются на собеседованиях.

Недели 3–4: Начало работы с Playwright

Установи Node.js (LTS-версию) и создай новый Playwright-проект командой npm init playwright@latest. Когда спросят, выбери TypeScript. Playwright создаст структуру папок и тестовый пример. Запусти npx playwright test и посмотри как он проходит. Эта структура: tests/, playwright.config.ts, package.json. Именно на ней будешь строить следующие два месяца.

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

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

test('login with valid credentials shows dashboard', 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();
});

Запусти с флагом --headed: npx playwright test --headed. Браузер откроется и начнёт сам заполнять поля. Этот момент цепляет большинство людей. Дальше напиши ещё два теста: один для неверных учётных данных (проверить что появляется сообщение об ошибке), один для выхода из аккаунта (проверить что кнопка Login снова видна). К концу 4-й недели должно быть шесть-восемь проходящих тестов и понимание того как Playwright думает о страницах.

Дни 31–60: Навыки автоматизации

Во втором месяце начинается настоящая работа. Углубишься в Playwright, освоишь стратегии локаторов, уверенно напишешь ассерции, реализуешь Page Object Model, освоишься с Git и GitHub, и выйдешь на конкретную цель: 20 и более реальных тестов против lab.becomeqa.com. Именно это спрашивают на технических собеседованиях.

Неделя 5: Локаторы и ассерции

Playwright даёт несколько способов найти элементы на странице. Правильная иерархия, от наиболее предпочтительного к наименее: getByRole, getByLabel, getByPlaceholder, getByText, getByTestId, и CSS-селекторы как последнее средство. Причина такого порядка: устойчивость. Локаторы на основе ролей и лейблов работают даже когда разработчик переименует CSS-класс или заменит div на section. CSS-селекторы ломаются.

Проведи 5-ю неделю прописывая локаторы для каждого основного элемента на lab.becomeqa.com. Используй npx playwright codegen https://lab.becomeqa.com: нажимай на элементы и смотри как Playwright их идентифицирует. Затем вручную перепиши каждый сгенерированный локатор в предпочтительный формат. Codegen часто выдаёт CSS-селекторы, а тебе нужна привычка выбирать лучшие варианты.

По ассерциям: отработай оба типа. Жёсткая ассерция (expect(locator).toBeVisible()) останавливает тест сразу при падении. Мягкая (expect.soft(locator).toBeVisible()) фиксирует провал, но тест продолжает работать, чтобы за один проход поймать больше проблем. Мягкие ассерции нужны когда хочешь проверить состояние целой страницы за раз. Жёсткие нужны когда провал означает что дальше в тесте ничему нельзя доверять.

Неделя 6: Page Object Model

К этому моменту тесты, скорее всего, начали повторяться. Каждый тест которому нужен авторизованный пользователь повторяет одни и те же четыре строки. Page Object Model (POM) убирает это дублирование и делает тесты читаемыми как документация.

Создай папку pages/. Начни с двух файлов: LoginPage.ts и ItemsPage.ts.

// pages/LoginPage.ts
import { Page } from '@playwright/test';

export class LoginPage {
  constructor(private page: Page) {}

  async navigate() {
    await this.page.goto('https://lab.becomeqa.com');
  }

  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();
  }

  async getErrorMessage() {
    return this.page.getByRole('alert').textContent();
  }
}

// pages/ItemsPage.ts
import { Page, Locator } from '@playwright/test';

export class ItemsPage {
  readonly itemRows: Locator;

  constructor(private page: Page) {
    this.itemRows = this.page.getByRole('row');
  }

  async getItemCount() {
    return this.itemRows.count();
  }

  async searchFor(term: string) {
    await this.page.getByPlaceholder('Search').fill(term);
  }
}

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

Неделя 7: Git и GitHub

Ты пишешь код уже месяц. Пора правильно версионировать его и сделать видимым. Установи Git если ещё нет. Создай аккаунт на GitHub. Выгрузи свой Playwright-проект как публичный репозиторий.

Git-поток который нужен для работы: git status чтобы посмотреть что изменилось, git add чтобы добавить конкретные файлы в стейдж, git commit -m "message" чтобы сохранить снапшот, git push чтобы загрузить. На этом этапе работаешь один, поэтому разветвлённый рабочий процесс пока не нужен. Но всё равно отработай его: создай feature-ветку командой git checkout -b add-items-tests, напиши там тесты, зафиксируй их, и смерджи командой git checkout main && git merge add-items-tests. Именно так работает каждая команда, в которой окажешься.

Напиши README для репозитория. Он не должен быть длинным. Расскажи что это за проект, как установить зависимости (npm install), как запустить тесты (npx playwright test), и против какого сайта ты тестируешь. README который существует и содержит рабочие инструкции уже лучше, чем большинство джуниорских портфолио.

Неделя 8: 20+ тестов и покрытие API

Неделя исполнения. Цель: 20 и более проходящих тестов против lab.becomeqa.com. Звучит много. На деле нет. Только потоки авторизации, CRUD-операции с элементами, поиск, фильтрация и API-эндпоинты дадут легко 40 сценариев для тестирования.

Для API-тестирования Playwright не нужны сторонние инструменты, всё встроено:

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

test('GET /api/items returns a list with required fields', 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('id');
  expect(items[0]).toHaveProperty('destination');
});

Напиши минимум пять API-тестов: happy-path GET, POST который создаёт элемент, DELETE который его удаляет, тест авторизации (что происходит если вызвать API без токена?) и один который проверяет что структура ответа совпадает с тем что отображает UI. Смешай API-тесты и UI-тесты в одном тестовом сьюте. Именно так устроены реальные проекты.

Дни 61–90: Портфолио и поиск работы

В третьем месяце всё построенное конвертируется в то, что помогает найти работу. Настроишь CI чтобы тесты запускались автоматически, напишешь профессиональный README, отполируешь LinkedIn-профиль, начнёшь откликаться. Поиск работы и обучение идут параллельно. Не жди до 90-го дня чтобы отправить первый отклик.

Неделя 9: GitHub Actions CI

Тестовый сьют который запускается только на ноутбуке стоит меньше для нанимающего менеджера, чем тот что запускается в облаке при каждом коммите. Настрой GitHub Actions: создай файл .github/workflows/playwright.yml.

name: Playwright Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Run tests
        run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Запушь этот файл. Зайди на вкладку Actions в репозитории GitHub. Должен запуститься workflow и тесты пройдут в Linux-контейнере. Когда пройдут, рядом с последним коммитом появится зелёная галочка. Скриншот этой галочки можно публиковать в LinkedIn. Это конкретное доказательство что ты понимаешь CI, а это тема которая звучит почти на каждом техническом собеседовании.

Если часть тестов оказывается флакующими в CI (проходят локально, но нестабильно падают в пайплайне), это само по себе важный урок. Флакующие тесты в CI обычно падают из-за тайминга: страница загружается медленнее на облачной машине чем на ноутбуке. Исправление почти всегда одно: заменить жёсткие ожидания (page.waitForTimeout(2000)) на правильное ожидание Playwright (page.waitForSelector, или просто довериться что ассерции Playwright ждут сами). Найди каждый флакующий тест и исправь. CI с одним красным нестабильным тестом хуже чем CI с 15 тестами вместо 20.

Неделя 10: Полировка портфолио

Репозиторий на GitHub должен включать три вещи до начала откликов: достаточное количество тестов (20+), CI-бейдж в README, и документацию которой может следовать незнакомый человек.

Добавь CI-бейдж в README, скопировав URL бейджа из GitHub Actions workflow. В Markdown это выглядит так:

![Playwright Tests](https://github.com/YOUR_USERNAME/YOUR_REPO/actions/workflows/playwright.yml/badge.svg)

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

Расширь README: добавь описание проекта, что именно тестируешь и почему (lab.becomeqa.com: практическое приложение для QA-инженеров), таблицу с каждым тестовым файлом и тем что он покрывает, и как запускать конкретные группы тестов командой npx playwright test --grep @api (добавь теги @api и @ui к тестам чтобы это работало). Цель: человек который никогда не видел твой проект должен суметь клонировать его, запустить и разобраться что происходит менее чем за десять минут.

Неделя 11: LinkedIn и резюме

LinkedIn-профиль должен включать четыре вещи для привлечения внимания QA-рекрутеров: заголовок с указанием цели («QA Automation Engineer | Playwright | TypeScript»), раздел About из 3–4 предложений объясняющих твой переход в QA и что ты построил, раздел Featured со ссылкой на GitHub-репозиторий, и раздел Skills: Playwright, TypeScript, JavaScript, Git, GitHub Actions, API Testing, Agile.

Если ты переходишь из другой области, не скрывай этого. Сформулируй как преимущество. «Опыт в клиентском сервисе дал мне другой взгляд на то как реальные пользователи взаимодействуют с продуктом» звучит интереснее, чем делать вид что всегда был в технологиях.

Для резюме: укажи GitHub-проект как полноценную строку опыта, не как примечание. Пиши так: «Playwright Automation Framework (личный проект): создал тестовый сьют с 25+ UI и API тестами против реального веб-приложения на TypeScript и Playwright. Настроил CI/CD-пайплайн с GitHub Actions. Реализовал Page Object Model для поддерживаемости.» Каждое слово правдиво, конкретно и напрямую соответствует тому что указано в вакансиях.

Если нет профессионального QA-опыта, резюме состоит из двух разделов: проект портфолио и предыдущий опыт работы сформулированный через переносимые навыки (внимание к деталям, ориентация на процесс, коммуникация, технический опыт при наличии). Ограничь объём одной страницей.

Неделя 12: Откликайся и продолжай

Начинай откликаться до того как почувствуешь готовность. На 30-й день ты чувствовал неготовность. На 60-й тоже. На 90-й тоже будет так. Узнать о своих пробелах можно только попав на собеседования и посмотрев что спрашивают. Отказ после технического экрана где не смог ответить на вопрос про fixtures или управление тестовыми данными точно показывает что изучать дальше. Это ценно.

На 12-й неделе откликнись в 5–10 компаний. Приоритет: компании с небольшими QA-командами (научишься больше и получишь больше ответственности), компании чьими продуктами ты сам пользуешься (искренний интерес слышится на собеседованиях), и компании явно ищущие джуниор-инженеров по автоматизации (не просто «QA аналитик» для ручного тестирования).

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

FAQ

Сколько тестов реально нужно в портфолио?

Минимум: двадцать. Тридцать-сорок уже хорошо. Больше не нужно. Задача показать охват (UI-тесты, API-тесты, POM, CI), а не объём. Пять тестов покрывающих авторизацию, список элементов, один API-эндпоинт и демонстрирующих Page Object Model произведут большее впечатление, чем пятьдесят скопированных тестов авторизации.

Нужен TypeScript или достаточно JavaScript?

Большинство современных Playwright-проектов используют TypeScript. Быть экспертом не нужно. Статическая типизация помогает больше чем мешает. Начинай с TypeScript с первого дня, пусть редактор говорит когда типы неправильные, и ищи что означает ошибка. В этом 90% процесса обучения.

Откликаюсь, но никто не отвечает. Что делать?

Если количество откликов меньше 30 и прошло меньше четырёх недель, выводы делать рано. Если больше 30 откликов без ответа, проблема обычно в резюме или LinkedIn-профиле, не в навыках. Попроси кого-то из QA или технической сферы просмотреть резюме. Вступи в QA-сообщества в LinkedIn и Discord. Там часто делятся открытыми позициями и могут порекомендовать напрямую, минуя стопку резюме.

Стоит ли делать сертификацию ISTQB за эти 90 дней?

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

Дошёл до 90-го дня, работу ещё не нашёл. Что дальше?

Продолжай откликаться и строить. Добавь второй проект в портфолио. Напиши тесты для другого приложения. Многие open-source проекты принимают вклады включающие тесты, а это даёт реальный опыт совместной работы. Начни простой технический блог документируя что узнал; даже два-три поста о конкретных решённых проблемах показывают что ты умеешь доносить технические мысли. 90-дневный план выводит на старт, а не к финишу. Большинство получают первый QA-оффер между 4-м и 6-м месяцем.