Интервью с Иваном Кузиным: как в 2025 году нанимают тестировщиков и почему одних только баг-репортов уже недостаточно?

ИТ-рынок в России возвращается к росту, компании снова расширяют команды, но нанимать тестировщиков «как раньше» уже не получается. Собеседования стали жестче, процессы — взрослее, а требования к QA-инженерам сильно изменились.

Мы поговорили с Иваном Кузиным, руководителем команды SaveLink, о том, как в 2025 году оценивают кандидатов, какие навыки уже не считаются конкурентным преимуществом и почему софт-скиллы перестали быть «приятным бонусом» и превратились в обязательное условие.

Что сейчас считается «обязательной базой» для тестировщика, а что уже выглядит как артефакт прошлого?

Иван: В SaveLink смотрят не на красивые слова в резюме, а на то, как человек решает реальные задачи.

Если обобщать, нас интересует не то, сколько инструментов кандидат может перечислить, а то, умеет ли он думать как инженер и как член продуктовой команды. Тестирование перестало быть «отдельным царством» в конце цепочки разработки.

Без каких практических навыков сложно пройти отбор?

Иван: Для российских ИТ-компаний сегодня по-настоящему важны несколько практических компетенций:

• Аналитические навыки: Умение погрузиться в бизнес область и составить оптимальный тест-дизайн

Важно не просто знать базовые техники, а уметь ими пользоваться. Кандидат должен уметь декомпозировать требования и пользовательские сценарии, выделять критические пути (happy path, edge cases, негативные сценарии) и приоритизировать тесты по рискам и влиянию на бизнес.

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

• Понимание архитектуры клиент-серверных приложений

Речь не о том, чтобы уметь с нуля написать бэкенд, а о базовой технической грамотности. QA-инженер должен понимать, как устроен клиент–сервер и HTTP, что такое API и чем REST отличается от GRPC, что такое база данных на уровне сущностей, связей и простых запросов, а также как работают сессии, авторизация и кеширование.

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

• Уверенная работа с инструментами для API-тестирования и логирования

В SaveLink на собеседованиях часто проверяют базовую практику. Кандидату нужно уметь составлять запрос в Postman/SoapUI или аналогичных инструментах, читать JSON-ответы и заголовки, понимать статусы 2xx / 4xx / 5xx и типичные ошибки, а также искать информацию в логах, например по trace ID, user ID или конкретному запросу.

В 2025 году специалист, который не умеет работать с API и логами, сильно проигрывает на старте. Даже если позиция формально для ручного тестировщика.

• Автоматизация как инструмент, а не самоцель

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

При этом важнее всего остается не набор фреймворков, а понимание, что и зачем автоматизировать: регресс, smoke и критические флоу.

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

• Работа в CI/CD-контуре и культура командной разработки

Даже для уровня middle сейчас крайне желательно понимать, как тесты вписываются в пайплайн (GitLab CI, GitHub Actions, Jenkins и другие), знать базовые Git-флоу (feature-ветки, code review, pull/merge requests), различать среду разработки, тестовые и продакшн-окружения и осознавать их назначение.

Что уже не производит впечатления и даже может насторожить при выборе специалиста?

Иван: Есть набор «классики», которая еще 5–7 лет назад выглядела как сильное преимущество, а сейчас воспринимается как базовый фон. Более того, иногда чрезмерный акцент на этом настораживает.

Десятки инструментов в резюме без реальной практики. Часто в резюме перечислено 15 и более инструментов, от Selenium до JMeter, но на собеседовании кандидат не может объяснить, какие реальные задачи он с их помощью решал. Это выглядит как попытка «накачать» резюме и выдает слабое понимание того, какие инструменты для чего нужны. Работодатели все чаще проверяют глубину, а не ширину компетенций.

Фокус исключительно на UI-тестировании. «Потыкать интерфейс» и написать тест-кейсы в Google Docs уже недостаточно. Рынок ожидает от QA-инженера полное видение и понимание алгоритма действий системы, а не только то, что в конце видит пользователь.

Типичные ошибки на собеседованиях: от резюме до live-задач

Иван: Большинство провалов на интервью происходит не из-за отсутствия уникальных суперскиллов, а из-за банальных и повторяющихся ошибок.

Несоответствие реального опыта и резюме

Классическая ситуация: в резюме написано «проводил нагрузочное тестирование», а на уточняющие вопросы кандидат отвечает в духе «ну, я запускал один раз JMeter по инструкции».

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

Мой совет: описание опыта должно быть честным и конкретным — лучше написать меньше, но по сути.

Отсутствие структурированного подхода к задачам

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

Хуже всего выглядит хаотичный набор проверок без приоритизации и отсутствие логики по принципу «проверю все подряд».

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

Обесценивание багов или попытка «списать» вину

Когда кандидат рассказывает о дефектах в прошлых проектах, нередко заметно, что он либо старается свести все к тому, что «разработчики неправильно сделали», либо оправдывается фразами вроде «мне не дали времени на тесты».

Это сигнал о том, как человек относится к ответственности, умеет ли он работать в команде и способен ли извлекать уроки из ошибок.

Мой совет: Гораздо лучше, если вы расскажете, как разобрались в причине инцидента, какие меры предложили и что сделали, чтобы снизить вероятность повтора.

Софт-скиллы: одни из важнейших навыков

Ключевые «человеческие» качества, на которые мы смотрим:

• Умение спорить по делу и без токсичности

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

• Прозрачность и предсказуемость в работе

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

• Обучаемость и отношение к обратной связи

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

Мы предпочитаем человека, который признает, что чего-то не знает, но показывает, как он будет этот пробел закрывать.

• Влияние на команду, а не только на себя

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

Как подготовиться к собеседованию? Подскажи практические рекомендации

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

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

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