Ищем тестировщиков, которые умеют находить проблемы до пользователей, а не после. Разбираем, какие виды тестирования человек применял на практике, как описывал ошибки и что делал, когда релиз нужно выпускать, а проверки не закончены.
Ошибки находят пользователи, а не команда: тестирование сводится к проверке основных сценариев по памяти.
Задачу закрывают без внятного описания дефекта, разработчик тратит время на переспрашивание и воспроизведение.
Автотесты есть, но они падают постоянно и никто им не верит — их отключают перед релизом.
Нужен тестировщик, который закроет и ручные проверки, и автоматизацию, а это разные навыки и разная мотивация.
Закрываем позиции в продуктовых командах, аутсорсе, финтехе и внутренних системах. Если нужен разработчик, который возьмёт на себя автоматизацию проверок, смотрите подбор разработчиков → Состав команды уточняем на брифинге.
Полчаса разговора: что и как часто релизится, какие проверки обязательны, есть ли автотесты, кто принимает решение о выпуске. Сразу говорим, реально ли закрыть позицию на ваших условиях.
Фиксируем требования, стоп-факторы и вилку. Публикуем вакансию, поднимаем базу и идём в прямой поиск по профильным сообществам.
Звоним, разбираем реальные проверки и дефекты, сверяем ожидания по деньгам и формату. Присылаем короткий список с комментарием по каждому.
Организуем встречи, при необходимости — задание на разбор требований или поиск дефектов. Собираем обратную связь и корректируем поиск.
Держим связь между оффером и первым рабочим днём. Тестировщику важно понять, как устроен процесс и есть ли место для автоматизации: обещание «потом займёшься автотестами» без сроков обычно не работает.
По данным исследования сервиса «Работа.ру», средний срок закрытия вакансии по рынку в целом — 16 дней, медиана — 11 дней. Это статистика прежде всего по массовым и линейным позициям: узкие требования к опыту в неё не укладываются. Как сроки закрытия зависят от профиля →
Разбор вакансии, оценка рынка и реалистичности требований — до начала работы и без обязательств.
Публикации, прямой поиск, звонки, интервью и проверка рекомендаций. Аванса нет: пока кандидат не вышел, вы не платите.
Счёт выставляем после того, как сотрудник вышел на работу.
Если в вакансии нужен ручной тестировщик, инженер по автоматизации и специалист по нагрузочным проверкам в одном человеке, мы скажем об этом сразу. Это три разные компетенции, и совмещение возможно только как временное решение.
Для большинства команд базовый набор — функциональное и регрессионное тестирование, работа с пограничными случаями и проверка интеграций.
Если продукт мобильный или работает под нагрузкой, добавляются проверки совместимости и производительности; это мы уточняем на брифинге.
И тех, и других — это разные рынки и разные ожидания по деньгам.
Отдельно предупреждаем: если обещать ручному тестировщику автоматизацию «в будущем» без конкретики, человек уходит на испытательном сроке.
Спрашиваем, как устроены чек-листы и тест-кейсы в его практике, кто ими пользуется и что происходит с ними при изменениях продукта.
Просим показать обезличенные примеры: по описанию дефекта сразу видно уровень работы.
Если в команде есть отдельный инженер по автоматизации, ручному тестировщику достаточно понимать принципы и уметь читать падения.
Если автоматизацию нужно развивать с нуля, это отдельная роль, и мы скажем об этом прямо.
Даём ситуацию: времени на полную проверку нет, а выпускать нужно. Смотрим, что человек считает критичным, как расставляет приоритеты и кого предупреждает о рисках.
Ответ показывает, работал ли кандидат в реальных релизных циклах.
Ответим в среднем в течение 1,5 часов в рабочее время. Можно написать в Telegram или позвонить — как удобнее.