Главная · Блог о тестировании ·
Портфолио тестировщика без опыта: готовый пример и шаблон
Хорошее портфолио позволяет быстро проверить, как ты понимаешь продукт, выбираешь проверки, собираешь доказательства и объясняешь риск. Ниже — цельный пример учебного проекта и разбор решений. Он не выдаётся за коммерческий опыт.
| Артефакт | Разумный объём | Что поймёт ревьюер |
|---|---|---|
| Описание продукта | Одна страница | Ты понимаешь пользователей, правила и риск |
| Чек-лист и кейсы | 10–20 проверок, 3–5 кейсов | Ты выбираешь покрытие и expected results |
| Багрепорты | 2–3 реальные воспроизводимые находки | Ты исследуешь и точно передаёшь результат |
| API и SQL | Один связанный сценарий | Ты проверяешь контракт и сохранённое состояние |
| Автоматизация | 3–8 стабильных проверок | Ты пишешь поддерживаемый код под понятный scope |
| Test summary | Одна страница | Ты сообщаешь об уверенности и остаточном риске |
Готовый пример: одно расследование оформления заказа
Этот вымышленный учебный репозиторий проводит один риск от интерфейса до API и сохранённых данных. Важен не объём файлов, а проверяемая цепочка от правила продукта к наблюдаемому результату.
qa-bookshop-portfolio/ ├── README.md ├── docs/ │ ├── scope-and-risks.md │ ├── checkout-checklist.md │ ├── test-cases.md │ └── bug-reports/BUG-001-empty-cart-order.md ├── api/bookshop.postman_collection.json ├── sql/order-integrity.sql ├── tests/checkout.spec.ts └── reports/test-summary.md
Продукт: учебный книжный магазин QA Job Simulator Объём: заказ с пустой корзиной и сохранение заказа Риск: пустой заказ сохраняется и попадает в обработку заказов Разрешение: собственная учебная среда Цепочка: чек-лист -> API-запрос -> SQL-проверка -> BUG-001 Результат: POST /orders вернул 201 и сохранил total=0 Ограничения: без нагрузки, security и чужого production
BUG-001 · POST /orders создаёт заказ для пустой корзины
Среда: учебный стенд, сборка 2026.10.25
Условие: пользователь авторизован; корзина пуста
Шаги: отправить POST /orders тестовым аккаунтом
Требование: AC-ORD-04 — в корзине нужен хотя бы один товар
Шаги: POST /qa-lab/api/v1/orders с {}; затем GET /orders
Ожидание: 422; заказ не возвращается и не сохраняется
Факт: 201; order_id=8412; items_count=0; total=0
Повторяемость: 3/3 на сборке 2026.10.25
Доказательства: очищенный HTTP, correlation_id и read-only SQL
Что доказывает пример
Требование задало ожидаемый результат, POST и последующий GET показали внешнее поведение, а разрешённый read-only запрос подтвердил строку в базе. В скачиваемом наборе есть каждый упомянутый файл. Вывод узкий: сценарий сломан в этой сборке; оплата, остатки и другое поведение не проверялись.
1. Определить, что именно должно доказать портфолио
Рекрутер быстро проверяет соответствие роли, а QA lead — мышление и коммуникацию. Учти обоих: на первом экране укажи целевую роль, продукт, scope и сильнейшее доказательство; глубже покажи путь к выводу. Не заставляй ревьюера восстанавливать историю по папке на диске.
Портфолио должно быстро ответить на четыре вопроса: что проверялось, какой риск получил приоритет, что было обнаружено и как это проверить другому человеку. Сертификаты и логотипы инструментов дают контекст, но не отвечают на эти вопросы. Доказательству нужны правило продукта, действие, ожидаемый результат и исход.
- Сначала видны целевая роль и контекст продукта.
- У каждого артефакта есть цель в одном предложении.
- Ссылки открываются без запроса доступа.
- Даты и учебный контекст указаны честно.
2. Выбрать легальный и ограниченный продукт для тестирования
Используй учебный стенд, своё приложение, open-source проект с правилами участия или публичное demo, где разрешено обычное использование. Не проводи нагрузочные, security или разрушающие проверки чужого production без явного разрешения. Портфолио должно показывать зрелость, в том числе понимание границы, где тест остановить.
Выбери один сценарий с видимыми бизнес-правилами и несколькими слоями: регистрация, каталог и checkout, бронирование, подписка или права аккаунта. Зафиксируй окружение и версию, тестовые аккаунты, источник данных и исключения. Узкий scope позволяет думать глубже, чем заявление «протестировал весь большой сайт».
Контрольная точка портфолио
Напиши scope statement в восемь строк: продукт, build, сценарий, включённые слои, исключённые виды тестирования, источник данных и основание разрешения.
3. Показать тест-дизайн, а не стопку документов
Начни с рисков и модели фичи, затем составь короткий чек-лист. Подробные кейсы оставь для критичных или неоднозначных путей. В каждом укажи предусловия, точные данные, шаги, expected result и важные побочные эффекты. Добавь позитивное, негативное и зависящее от состояния поведение вместо двадцати повторов валидации поля.
Сделай выбор видимым: отметь технику, которая сформировала группу проверок, и то, что сознательно осталось вне scope. Пять обоснованных значений возле границы говорят больше пятидесяти случайных input. Если требование неясно, запиши вопрос и варианты ожидания вместо выдуманной уверенности.
4. Добавить реальные находки с воспроизводимыми доказательствами
Хороший багрепорт для портфолио содержит окружение, предусловия, точные шаги и данные, expected и actual result, частоту и вложения. Используй correlation id, очищенный request или короткую запись, если они помогают. Никогда не публикуй пароли, рабочие token, персональные данные или закрытую информацию компании.
Не выдумывай дефекты ради объёма. Если продукт стабилен, опиши расследование, подтвердившее правило, или неоднозначное требование, которое удалось прояснить. Один неочевидный state или integration defect с сильными доказательствами убедительнее десяти косметических наблюдений с меткой critical.
Контрольная точка портфолио
Проверь два своих отчёта: сможет ли незнакомый человек воспроизвести дефект, найти нарушенное правило и увидеть evidence, не спрашивая у тебя секреты и контекст?
5. Связать доказательства из UI, API и данных
Сильный технический пример проводит одно бизнес-действие через несколько слоёв. Покажи input в UI, HTTP request и response, конечное состояние через публичный GET или разрешённый read-only SQL. Объясни, что покрывает каждая проверка и почему один зелёный ответ не подтверждает все side effects.
Сделай коллекции Postman, SQL и логи читаемыми. Используй environment variables с примерными значениями, удали секреты, форматируй запросы и указывай expected results. Если репозиторий не запускается без твоего личного аккаунта, его нельзя проверить. Fixtures и скриншоты должны помогать, а не заменять инструкцию.
6. Добавить небольшой automation-проект, только если он поддерживаемый
Автоматизация необязательна для manual-роли и полезна, если её ждут в вакансии. Выбери несколько стабильных проверок, используй ясные locators и assertions, изолируй данные и обеспечь запуск одной командой. В README укажи setup, версии инструментов, архитектуру, scope тестов и пример отчёта.
Сгенерированный код — черновик, а не доказательство навыка. Убери дублирование, объясни fixtures и waits, сделай падения диагностируемыми через traces или logs. Ревьюер должен клонировать repository, поставить зависимости и запустить тесты без поиска скрытого credential или локального пути.
Контрольная точка портфолио
Дай репозиторий другому человеку только с README. Зафиксируй каждый пропущенный setup step, flaky result и неясный assertion, затем исправь инструкцию и suite.
7. Опубликовать путь просмотра на две минуты
Используй GitHub repository, простой сайт или оба варианта. В корневом README дай контекст продукта, scope, окружение, карту доказательств, главные находки, ограничения и способ запуска кода. Самый сильный артефакт поставь первым. Глубокие папки и декоративные dashboard тормозят ревьюера с ограниченным временем.
До добавления ссылки в CV открой её в incognito и на телефоне. Проверь права, битые ссылки, имена файлов, язык и редактирование чувствительных данных. Попроси QA-специалиста потратить ровно две минуты и описать, что ты умеешь; исправь путь, если его вывод отличается от задуманного.
- README начинается с контекста и результата.
- У артефактов единые имена и даты.
- В истории нет secret и персональных данных.
- У каждого скриншота есть смысл и читаемый масштаб.
- Repository запускается документированными командами.
Портфолио QA: частые вопросы
Нужно ли manual QA портфолио?
Это не универсальное требование найма. Но начинающему компактный набор доказательств помогает показать практические навыки. Соизмеряй усилия с целевым рынком и не откладывай реальные отклики бесконечной полировкой сайта.
Можно ли указать учебный проект в разделе опыта работы?
Называй его проектом, обучением или самостоятельной практикой, если это не было трудоустройством или контрактом. Честный контекст сохраняет доверие и не мешает разбирать технические решения и результат.
Нужно ли добавлять все созданные документы?
Нет. Оставь небольшой набор лучших работ, а слабые и повторяющиеся черновики убери в архив. Цель — быстро показать текущий уровень, а не доказать выполнение каждого упражнения.
Можно ли использовать AI для материалов портфолио?
AI может помочь отревьюить текст или предложить варианты, но каждое правило, результат и строку кода нужно проверить самостоятельно. Указывай существенную помощь, когда это важно, и не публикуй сгенерированные доказательства тестов, которые не выполнялись.
Убедительное портфолио начинающего не притворяется уже полученным опытом. Это короткая проверяемая запись подхода к работе: контекст, риск, проверка, доказательство, вывод и честные ограничения.