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

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

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

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

– — – — – — – — – — – — – — – — – — – —

Кейс: тестировщик или разработчик – кто первый?

Суть: мы смогли поработать как в нескольких крупных компаниях, так и в стартапах, что позволит рассказать об особенностях работы с тестированием под разными ракурсами. Начнем, пожалуй, со стартапов. Работа в стартапе характерна совмещением нескольких функциональностей в одной роли, это может быть как две, так и три роли в одном участнике, ведь задача стартапа быстро собрать MVP8 продукта и показать его конечному потребителю, чтобы проверить гипотезу и CVP, которые необходимо донести. Если собирать стартап командой, уровень которой ниже чем middle+ / senior, то шанс попасть в те самые девять из десяти погибающих стартапов становится выше, ведь правильно заложенная архитектура продукта – это залог его успешного масштабирования в дальнейшем, а если речь идет об использовании одного бэкенда для web-приложений и мобильных приложений, то ценность высококвалифицированных специалистов на ранних стадиях становится еще выше. В ситуации, когда собирается стартап, функционал тестировщика минует множество бюрократических аспектов крупных компаний, и создания большого количества артефактов от тестирования также не требуется. Это значит, что тестировщик вполне может приступать к работе только после того, как готов первый блок функциональности, который можно проверять, сверять с макетами или требованиями и заводить дефекты. Раньше, чем есть первая кодовая база, привлекать тестировщика на стартап совершенно бессмысленно, если только у вас нет лишнего бюджета или желания вовлечь тестирование в процесс пораньше.

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

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