QA-резюме читают по артефактам. «Внимательный, ответственный, знаю виды тестирования» не закрывает сомнение. Рекрутер ищет контур: web, API, mobile; как выглядит баг-репорт; был ли регресс; есть ли автоматизация в проде или только курс Selenium.
Ниже — как собрать резюме QA-инженера: роль без притворства SDET, тестовая документация, пули опыта, два заполненных примера, что не писать про «полный цикл разработки». Общий каркас — в как составить резюме. Формула пункта — в как описать опыт. Вход без штата — в резюме без опыта и в как стать QA-инженером.
Коротко:
- Заголовок = QA + тип: ручной web, API, mobile, не «инженер по качеству» без контура.
- Автоматизацию пишите только если гоняете её на CI или готовы к тестовому на ней.
- Ссылка на 2–3 лучших отчёта сильнее сертификата ISTQB без папки.
- Пули: сценарий, баг, регресс, окружение, эскалация в разработку — не «проводил тестирование».
- Не копируйте теорию тест-дизайна в навыки: её и так ждут, факта в этом нет.
Как читают QA-файл за 15 секунд
На вакансиях QA решают:
- Ручной, автоматизация или смесь? Файл должен совпасть со слотом.
- Какой продукт: web-сервис, API, мобилка, 1С, игры?
- Есть ли артефакт: кейсы, чек-листы, баг-репорты, Allure, не «умею писать тест-кейсы».
- Не притворяется ли ручной тестировщик SDET из‑за слова Selenium в шапке?
- Готов ли человек к тестовому на вашем контуре на этой неделе?
Смешение «QA / аналитик / поддержка / немного Python» в одном заголовке кладёт файл в никуда. Карточка роли — в резюме IT-специалиста. Если цель — автотесты, это другая история и другой акцент: см. как стать автотестировщиком и резюме автотестировщика, когда будете собирать отдельный файл.
Структура резюме QA
Шапка: роль, контур, город / UTC, контакты, одна ссылка на папку с отчётами или репозиторий автотестов. Summary: 4–6 строк — продукт, типы тестов, один сильный факт. Опыт. Навыки группами: платформы, инструменты отчёта, API, SQL если пользуетесь, автоматизация отдельно. Образование внизу.
Не ставьте ISTQB и десять курсов на первый экран. Сертификат можно строкой внизу, если есть. Артефакт — наверх. Как собрать summary — в summary в резюме. Навыки без простыни теории — в навыках QA и в стеке в резюме.
Папка с 80 кейсами хуже трёх сильных отчётов в шаблоне «шаги / ожидание / факт / окружение / вложения». Drive без подписей не открывают. Персональные данные клиентов вырежьте. Учебный сервис так и подпишите.
Заголовок: не притворяйтесь SDET
Честные варианты: «QA, ручной web», «QA, web + API», «QA, mobile Android», «QA automation, Python / pytest, web». Не «QA Engineer / SDET / тестировщик / аналитик качества».
Было. Инженер по обеспечению качества. Знание полного цикла SDLC. Виды тестирования, тест-дизайн, гибкие методологии. Selenium, Postman, Jira, SQL, Python, Jenkins, Docker. Внимателен к деталям.
Стало. QA, ручной web + API. Сервис заказов: регресс по чек-листу, баг-репорты в шаблоне команды. Папка с 3 отчётами: [ссылка]. Автотестов в проде нет — в шапке Selenium нет. Минск / UTC+3.
Вторая шапка можно звать. Первая обещает созвон по CI и PageObject, которого не было. Расхождение вскрывается на тестовом и жжёт репутацию быстрее, чем «просто ручной QA».
Как писать опыт тестирования
Не «проводил функциональное и регрессионное тестирование». Пишите контур и эффект:
- какой сценарий закрывали (заказ, оплата, регистрация, роль админа);
- как баг доходил до разработки без переспроса;
- регресс: чек-лист, срок, что перестало отваливаться перед релизом;
- окружения: тест, стейдж, что делали, когда данные расходились;
- API: какой контракт проверяли, чем (Postman/коллекция), какой баг поймали;
- автотесты: что именно гоняется на CI, что падает, кто чинит.
Цифры без вранья: 18 сценариев, 11 багов за итерацию, регресс с полудня до часа, флаки в ночном прогоне. «Повысил качество продукта на 50%» не пишите. Типичные пустые формулировки — в ошибках в резюме.
Пример 1. Junior, ручной web, без штата
Вакансия: junior QA, веб-сервис, баг-репорты, чек-листы, тестовое на описание бага.
Junior QA, ручной web. Учебный сервис доставки. 18 сценариев, 11 баг-репортов — [папка]. Коммерческого штата нет.
Собрал чек-лист заказа: создание, отмена, повтор, ошибка слота. Отделил баг от пожелания: «нет тёмной темы» в отчёты не клал.
Шаблон отчёта: шаги, ожидание, факт, окружение, скрин, версия. Разработка по учебным отчётам не переспрашивала, где кликать.
Нашёл расхождение статуса заказа в списке и в карточке после отмены. Описал как дефект данных, не как «что-то не так».
К тестовому на вашем сервисе готов на этой неделе. Автоматизации нет, Postman на курсе — не навык в шапке.
Это закрывает входной слот. Не дописывайте Python «для солидности». Если за неделю можете собрать пять запросов к учебному API — тогда отдельной строкой в навыках, не в заголовке.
Пример 2. QA в продукте, регресс и API
Вакансия: QA, web+API, релизный цикл, Jira, без обязательного SDET.
QA, web + API, кабинет B2B. 2 года. Remote, UTC+3. Примеры отчётов без ПДн: [ссылка].
Вёл регресс оплаты перед релизом: чек-лист из 24 шагов, срок с полудня до ~1 часа за счёт выкинутых дублей и стабильных тестовых карт.
Ловил расхождение статуса оплаты между кассой и кабинетом. Отчёт: запрос, ответ, id платежа, шаги в UI. Разработка чинила без «не воспроизводится».
Коллекция Postman на критичные методы заказа: 401, пустое тело, повторный POST. Это не автотесты в CI — в файле так и написано.
Онбординг новичка QA: шаблон бага и доступы к стейджу. Не обещаю Selenium: прогон на CI ведёт другая роль.
Честная граница по автоматизации здесь важнее, чем слово «инженер». Вас позовут на ручной+API слот, а не провалят на live-coding драйвера.