Почему портфолио важно
При найме в QA слова мало стоят. Каждый кандидат утверждает, что знает Playwright, понимает CI/CD и умеет проектировать тест-стратегии. Портфолио — это доказательство. Оно отделяет тех, кто говорит о тестировании, от тех, кто реально его делает.
Для QA-инженеров портфолио обычно означает публичный профиль на GitHub с хорошо структурированными проектами, демонстрирующими навыки тестирования.
Что делает портфолио отличным
Основные компоненты
Сильное QA-портфолио включает:
1. Проект фреймворка автоматизации Это центральный элемент. Постройте полноценный фреймворк, тестирующий реальное (публичное) приложение:
- Используйте современный инструмент (Playwright, Cypress или аналог)
- Реализуйте Page Object Model или паттерн Screenplay
- Включите API-тесты наряду с UI-тестами
- Добавьте репортинг (Allure, HTML-отчёты)
- Настройте CI/CD с GitHub Actions
- Напишите подробный README с архитектурными решениями
2. Коллекция API-тестов Коллекция Postman или программная API-тест-сюита для публичного API:
- Потоки аутентификации
- CRUD-операции
- Обработка ошибок и граничные случаи
- Валидация данных
3. Тест-план или документ стратегии Написанный тест-план для реального приложения, демонстрирующий аналитическое мышление:
- Оценка рисков
- Область и подход тестирования
- Требования к окружению
- Критерии входа/выхода
4. Баг-репорты Образцовые баг-репорты, демонстрирующие умение чётко описывать проблемы.
Структурирование профиля на GitHub
Организация репозиториев
ваш-github/
├── playwright-demo-framework/ # Основной проект автоматизации
│ ├── tests/
│ │ ├── ui/
│ │ ├── api/
│ │ └── performance/
│ ├── pages/ # Page objects
│ ├── utils/ # Хелперы
│ ├── .github/workflows/ # CI/CD
│ ├── playwright.config.ts
│ └── README.md # Документация архитектуры
├── api-testing-suite/ # Проект API-тестов
├── test-plans/ # Текстовые артефакты
└── README.md # README профиля
README профиля
GitHub позволяет создать специальный репозиторий (с именем пользователя) с README, который отображается на профиле. Используйте его как лендинг портфолио.
Создание первого проекта портфолио
Выбор целевого приложения
Тестируйте публично доступные приложения:
- SauceDemo (saucedemo.com) — простой e-commerce для базовой автоматизации
- The Internet (the-internet.herokuapp.com) — различные UI-задачи
- Restful Booker (restful-booker.herokuapp.com) — практика API-тестирования
- Pet Store API (petstore.swagger.io) — комплексное API-тестирование
Архитектура, которая впечатляет
Выйдите за рамки простых скриптов. Покажите понимание софтверной инженерии:
├── src/
│ ├── pages/ # Page Object Model
│ ├── api/ # API client wrappers
│ ├── fixtures/ # Управление тестовыми данными
│ ├── helpers/ # Утилиты
│ └── types/ # TypeScript интерфейсы
├── tests/
│ ├── e2e/ # End-to-end сценарии
│ ├── api/ # API-тесты
│ ├── visual/ # Визуальная регрессия
│ └── accessibility/ # Проверки доступности
├── reports/ # Сгенерированные отчёты
├── .github/workflows/ # CI-пайплайн
└── README.md
Типичные ошибки портфолио
Ошибка 1: Копирование кода из туториалов. Работодатели узнают код, скопированный из курсов. Пишите свои тесты.
Ошибка 2: Отсутствие README. Проект без документации выглядит незавершённым.
Ошибка 3: Только happy path. Тестирование только успешных сценариев показывает ограниченное мышление. Включайте граничные случаи и негативные тесты.
Ошибка 4: Устаревшие репозитории. Портфолио без коммитов 12 месяцев говорит о том, что вы перестали учиться.
Ошибка 5: Слишком много тривиальных репозиториев. Пять недоделанных проектов хуже одного качественного фреймворка.
Упражнение: Постройте фреймворк для портфолио
Создайте проект автоматизации для портфолио с нуля:
Шаг 1: Инициализация проекта
Настройте проект Playwright с TypeScript:
npm init playwright@latest portfolio-framework
cd portfolio-framework
Шаг 2: Реализуйте Page Objects
Создайте page objects для SauceDemo:
- LoginPage: взаимодействие с формой логина
- InventoryPage: список товаров и сортировка
- CartPage: управление корзиной
- CheckoutPage: поток оформления заказа
Шаг 3: Напишите тест-сюиты
Создайте тесты, покрывающие:
- Логин: валидные/невалидные данные, заблокированный пользователь
- Каталог: сортировка по имени/цене, добавление в корзину
- Корзина: добавление/удаление, расчёт цены
- Оформление: полный поток, валидация формы
Шаг 4: Добавьте CI/CD
Создайте .github/workflows/tests.yml с запуском на push и PR, HTML-отчётом и загрузкой артефактов.
Шаг 5: Напишите README
Задокументируйте: обзор проекта, tech stack, как запустить локально, архитектурные решения, настройку CI/CD.
Пример структуры README
# Фреймворк автоматизации E-Commerce
Комплексный фреймворк тестирования для SauceDemo на Playwright + TypeScript.
## Архитектура
- **Page Object Model** для поддерживаемости
- **Fixture-based setup** для изоляции тестов
- **API + UI** слои тестов
- **GitHub Actions CI** с параллельным выполнением
## Tech Stack
| Инструмент | Назначение |
|-----------|-----------|
| Playwright | Автоматизация браузера |
| TypeScript | Типобезопасность |
| Allure | Репортинг |
| GitHub Actions | CI/CD |
Советы из практики
Совет 1: Добавьте live-бейдж. Включите бейдж статуса GitHub Actions в README. Зелёный «passing» сразу сигнализирует, что тесты работают.
Совет 2: Пишите осмысленные сообщения коммитов. Работодатели могут просматривать историю коммитов.
Совет 3: Включите CONTRIBUTING.md. Даже для личного проекта это показывает, что вы думаете о совместной работе и стандартах.
Ключевые выводы
- Работающий фреймворк автоматизации на GitHub — самый ценный артефакт портфолио
- Структурируйте проекты как продакшен-код: page objects, CI/CD, репортинг, документация
- Избегайте типичных ошибок: копирование туториалов, отсутствие README, только happy path тесты
- Поддерживайте портфолио активным регулярными коммитами
- README так же важен, как код — он показывает навыки коммуникации и архитектурное мышление
- Качество важнее количества: один качественный проект лучше пяти недоделанных