Как составить резюме для позиции QA-инженера

На что менеджер по найму смотрит в первую очередь

Человек, нанимающий QA-инженера, не читает ваше резюме с начала до конца при первом просмотре. Он ищет три вещи примерно в таком порядке: что вы тестировали (область — финтех, здравоохранение, e-commerce, встроенные системы, игры), как вы это тестировали (вручную, автоматизированно или и то, и другое, и на каком уровне — модульное, API, UI, end-to-end), и чем вы это тестировали (конкретные инструменты, указанные в их стеке). Если эти три вещи не видны в первой трети страницы, резюме откладывают в сторону, потому что у читателя стопка таких резюме, а в вакансии конкретные инструменты названы не просто так.

Вот почему фраза «внимательный к деталям командный игрок с сильными коммуникативными навыками» в начале резюме QA — пустое место. Она не сообщает читателю ничего, что он не может предположить сам, и сдвигает полезную информацию — Selenium, Playwright, Postman, что бы это ни было — дальше вниз по странице, где её можно пропустить при беглом просмотре.

Укажите свой стек автоматизации и область тестирования в первых нескольких строках — либо как краткое резюме, либо как строку навыков прямо под именем. Не облако навыков с сорока инструментами в алфавитном порядке — несколько тех, которые вы реально использовали в продакшене, с достаточной конкретностью, чтобы читающий сразу понял, пересекаетесь ли вы с их стеком.

Квалификации и сертификаты: что они на самом деле сигнализируют

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

ISTQB Foundation Level (и более высокие уровни Advanced и Expert, если они у вас есть) — это сертификат, который с наибольшей вероятностью будет узнан с первого взгляда менеджером по найму в QA, потому что это самое близкое к общему словарю, что есть в этой области — уровни тестирования, типы тестирования, жизненный цикл дефекта, терминология, используемая в тест-планах. Он сам по себе не приведёт вас на собеседование, но не указывать его, если он у вас есть — ошибка: некоторые ATS и некоторые менеджеры по найму действительно фильтруют по нему.

Помимо ISTQB, большее значение имеют специфичные для инструментов и облачных платформ сертификаты, которые напрямую соответствуют вакансии: сертификаты AWS или Azure, если роль касается тестирования облачной инфраструктуры, Certified Selenium Professional или подобные, если автоматизация — центральная часть работы, сертификаты по тестированию безопасности вроде OSCP или CEH, если в роли есть компонент тестирования безопасности (всё чаще встречается в вакансиях QA, где запрашиваются навыки, близкие к пентесту). Перечисляйте их рядом с именем или в короткой строке «сертификаты», а не в конце раздела образования — менеджер по найму, сканирующий резюме на конкретный сертификат, названный в вакансии, сначала посмотрит вверху.

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

Как продемонстрировать свой опыт тестирования

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

Что менеджер по найму QA хочет видеть для каждой роли — это некоторая комбинация следующего:

• Что вы тестировали и на каком уровне — модульное, интеграционное, API, UI, end-to-end, производительность, безопасность, доступность. Указание уровня говорит читателю, где вы находитесь в пирамиде тестирования, а это реальное различие в этой области и влияет на то, что роли действительно нужно.
• Что вы нашли и что с этим случилось. Не просто счётчик дефектов (большое количество багов может означать тщательное тестирование или плохо построенную функцию — это не читается однозначно позитивно), а форма работы: какие классификации по серьёзности вы использовали, как сортировались дефекты, писали ли вы шаги воспроизведения, которые позволили быстрее выпустить исправление.
• Что вы автоматизировали, и было-стало. «Сократил цикл регрессии с трёх дней ручного выполнения до двухчасового автоматизированного набора» — конкретно и проверяемо на собеседовании, именно поэтому это работает лучше, чем «улучшил эффективность тестирования».
• Покрытие, где вы можете указать его честно. Проценты покрытия тестами обычно приводятся в резюме QA, но они — приближённый показатель тщательности, а не доказательство её — менеджер по найму, который делал эту работу, спросит, что измерял инструмент покрытия и было ли это покрытие строк, ветвей или требований. Если вы приводите цифру, будьте готовы сказать, что она измеряла.
• Ваша позиция в процессе релиза. Владели ли вы подписанием релиза или выполняли тест-кейсы, написанные кем-то другим? Писали ли вы тест-план или следовали готовому? Это один из самых чётких сигналов сениорности в QA, и он обычно остаётся неявным, а не прямо указанным.

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

Инструменты, фреймворки и словарь, которые должны быть в этом резюме

Общее «владею инструментами тестирования» невидимо. Называйте реальный стек, потому что названия инструментов выполняют реальную фильтрующую работу — как для человека, просматривающего страницу, так и для любого поиска по ключевым словам в ATS.

Фреймворки и инструменты автоматизации: Selenium, Playwright, Cypress, Appium (для мобильных), TestNG, JUnit, PyTest — и на каком языке вы их использовали, потому что просто «Selenium» не говорит читателю, писали ли вы на Java, Python или C#.

Тестирование API и сервисного слоя: Postman, REST Assured, SoapUI — указывайте их отдельно от автоматизации UI, потому что тестирование API и UI — это разные навыки, и вакансия, где указано одно, говорит вам, что именно им нужно.

CI/CD и интеграция с пайплайнами: Jenkins, GitHub Actions, GitLab CI, CircleCI. Указание, что ваш автоматизированный набор запускался как часть пайплайна, а не вручную, сигнализирует о более зрелой практике тестирования, чем отдельный скрипт, запущенный вручную.

Управление дефектами и тестами: JIRA (и конкретно, использовали ли вы Xray или Zephyr вместе с ней), TestRail, qTest. Их стоит называть, потому что разные QA-команды стандартизируются на разных инструментах, и знакомство с конкретным инструментом из вакансии снимает трение адаптации, о котором думает менеджер по найму.

Тестирование производительности и нагрузки: JMeter, Gatling, k6 — стоит вынести отдельной строкой, если оно у вас есть, так как это отдельный набор навыков от функционального тестирования и часто то, что отделяет middle QA-инженера от senior.

Тестирование доступности: axe, WAVE или ручное тестирование соответствия WCAG — всё чаще запрашивается и редко указывается, что делает это стоящим упоминания, если вы это действительно делали.

Контроль версий и словарь окружений: Git, Docker, staging против production окружений, feature flags. QA-инженеры, которые могут говорить о том, как они тестировали в разных окружениях, а не только что тестировали, читаются как более сениорные.

Что пропускают, а не следовало бы

Несколько вещей, которые QA-инженеры регулярно опускают не из-за нечестности, а потому что не думают их упоминать:

Масштаб того, что вы тестировали. Количество поддерживаемых тест-кейсов, размер регрессионного набора, количество окружений или комбинаций браузеров/устройств, которые покрывались. Эти цифры конкретны и дают менеджеру по найму представление о размере операции без необходимости спрашивать.

Работали ли вы в Agile-команде и какой была ваша роль в цикле спринта — написание критериев приёмки, тестирование внутри спринта или после, участие в планировании спринта или ретроспективах. Вовлечённость QA в Agile-церемонии сильно различается между компаниями, и это стоит указать, а не предполагать.

Кроссфункциональная работа с разработчиками. Работали ли вы в паре с разработчиками над test-driven development, ревьюили ли pull request'ы, писали ли тесты, которые запускались как часть рабочего процесса самого разработчика, а не отдельного QA-прохода. Это различие — QA как барьер в конце против QA, встроенного в разработку — это то, на что менеджеры по найму активно фильтруют, и это редко указывается прямо.

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

Что делать дальше

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

Если вы отправляете резюме быстрее, чем можете адаптировать их к тому, что конкретно запрашивает каждая вакансия — обычно оттуда и идёт тишина, а не от качества работы за резюме. jobmarket.pro читает каждую вакансию полностью, сопоставляет её с одним профилем, в который он не может выдумать опыт, и готовит заявку на основе этого.