От ручного QA к автоматизации: как нанимать и как растить своих

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

От того рынка не осталось и следа.

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

Параллельно складывается другая картина: каждый второй CTO, с которым нам приходилось общаться за последние полгода, рано или поздно задаёт один и тот же вопрос — «У нас в команде есть отличные QA, которые сами рвутся в автоматизацию. Может, просто обучим их и не будем никого нанимать со стороны?».

Иногда это оказывается самым умным решением за весь год. А иногда — после восьми месяцев попыток, разочаровавшихся людей и подорванного доверия — вы всё равно идёте искать специалиста извне.

Главное — научиться отличать одну ситуацию от другой ещё до того, как вы успели потратить на ошибку полгода.

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

Почему всё стало сложнее

На рынке одновременно случилось несколько процессов, которые работают друг на друга, а не в нашу пользу.

Во-первых, сама роль заметно преобразилась. То, что когда-то называлось «человек, который пишет Selenium-скрипты», постепенно превратилось в инженера, отвечающего за CI-пайплайны, разбирающегося с API-контрактами и периодически залезающего даже в инфраструктурный код. Одни компании, понимая это, называют такую роль SDET и платят соответственно. Другие предпочитают писать вакансию на «Automation QA Engineer» и при этом рассчитывают платить на 30% меньше за тот же объём ответственности, — после чего удивляются, почему их вакансии висят без откликов месяцами.

Во-вторых, рынок стал глобальным, а вместе с тем — гораздо более разнообразным. По данным Stack Overflow Developer Survey, QA-позиции из года в год входят в число самых трудных для закрытия, а удалёнка добавила к этому процессу свою специфику: ваш кандидат, сидя в Минске или Тбилиси, может спокойно принять оффер из Берлина или Сан-Франциско, не складывая при этом ни одной вещи.

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

Так что в сухом остатке это давно не проблема найма как такового, а вопрос организационной стратегии, который всего лишь маскируется под кадровый.

Что вообще скрывается за словами «QA-автоматизатор» в 2026 году

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

1. SDET. По своей сути это разработчик, который занимается тестами: строит фреймворки, контрибьютит в продуктовый код, живёт в пул-реквестах. Зарплатная вилка у него стоит рядом с бэкендером сопоставимого грейда.
2. QA Automation Engineer. Силён в коде, однако фокус его внимания — тест-дизайн и прогон тестов, а не продуктовая разработка. Отвечает за тестовый код, а не за код приложения. По факту большинству команд нужен именно такой специалист — а вакансию по привычке пишут на SDET, и этот нюанс обходится компании ровно в годовую зарплату, переплаченную впустую.
3. QA-лид с гибридным бэкграундом. Тот самый человек, который вырос из ручного тестирования, со временем освоил автоматизацию, а теперь ведёт небольшую команду. Кадр редкий и ценный и почти всегда не нанятый со стороны, а развитый внутри.

А теперь — реалистичный чек-лист по навыкам, которые действительно требуются:

• Один язык программирования, на котором кандидат реально писал продакшен-код, — Python, JavaScript, Java или C#. Не «знакомство», не «понимание основ», не «изучал на курсах», а живой код, который где-то работал и который вы при желании можете проверить.
• Современный фреймворк автоматизации — Selenium, Playwright или Cypress: в новых проектах сейчас доминирует Playwright, тогда как legacy по-прежнему держится на Selenium.
• Тестирование API — обычно Postman для ручной части и REST-assured (либо аналог) на уровне кода.
• Git, основы CI/CD и базовый SQL — без компромиссов.
• Понимание теории тестирования — достаточное для того, чтобы аргументированно объяснить, что стоит автоматизировать, а что нет. 

Сертификат ISTQB Foundation служит неплохим косвенным признаком, что человек подучил теорию. Однако многие сильные автоматизаторы его никогда не сдавали — поэтому делать этот сертификат обязательным требованием не стоит ни при каких обстоятельствах.

Путь А: найм со стороны

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

Сроки

На рынке найм сеньора-автоматизатора занимает 6–9 недель с момента открытия вакансии до подписанного оффера. Мидл вакансия закрывается за 4–6 недель. Если же вам нужно, чтобы человек писал тесты уже через три недели, то это уже не классический найм, а аутстафф, либо работа с рекрутером, у которого уже есть готовая база проверенных кандидатов. Третьего варианта здесь не существует, и тот, кто его вам обещает, либо переоценивает свои силы, либо просто врёт.

Где искать

Если речь идёт о найме в команду на территории СНГ или Восточной Европы, картина рынка достаточно прозрачная. Беларусь, Польша, Украина, Россия, Казахстан давно сложились в кадровый резерв для западных продуктовых команд: сильная техническая база (значительная часть автоматизаторов приходит из физмата или из смежных инженерных специальностей), хороший рабочий английский и зарплаты, которые при сопоставимом уровне навыков остаются на 30–50% ниже западноевропейских. За годы работы мы закрыли сотни QA-вакансий в этом регионе под команды в США и ЕС, а в нашем зарплатном исследовании можно посмотреть реальные цифры с фильтрацией по грейдам и стекам.

Описание вакансии, которое не отпугнёт сильных кандидатов

• Сократите список обязательных требований ровно вдвое. Когда в вакансии 14 пунктов «должен знать», сильный кандидат делает простой вывод — вам нужен единорог, — и проходит мимо, не читая описание до конца.
• Будьте максимально конкретны со стеком. Формулировка «опыт работы с различными фреймворками тестирования» не несёт ровным счётом никакой информации. А вот «у нас Playwright + TypeScript, тесты гоняем в GitHub Actions, ищем человека, который сможет расширить наш текущий Page Object» — это всё, что нужно знать кандидату, указанное в одном предложении.
• Начинайте с задач, а не с перечня плюшек. Инженеры, а особенно сильные, не меняют работу ради компенсации за спорт.

Собеседования, которые реально помогают

Про задачи на логику можно смело забыть, так как работает совершенно другое:

• Этап 1. Совместное код-ревью реального (или максимально близкого к реальному) тестового сьюта. Попросите кандидата рассказать, что бы он переделал и почему, — за двадцать минут такого разговора о его мышлении станет понятно больше, чем за всё остальное собеседование, вместе взятое.
• Этап 2. Небольшое live-задание — расширить фреймворк, починить флакующий тест или написать тест на конкретный user story. От 60 до 90 минут, не больше, и обязательно в формате парного программирования, а не «вот вам доска, решайте».
• Этап 3. Поведенческое интервью. Спросите про релиз, который по-хорошему должны были заблокировать, но не заблокировали. Про флакующий тест, с которым приходилось воевать неделями. Про то, как кандидат объясняет разработчику, что код пора писать более тестируемым, — желательно без перехода на личности.

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

Красные флаги, которые лучше замечать пораньше

• Уверенно перечисляет инструменты и фреймворки, но затрудняется объяснить, почему для конкретной задачи он выбрал бы именно Playwright, а не Selenium (или наоборот).
• Нет ни публичного кода, ни активного GitHub, ни одного готового примера. А обезличить хотя бы небольшой фрагмент рабочего кода — «не может». У сильного инженера всегда находится, чем поделиться, даже если основной проект под NDA.
• Относится к ручным тестировщикам с лёгким презрением, как ко второму сорту. Такой настрой — это яд, который отравляет команду быстрее любого сорванного дедлайна.

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

Путь Б: развитие своих

Путь сложнее. И, как правило, гораздо результативнее. Просто почти никто не делает его правильно с первого раза.

Кто реально подходит на роль автоматизатора

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

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

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

Шестимесячный план обучения — честная версия

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

Это не обучение. Это плановое выгорание, расписанное на полгода вперёд.

Сколько такой переход стоит на самом деле

• Время обучающегося — примерно 10–15 часов в неделю на протяжении шести месяцев.
• Время сеньора-ментора — 3–5 часов в неделю, которые уходят на код-ревью, парную работу и ответы на вечный вопрос «почему этот тест опять флакует».
• Бюджет на обучение — $500–1500 на человека: Test Automation University бесплатный и при этом действительно хороший, тогда как профильные курсы по Playwright или Selenium обойдутся в $50–200 каждый.
• Полная стоимость со всеми накладными расходами выходит примерно в $8 000–15 000 на человека.

Для сравнения — полная стоимость найма сеньора-автоматизатора со стороны, с учётом всех расходов и времени, потраченного на сорсинг, доходит до $80 000–150 000. Так что арифметика тут получается, мягко говоря, однобокая.

Почему внутренний переход всё равно чаще всего проваливается

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

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

Так какой путь в итоге выбирать?

Короткая шпаргалка, в которой вы найдете строчку, которая точнее всего описывает вашу текущую ситуацию.

• Если автоматизация должна заработать в течение трёх месяцев — нанимайте. И не уговаривайте себя, что обучение пойдёт быстрее: не пойдёт.
• Если у вас есть полгода в запасе и пара ручников с нужными навыками — растите своих. Когда такой подход срабатывает, экономия перекрывает всё остальное с большим запасом.
• Если нужны три и больше автоматизаторов — комбинируйте оба пути. Один сильный сеньор, нанятый со стороны, плюс двое внутренних ручников в роли его подопечных. Этот сеньор одновременно становится и архитектором, и ментором, что даёт самый высокий ROI среди всех вариантов QA-найма.
• Если в команде нет ни одного сеньора-автоматизатора, который мог бы менторить новичков — сначала наймите. Растить начинайте уже после, опираясь именно на этого сеньора. Без ментора внутри попытка вырастить своих автоматизаторов проваливается практически гарантированно.

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

Большинство компаний промахиваются с выбором пути по одной и той же причине: они оптимизируют по одному параметру в отрыве от остальных — то исключительно по бюджету, то исключительно по срокам. Правильный же вопрос звучит не «как сделать дешевле прямо сейчас?», а «во что нам обойдётся ошибка, обнаруженная через девять месяцев?».

Гибрид, который почти все упускают из виду

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

Работает такая модель только в одном случае, если вы заложили её в план с самого первого дня. Менторство прописано в описании вакансии. Менторство учитывается в KPI. На него отведено время. И зарплата у этого сеньора рассчитана как у мультипликатора, которым он по факту и является.

Однако, когда вы наняли сеньора и про себя надеетесь, что он будет менторить «в свободное время», это не сработает. Не будет. Он сделает ровно то, на что его формально нанимали, после чего уйдёт на ближайший Staff-оффер — как только осознает, что обещанного лидерского роста ему здесь не видать.

Кратко

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

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