Как перейти в QA-инженеры из другой профессии

Что действительно переносится

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

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

Участие в приёмочном тестировании (UAT) со стороны бизнеса, даже неформальное, ближе к QA, чем люди думают. Если вы когда-либо подписывали релиз, создавали тикеты для подрядчика или выполняли тест-скрипт, написанный кем-то другим, укажите это явно — это доказательство, а не просто интерес.

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

Что вам действительно нужно построить

Современная вакансия QA, даже начального уровня, обычно перечисляет какую-то комбинацию: баг-трекер (обычно Jira), инструмент управления тестированием, SQL для проверки того, что приложение фактически записало в базу данных, и фреймворк автоматизации — Selenium, Cypress или Playwright на Java, Python или JavaScript. Многие также упоминают тестирование API с Postman, некоторые — нагрузочное тестирование с JMeter или тестирование доступности по WCAG.

Вам не нужно всё это до подачи заявки. Вам нужно достаточно, чтобы пройти техническое собеседование и иметь на что указать. На практике это означает:

• Напишите тест-кейсы и тест-план для реального софта (свой проект, опенсорсный инструмент, что угодно с видимым поведением) и разместите где-то, где это можно посмотреть.
• Выучите один инструмент автоматизации как следует, а не несколько плохо. Playwright и Cypress — это то, что сейчас чаще всего просят в вакансиях в JavaScript-окружении; Selenium с Java всё ещё распространён в старых корпоративных стеках.
• Выучите достаточно SQL, чтобы написать join и фильтр. Работа QA включает проверку данных, а не только клики по кнопкам.
• Освойтесь с терминологией: регрессионное тестирование, smoke-тестирование, покрытие тестами, серьёзность дефекта против приоритета, идея shift-left о тестировании раньше в процессе разработки, а не в конце. Интервьюеры используют этот язык без объяснений, и незнание его читается как отсутствие опыта работы.

Если вы приходите из технической области — инженер поддержки, анализ данных, даже частичное образование в computer science — сторона автоматизации пойдёт быстрее, потому что написание кода не новое, новое только его применение. Если вы из нетехнической области, будьте честны с собой, что это медленная часть, и закладывайте реальные месяцы, а не курс выходного дня.

Нужна ли лицензия или квалификация?

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

Ближайший аналог признанного в индустрии сертификата — это ISTQB Foundation Level, выдаваемый International Software Testing Qualifications Board через национальные членские организации. Он охватывает стандартную терминологию и техники тестирования и действительно часто упоминается в вакансиях, особенно в Европе и в крупных процессно-ориентированных организациях.

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

Разумная позиция: если у вас пока нет других доказательств знания тестирования, сдайте ISTQB Foundation рано — это несколько недель учёбы — а затем потратьте основную часть усилий на портфолио, показывающее, что вы умеете это делать, а не просто определять.

Что ваша заявка действительно должна преодолеть

Две проблемы накладываются друг на друга для меняющего карьеру, и это разные проблемы.

Первая — это система отслеживания кандидатов. Вакансии QA всё чаще называют конкретные инструменты и годы опыта с ними — «3+ года Selenium», «опыт с Cypress и CI/CD pipeline» — и ATS часто фильтрует по точным совпадениям ключевых слов до того, как человек вообще увидит резюме. Если ваше резюме не содержит названий инструментов из вакансии, потому что вы действительно их ещё не использовали, никакое количество формулировок о переносимых навыках не пропустит вас на этом этапе. Это настоящий механический фильтр, не метафора, хотя насколько агрессивно его применяет система любого конкретного работодателя, варьируется и это невозможно проверить снаружи.

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

Практическое решение для обеих проблем одно: поместите названные инструменты и техники из вакансии в первую треть резюме или заявки, подкреплённые чем-то реальным, а не просто перечисленные как «знаком с». Однострочное описание проекта — «написал и автоматизировал 40 регрессионных тест-кейсов для Django-приложения с Playwright и Python, нашёл и зафиксировал 12 дефектов» — делает больше работы, чем пункт, заявляющий о внимании к деталям.

Честный таймлайн

Здесь два отдельных маршрута, и они занимают очень разное время.

Ручное и функциональное тестирование, без автоматизации — это более быстрая дверь. Если вы можете построить небольшое, но реальное портфолио — пару тест-планов, описание поиска багов, ISTQB Foundation — и подаёте заявки на позиции junior test analyst или QA analyst, а не на собственно «QA engineer», некоторые люди переходят за несколько месяцев, особенно если они могут сначала получить QA-смежную должность внутри своего текущего работодателя, что полностью обходит проблему резюме.

QA-инженерия с возможностью автоматизации — это более длинный маршрут, и вам следует относиться к этому как к обучению программированию с конкретной целью, а не лёгкому навыку для освоения на стороне. Добраться до точки, где вы можете писать поддерживаемый автоматизированный тест-сьют, отлаживать нестабильные тесты и убедительно говорить об интеграции тестов в CI/CD pipeline, обычно занимает большую часть года постоянной практики для человека без программистского бэкграунда — иногда дольше, если вы делаете это параллельно с полной занятостью.

Также стоит сказать прямо: рынок сдвинулся. Чисто ручные позиции тестирования вообще без ожиданий автоматизации сокращаются, поскольку компании сдвигают ответственность за тестирование раньше в разработку, и растущая доля вакансий «junior QA» уже перечисляет скриптовый язык как требование, а не приятное дополнение. Это не закрывает маршрут, но означает, что путь только через ручное тестирование — это более узкая дверь, чем раньше, и стоит направлять время обучения на автоматизацию с самого начала, а не относиться к ней как к второму этапу, до которого вы когда-нибудь дойдёте.

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

Выберите один инструмент автоматизации и один небольшой реальный проект и постройте портфолио до того, как отправите следующую заявку — резюме, заявляющее QA-навыки без чего-то, что их демонстрирует, это то, что сейчас отфильтровывается, а не отсутствие QA-должности. Сдайте ISTQB Foundation, если у вас нет другого сертификата, на который можно указать. Затем вернитесь к вакансиям, по которым вас уже отклонили, и проверьте, инструмент за инструментом, содержало ли ваше резюме действительно слова, по которым они фильтровали.

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