Как устроен тестовый стенд
Что проверяют
Видели ли вы стенд изнутри или только запускали тесты по чужой ссылке. Ответ показывает, понимаете ли вы, откуда на стенде берутся данные, кто его обновляет и почему он периодически «лежит».
Как отвечать
Опишите состав, а не определение. Тестовый стенд это развёрнутая копия системы: приложение, база, очереди, кеш и заглушки внешних сервисов, доступная команде отдельно от продакшна.
- окружения: dev для разработчиков, тестовый для QA, препрод (stage) максимально похожий на прод, сам прод. Чем ближе к проду, тем строже доступ и тем реалистичнее данные;
- обновление: стенд катится из CI автоматически после мержа или по кнопке на выбранную ветку. Ручная сборка руками по SSH это признак незрелого процесса;
- данные: наливаются скриптом или дампом с обезличиванием. Тесты должны сами создавать то, что им нужно, и убирать за собой, иначе через неделю стенд забит мусором;
- внешние системы: платежи, СМС, банки подменяются моками (WireMock, локальные заглушки) или песочницами вендора. Дёргать боевого провайдера со стенда нельзя;
- изоляция: контейнеры и разворачивание стенда на ветку решают главную боль, когда один общий стенд занят чужим тестированием.
Полезно назвать, чего на стенде не хватает: объёма данных и нагрузки. Часть проблем ловится только на препроде или на проде под реальным трафиком, поэтому там нужны мониторинг и логи.
Где спотыкаются
Считают стенд статической средой, куда данные завезли один раз. Отсюда тесты, зелёные только в первый прогон.
Не разделяют тестовый стенд и препрод, а вопрос про разницу обычно идёт следующим.
Не могут объяснить, откуда взялись тестовые учётки и что делать, когда стенд не отвечает. Диагностика (логи, статус контейнеров, свежесть версии) часть работы тестировщика, а не только админа.