Какой размер команды и сколько в ней программистов и тестировщиков
Что проверяют
Этот вопрос чаще задаёт кандидат, и по нему интервьюер видит, что вам важно: качество, процесс, нагрузка. Если спрашивают вас, хотят понять, к какой команде вы привыкли и кто у вас отвечал за тесты. Следом обычно идёт вопрос, какие тесты вы писали сами.
Как отвечать
Если спрашиваете вы, сама цифра мало что скажет, важно устройство команды. Для Java-бэкенда полезно уточнить:
- состав: сколько бэкенд-разработчиков, есть ли фронтенд и мобильные внутри команды, пишет ли код тимлид;
- зона ответственности: сколько сервисов на команду, свои ли это сервисы или общий монолит на десяток команд;
- тестирование: сколько QA, кто пишет автотесты, есть ли автоматизатор, какие проверки обязательны в пайплайне перед мержем;
- ожидания от разработчика: пишете ли вы сами юнит-тесты на JUnit 5 и Mockito, интеграционные на Testcontainers, контрактные; кто дежурит по продакшену.
Универсальной пропорции программистов и тестировщиков нет. Бывают команды, где тестирование целиком на разработчиках, и команды с выделенным QA и автоматизатором. Само по себе ни то, ни другое не плохо: важно, кто держит регрессию и сколько идёт релиз.
Если вопрос задали вам, опишите последнюю команду фактами: «шесть бэкендеров на Java и Spring Boot, два QA, один из них автоматизатор; мы писали юнит- и интеграционные тесты, QA держали сквозные сценарии и регрессию». Цифры только свои. Если тестировщиков не было, скажите прямо и объясните, как обеспечивали качество: ревью, тесты в CI, фича-флаги, мониторинг после выкладки.
Где спотыкаются
Выдают «оптимальную» пропорцию вроде «на шесть разработчиков два тестировщика» как правило. Такого правила нет, зато интервьюер слышит, что вы отвечаете шаблоном.
Говорят, что тестирование это работа QA. Для Java-разработчика это минус: от бэкенда ждут юнит- и интеграционных тестов в каждом PR, а тестировщик проверяет сценарии, а не каждую ветку кода.
Задают вопрос работодателю и не слушают ответ. Если выясняется, что QA один на пять команд, это повод спросить, как устроен релиз и кто ловит регрессии, а не пропустить мимо ушей.