Как создать QA-портфолио на GitHub, которое приносит офферы (Playwright)

Большинство QA-инженеров которые претендуют на роли с автоматизацией не имеют публичного кода для показа: нанимающий инженер читает текст об опыте тестирования и делает субъективный вывод. GitHub-репозиторий с проходящим CI-пайплайном рассказывает ту же историю за 30 секунд без субъективных оценок. Статья разбирает что именно поместить в QA-портфолио: структуру Playwright-сьюта, организацию директорий, README, и единственную ошибку которая превращает портфолио в проблему.

Почему портфолио важно для QA-ролей

QA-автоматизация: технический навык. Компании которые нанимают на него хотят видеть код, а не описания кода.

CV с текстом "5 лет опыта с Playwright и TypeScript" и портфолио которое показывает 5 лет опыта с Playwright и TypeScript дают разные результаты на этапе скрининга.

У нанимающего инженера который смотрит на заявку есть 30–60 секунд до того как он решит читать дальше или переходить к следующей. Ссылка на GitHub-репозиторий с чистым, хорошо структурированным тест-кодом делает за эти 30 секунд больше чем абзац текста.

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

Что поместить в QA-портфолио

Не нужен огромный проект. Нужны доказательства конкретных компетенций. Каждый элемент портфолио должен демонстрировать что-то конкретное.

Playwright-тест-сьют для реального приложения

Это основной элемент. Репозиторий с тестами для реального приложения: не туториальное, не localhost, а реальный публично доступный сайт.

Что тестировать: lab-окружение BecomeQA на lab.becomeqa.com существует именно для этой цели. React-приложение с логином, CRUD-операциями, загрузкой файлов и платёжной секцией. Пиши тесты против него.

Что должен включать сьют:

• Флоу логина (happy path + негативные кейсы)
• CRUD-операции для основной фичи (добавить, редактировать, удалить элемент)
• Тесты валидации форм
• Хотя бы один API-тест с фикстурой request от Playwright
• Структура Page Object Model

Минимально жизнеспособный размер: 15–20 тестов которые реально проходят. Качество важнее количества.

Структура директорий которая отражает реальные знания

my-playwright-tests/
├── playwright.config.ts
├── package.json
├── tests/
│   ├── auth/
│   │   ├── login.spec.ts
│   │   └── logout.spec.ts
│   └── items/
│       ├── create-item.spec.ts
│       ├── edit-item.spec.ts
│       └── delete-item.spec.ts
├── pages/
│   ├── BasePage.ts
│   ├── LoginPage.ts
│   └── ItemsPage.ts
└── utils/
    └── testHelpers.ts

Такая структура показывает что понимаешь Page Object Model, организацию тестов и разделение тест-логики от логики страниц. Плоская директория с 20 .spec.ts файлами в корне показывает обратное.

README которое объясняет что ты построил

Напиши README которое охватывает:

1. Что делает тест-сьют (какое приложение, какие сценарии)

2. Как его запустить (npm install && npx playwright test)

3. Какие технологии использованы (Playwright, TypeScript, паттерн POM)

4. Что бы добавил следующим (показывает что умеешь думать о скоупе и приоритетах)

Коротко: 200–400 слов. README читают нанимающие инженеры которые решают стоит ли смотреть код.

Что делает код портфолио запоминающимся

Разница между кодом который производит впечатление и кодом который забывают:

// Слабо
await expect(page).toHaveURL('/dashboard');

// Сильно
await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
await expect(page.getByRole('navigation')).toContainText('admin@becomeqa.com');

Настройка репозитория портфолио

# Инициализация нового проекта
mkdir my-playwright-portfolio
cd my-playwright-portfolio
npm init playwright@latest

# Выбери TypeScript при запросе
# Укажи tests/ как директорию тестов
# Да для GitHub Actions workflow

Это даёт рабочую Playwright-установку с TypeScript и файлом GitHub Actions workflow который запускает тесты в CI.

Добавь тесты

// tests/auth/login.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../../pages/LoginPage';

test.describe('Login', () => {
  test('user can log in with valid credentials', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await loginPage.login('admin@becomeqa.com', 'testpass123');
    
    await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
  });

  test('shows error with incorrect password', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await loginPage.login('admin@becomeqa.com', 'wrongpassword');
    
    await expect(page.getByText('Invalid credentials')).toBeVisible();
    await expect(page).not.toHaveURL('/dashboard');
  });
});

Запуш на GitHub с прошедшим CI

GitHub Actions workflow который создаёт npm init playwright@latest будет автоматически запускать тесты при каждом пуше. Прошедший CI-пайплайн производит большее впечатление чем тесты которые "работают на моей машине".

Проверь вкладку Actions после пуша. Если тесты проходят: портфолио теперь показывает живой CI-пайплайн с Playwright-тестами. Это лучше чего угодно что можно написать в CV.

Если падают: почини до того как делиться ссылкой.

Что ещё включить

Примеры баг-репортов

Коллекция из 3–5 хорошо написанных баг-репортов. Не обязательно из компании. Могут быть баги которые найдёшь на любом публичном приложении, включая lab.becomeqa.com.

Форматируй точно по шаблону Анатомия баг-репорта, который исправят: структура и примеры: заголовок, окружение, предусловия, шаги, ожидаемый результат, фактический результат, серьёзность, вложения.

Помести в папку /bug-reports как markdown-файлы. Демонстрирует навыки письменной коммуникации и репортинга багов которые автоматизированные тесты не показывают.

Документ тест-плана или тест-кейсов

Короткий документ показывающий как подошёл бы к тестированию фичи с нуля. Выбери конкретную фичу (например загрузка файлов на lab.becomeqa.com) и напиши какие тест-сценарии покроешь, почему выбрал именно их и что приоритизируешь и почему.

Демонстрирует стратегическое мышление по тестированию, а не только выполнение тестов.

Где делиться портфолио

Частые ошибки которых стоит избегать

// Плохо
await page.fill('#email', 'admin@becomeqa.com');

// Лучше (хотя для портфолио хардкоженные тестовые учётные данные к тестовому приложению допустимы)
await page.fill('#email', process.env.TEST_EMAIL || 'admin@becomeqa.com');

FAQ

У меня нет реальных работ по автоматизации для показа. Что делать?

Строй портфолио на публичных тест-окружениях. lab.becomeqa.com существует для этой цели. Другие варианты: the-internet.herokuapp.com, automationexercise.com, saucedemo.com. Приложение не важно. Важно качество кода.

Сколько времени займёт построить портфолио?

Минимально жизнеспособное портфолио (15–20 тестов, структура POM, прошедший CI, README) занимает 15–25 часов сфокусированной работы для того кто знает Playwright. Если ещё учишься: закладывай 30–40 часов распределённых на несколько недель.

Стоит ли включать примеры API-тестов?

Да, если есть. Один-два API-теста с фикстурой request от Playwright показывают что понимаешь полный стек тестирования:

test('API: create item returns 201', async ({ request }) => {
  const response = await request.post('/api/items', {
    data: { destination: 'Tokyo', status: 'Planned' },
    headers: { Authorization: `Bearer ${token}` },
  });
  expect(response.status()).toBe(201);
});

Реально ли портфолио влияет на найм?

Да, заметно. QA-инженеры без портфолио конкурируют на тексте CV. QA-инженеры с портфолио дают нанимающим инженерам что-то конкретное для оценки. На практике владельцы портфолио проходят дальше на этапе скрининга в технических компаниях.