Сколько тестировщиков выделено на команду
Что проверяют
Вопрос ваш, и по ответу видно контур качества на бэкенде. Для java-разработчика важнее не штат, а что стоит между вашим коммитом и продакшеном: какие проверки автоматические, какие ручные и кто отвечает за интеграции между сервисами.
Как отвечать
Уточняйте процесс, а не численность:
- пишут ли разработчики интеграционные тесты сами и на чём поднимается окружение: контейнеры в тестах, общий стенд, заглушки внешних систем;
- есть ли контрактные тесты между сервисами или совместимость проверяют вручную;
- как проверяются миграции схемы и что делают, если релиз надо откатить, а миграция несовместима назад;
- проводится ли нагрузочное тестирование и кто его запускает;
- сколько тестовых окружений и приходится ли делить стенд с соседними командами.
Дальше слушайте. Тестировщик без автоматизации на системе из многих сервисов означает, что регресс гоняют через интерфейс, а ваши сервисы покрыты только вашими же тестами. Отсутствие тестировщиков при зрелой сборке с интеграционными прогонами и постепенной выкаткой это нормально: качество перенесено в код и в мониторинг. Спросите заодно, кто дежурит по инцидентам. «Тестирования почти нет» и «дежурят разработчики» ходят вместе, и знать это лучше до выхода.
Где спотыкаются
Считают, что много тестировщиков означает высокое качество. Нередко наоборот: большой ручной регресс перед каждым релизом это симптом того, что автотестов нет и релизный цикл растянут.
Не спрашивают про тестовые данные и внешние интеграции. На бэкенде именно они делают проверку долгой: без нормальных данных и заглушек любой сценарий готовится дольше, чем выполняется.
Задают вопрос как претензию, с интонацией «а почему у вас так мало». Собеседование идёт в обе стороны, но откровенный ответ вы получите только если спрашиваете из интереса к процессу, а не выставляете оценку.