Когда команда говорит «сборка уехала на стенд», это значит, что релизную сборку развернули в отдельной среде со своим адресом, настройками и данными.
Одна и та же сборка на DEV, IFT и PROD может вести себя совершенно по-разному.
Разберем:
DEV нужен для быстрых экспериментов и первичной проверки свежих изменений, QA — для спокойной проверки согласованной сборки.
PROD — это среда реальных пользователей и данных, поэтому туда попадает только проверенная версия.
Примеры проблем при работе на одном стенде
Если все в одном стенде
Разработчик перенакатил сборку на общий стенд, и тестировщик не понимает, почему все сломалось: из-за проверки, новой версии или нестабильного стенда.
Когда стенды разделены
На DEV можно быстро проверить свежую сборку, а на QA тестировщик работает с согласованной версией и видит, после какого деплоя появилась проблема.
Примеры проблем при работе на одном стенде
Если все в одном стенде
Пробные аккаунты, заявки, заказы и статусы попадают в общую базу. После этого непонятно, какие записи можно менять, а какие нужны для приемки или реальных процессов.
Когда стенды разделены
На QA можно свободно готовить и чистить тестовые данные, а приемка работает с отдельным стабильным набором и не ломается от экспериментов.
Примеры проблем при работе на одном стенде
Если все в одном стенде
Команда ждет, пока внешний сервис или соседний компонент будут готовы, поэтому проверка сценария стоит.
Когда стенды разделены
На QA можно проверять сценарии на заглушках: они имитируют ответы внешних сервисов и позволяют не ждать доработки всех зависимостей.
Названия могут отличаться: где-то говорят TEST, где-то QA; IFT могут называть SIT; PREPROD может называться STAGE. Важнее не аббревиатура, а договоренность команды: кто деплоит, кто тестирует, какие данные можно менять и что считается готовностью к следующему шагу.
Здесь разработчики быстро проверяют свежие изменения сразу после сборки: приложение запускается, изменение доступно, очевидный happy path не падает. Стабильность не гарантирована, тестовые данные могут пересоздаваться.
Такой стенд помогает быстро заметить грубые проблемы, но не заменяет полноценную проверку качества.
Контролируемая среда, где тестировщик проводит основную проверку задачи: дымовое тестирование, функциональные сценарии и регрессионные проверки.
Здесь важны требования, тестовые данные, чек-листы и понятные баг-репорты.
IFT означает Integration Functional Testing, SIT — System Integration Testing. Здесь сервисы подключены друг к другу и к тестовым версиям внешних систем.
На этом шаге проверяют обмен данными между компонентами: контракты API, очереди, платежи, авторизацию и callback-и.
UAT расшифровывается как User Acceptance Testing. На этом стенде бизнес, владелец продукта или заказчик смотрит сценарии с точки зрения реальной ценности.
Цель этапа — подтвердить, что сценарий решает задачу пользователя, и отделить баги от изменений требований.
Preprod или stage максимально похож на production: конфигурацией, процессом деплоя и набором подключений. Данные обычно обезличены или специально подготовлены.
Команда репетирует продовый деплой, проверяет миграции, настройки, фичефлаги, финальное дымовое тестирование и готовность к релизу.
Production — среда реальных пользователей, денег, заказов и репутации. Здесь уже не экспериментируют с проверками, которые можно было выполнить раньше.
После выкладки команда выполняет пострелизное дымовое тестирование, смотрит логи, метрики и трассировку, чтобы быстро понять, нужен ли hotfix.
Фраза «не воспроизводится» часто означает не «бага нет», а «мы смотрим в разные среды». Перед проверкой полезно зафиксировать контекст.
Если баг зависит от среды, в баг-репорте указывайте стенд, версию, данные и интеграцию. Это экономит часы на переписке и помогает быстро понять, где искать причину.
Релиз-кандидат — сборка, которую команда считает достаточно зрелой для финальных проверок. Обычно она движется не прыжком из dev в prod, а цепочкой:
Небольшой проект может жить с dev, test и prod, большой финтех почти всегда отделяет интеграции, приемку и preprod.
Уровень повышен!
