Были ли тестовые среды?

Что проверяют

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

Как отвечать

Опишите цепочку, которая была у вас, с назначением каждого звена. Типичный набор для Java-сервиса:

• локально: приложение и зависимости через Docker Compose, интеграционные тесты на JUnit 5 с Testcontainers, которые поднимают настоящий PostgreSQL или Kafka вместо моков;
• dev или test: общий стенд, куда автоматически выкатывается main, здесь работают тестировщики и гоняются автотесты;
• stage (preprod): максимально похож на прод по версиям, конфигурации и объёму данных, здесь приёмка и нагрузочные прогоны;
• временные стенды: отдельный namespace в Kubernetes на ветку или merge request, если инфраструктура позволяла.

Дальше детали, по которым видно понимание. Между средами продвигается один и тот же артефакт, Docker-образ или jar, а различается только конфигурация: профили Spring Boot (application-stage.yml, spring.profiles.active), переменные окружения, секреты из Vault или Kubernetes Secrets, но не из репозитория. Схема базы на всех стендах меняется одними и теми же миграциями Flyway или Liquibase. Внешние системы, до которых со стенда не дотянуться, подменяются WireMock. Данные на stage обезличены, если это копия прода.

Если стендов было мало, скажите честно и объясните, как команда снижала риск: feature flags, канареечные выкладки, быстрый откат. И назовите, что бы вы добавили.

Где спотыкаются

Называют продакшен одной из тестовых сред. Проверка на проде бывает (канареечный релиз, мониторинг после выкладки), но это отдельная практика, а не стенд для тестирования.

Собирают артефакт заново под каждую среду. Тогда на прод уезжает не то, что проверяли на stage.

Не могут объяснить, почему на stage всё работало, а на проде нет. Сильный ответ называет причины расхождения: другие версии зависимостей, объём данных, настройки пула соединений, и то, как вы их выравнивали.