Гайд: проектирование тестовой инфраструктуры

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

На этапе Подготовка команда определяет состав сред, необходимые инструменты и план их готовности. Существующие средства клиента переиспользуются, если обеспечивают нужную изоляцию и управление. Пример для трёх принимающих показывает, как оформить решение.

Этот гайд описывает среды и средства выполнения проверок. Требования, спецификации, тест-кейсы, данные и автотесты учитываются в общем реестре артефактов; их содержание и полнота развиваются по отдельному плану параллельно внедрению.

Среды, сборка и управление описаны в разделах 1–3. Моки, эмуляторы и приёмники эффектов и управляемое выполнение раскрывают конкретные механизмы тестирования; сводная таблица помогает выбрать применимые.

1. Два назначения сред: DEV и UAT

В этой методологии DEV и UAT обозначают назначение среды. Названия стендов у клиента могут быть другими.

Нужны 2–4 независимые DEV-среды и подходящие среды для приёмки — UAT. Наличие UAT обязательно, но создавать новый отдельный пул не обязательно. Сначала проверяется, где команда уже принимает изменения: на персональных стендах, общих тестовых средах или pre-prod.

При создании новых UAT ориентируются на число одновременно принимающих; в идеале у каждого своя среда. Например, для трёх аналитиков, формулирующих и принимающих задачи, можно предусмотреть три UAT. Принимающим может быть и другой назначенный участник.

Количество DEV выбирается по планируемому параллелизму. Если среда занята, новая задача ожидает свободную либо получает дополнительно созданную среду; чужое выполнение не перезаписывается. Динамически создаваемые среды допустимы, если одновременно доступны нужные 2–4 независимых места работы.

При общей UAT или pre-prod согласуются состав проверяемой версии, время приёмки и порядок изменений, чтобы параллельная работа не разрушала проверяемое состояние. Персональные среды не являются обязательным условием внедрения; ожидание общей среды фиксируется как ограничение процесса.

Обязательное условие: доступ агента к UAT

Независимо от того, кто развёртывает результат и кому принадлежит среда, у агента должен быть доступ к используемой UAT для понимания и разбора проблем и замечаний принимающего. Одной ссылки на ветку для этого недостаточно.

Нужно обеспечить возможность увидеть фактически развёрнутую версию, проверить описанное поведение и получить связанные журналы, ошибки, конфигурацию и необходимые для воспроизведения данные. На подготовке проверяют этот доступ на конкретном сценарии и определяют, как передавать агенту шаги и контекст замечания.

Доступ для диагностики не означает обязательного права на развёртывание, сброс данных или изменение среды. Такие операции выполняет назначенный участник, штатный процесс клиента либо агент в согласованных пределах. Для общего pre-prod отдельно фиксируются доступные агенту действия и порядок подключения ответственных за остальные операции.

2. Что означает независимость среды

Среда — это приложение вместе с состоянием, зависимостями и средствами управления. Разные адреса приложения сами по себе не обеспечивают независимость. Для существующей UAT или pre-prod описывают фактическую организацию и допустимые операции; обязательного повторения архитектуры DEV и права агента на сброс UAT не требуется. Влияние общих компонентов на приёмку учитывается в правилах использования среды.

Компоненты могут быть общими физически, если обеспечена и проверена логическая изоляция. Для неё могут использоваться отдельные экземпляры, базы, схемы, пространства имён или другие средства проекта. Для каждого общего компонента нужно объяснить, как разделяются состояние и управляющие операции.

Ресурсов должно хватать на выбранное число одновременных прогонов: логически изолированные среды не должны регулярно блокировать друг друга из-за нехватки доступной мощности.

Сборка, хранилище артефактов и деплой

Для всех стендов действует единая схема: исходный код → сборка → хранилище артефактов → деплой на выбранный стенд. Единственный источник бинарей для деплоя — хранилище артефактов. Это правило одинаково для DEV, UAT и pre-prod, независимо от того, кто запускает операцию.

1. Ветка или задача определяет исходный код; перед сборкой фиксируется точная ревизия.
2. Процесс сборки создаёт бинарный артефакт — например, пакет или контейнерный образ — и публикует его в хранилище.
3. Артефакт получает неизменяемый идентификатор и связь с ревизией и запуском сборки. Повторная сборка публикуется как новый артефакт.
4. Деплой получает выбранный артефакт из хранилища по точному идентификатору и применяет конфигурацию целевого стенда.
5. В записи деплоя сохраняются стенд, идентификатор артефакта, ревизия кода, конфигурация и результат проверки готовности. Проверки и замечания привязываются к этому артефакту.

Один опубликованный артефакт может независимо деплоиться на несколько стендов. Для приёмки выбирается конкретный артефакт с известными результатами проверок. Если требуется объединить изменения нескольких задач, формируется соответствующая ревизия исходного кода, выполняется сборка и публикуется новый артефакт.

Данные и настройки сценариев подготавливаются отдельно по воспроизводимым наборам и инструкциям. Стенд получает свою конфигурацию при деплое; идентификатор бинарного артефакта остаётся однозначным.

Деплой ревизии задачи и служебные ветки

Для выбранного потока агент должен уметь независимо проверить конкретную ревизию задачи на выделенной среде, без предварительного включения задачи в общую интеграционную ветку. Схема «разработчик проверяет на своём компьютере, затем команда выбирает задачи для единственной развёртываемой ветки» не обеспечивает это условие для параллельной агентской работы.

Полноценность среды определяется сценариями: приложение, нужные данные, миграции, фоновые процессы и зависимости должны позволять выявить значимые для задачи проблемы. Изолированные управляемые моки допустимы. Локальный запуск части приложения не заменяет проверки взаимодействий, которые в нём отсутствуют. Unit- и другие проверки без стенда сохраняются в своём контуре; они не заменяют необходимые стендовые проверки.

На Подготовке фиксируются ограничения CI/CD и выбирается решение:

Деплойные ветки — допустимый способ адаптации существующего CI/CD. Не требуется вводить их там, где исходная схема уже решает задачу.

Работа со служебной деплойной веткой

1. Зарезервировать среду под задачу/прогон; для UAT сохранить правила приёмки и подтверждение разрешённого изменения.
2. Зафиксировать feature-ветку и точный исходный commit SHA. По правилам проекта пересоздать или переназначить служебную ветку этой среды точно на этот commit, не объединяя в ней задачи и не добавляя продуктовые изменения.
3. Запустить привязанный к ней CI/CD. Сборка использует зафиксированный SHA, а не текущее значение имени ветки при позднем старте job. Артефакт публикуется под неизменяемым ID.
4. Перед деплоем проверить, что запрос всё ещё владеет резервированием среды и выбран для её текущего развёртывания. Сериализовать изменения одной среды и удерживать блокировку на время деплоя; устаревший pipeline не должен получить право изменить среду после нового запроса.
5. Выполнить деплой из хранилища, подготовить состояние, проверить готовность и фактическую версию. Сохранить цепочку задача → feature-ветка → исходный SHA → деплойная ветка и запуск pipeline → ID артефакта → среда и запись деплоя → результаты тестов.
6. Перед следующей задачей сохранить доказательства, освободить/переназначить среду и подготовить её данные, моки и время. Сама смена ветки не очищает состояние БД и не отменяет уже начавшиеся задания.

Резервирование имеет идентификатор или иной проверяемый признак актуальности. Порядок отмены старых jobs, блокировки деплоя и проверки актуального запроса фиксируется в инструкции. Одна только отмена pipeline без проверки на стороне деплоя не подтверждает защиту от запоздалого запуска.

Feature-ветка и MR сохраняют историю разработки и ревью. Служебная ветка не используется как источник продуктового merge. Пересоздание/принудительное обновление разрешается отдельному исполнителю только для указанных служебных веток; продуктовые и защищённые ветки сохраняют свои ограничения.

Если настройка CI требует дополнительных файлов, предпочтительно вынести её в подключаемую конфигурацию или другой механизм, не изменяющий выбранный исходный commit. Если это невозможно и создаётся отдельный сборочный commit, фиксируются оба SHA и полный diff; дополнительные изменения не должны незаметно менять продукт, а соответствие проверяемому MR отдельно подтверждается.

Для приёмки используется выбранный артефакт из хранилища. Если существующий CI/CD заставляет выполнить новую сборку для UAT, она получает новый ID; проверки прежнего артефакта не считаются автоматически проверками нового.

Что зафиксировать и проверить

Карта «среда → служебная ветка → pipeline → полномочия» и выбранный способ развёртывания заполняются в Git-шаблоне. Пример показывает эту схему на двух параллельных задачах.

До запуска зависимой задачи проверяется путь выбранной ревизии до среды. К третьей фазе PoC проверяются параллельные деплои разных задач, смена задачи на среде, защита от устаревшего pipeline и воспроизводимость версии/данных. Отдельная машина инженера не служит подтверждением этих условий.

3. Управление средами со стороны сопровождения

В DEV действия агента должны выполняться программно — через API, CLI, задания CI/CD или существующие инструменты проекта. В UAT этот набор применяется к операциям, порученным агенту; самостоятельное развёртывание принимающим или штатным процессом клиента допустимо. Для любой UAT обязателен доступ агента для диагностики. Для каждого действия задаются целевая среда, входные параметры, проверяемый результат и способ получить ошибку. Операция не считается успешной только потому, что команда запуска принята.

Набор возможностей для DEV и для автоматизируемых операций UAT:

В записи прогона сохраняются применимые параметры: артефакт и ревизия, среда, набор данных, конфигурация, версии моков и эмуляторов, сценарий эффектов, начальное время, seed и последовательность конкурентных событий. Секреты остаются в штатном хранилище; в записи используются ссылки или идентификаторы.

Конкретные команды описываются в инструкции проекта. Если действие требует человека, указываются ответственный и порядок обращения. Для DEV планируется автоматизация необходимых агентам операций; самостоятельное развёртывание человеком в UAT само по себе не является недостатком и не требует обязательной автоматизации.

Порядок работы в DEV

1. Агент получает свободную среду и связывает её с задачей и прогоном.
2. Выбирает опубликованный артефакт нужной ревизии либо запускает его сборку и публикацию. Выполняет деплой из хранилища в выделенную DEV, готовит данные, моки и начальное время.
3. Выполняет задачу, проверки и исправления; сохраняет доказательства.
4. При сбое, который агенты не могут устранить, подключается назначенный человек.
5. После завершения работы сохраняет результаты и освобождает среду по согласованному правилу.

DEV не используется людьми для обычной приёмки или демонстраций. Диагностическое вмешательство человека отмечается, особенно если оно изменило состояние и требует повторения проверок.

Смена задачи: БД и восстановление тестовых данных

Смена ветки или бинарного артефакта не возвращает БД в исходное состояние. Предыдущая задача могла изменить схему и данные так, что новая ревизия с ними несовместима. Перед запуском приложения выбирается и выполняется способ подготовки БД.

Исходное состояние — версионированный комплект схемы и данных, совместимый с целевой ревизией: снимок БД с известной историей миграций либо создание БД с нуля и загрузка заданного набора. У комплекта указаны источник, версия схемы, версия данных и инструкция восстановления. Снимок с чужими изменениями ветки не становится подходящим только потому, что он успешно восстановился.

Порядок сброса и подготовки

1. Зафиксировать целевые задачу, SHA и ID артефакта, среду и принадлежащую ей БД. Проверить резервирование и права на сброс; блокировка должна охватывать подготовку БД и деплой. Устаревшие pipeline не могут менять ни приложение, ни БД.
2. Сохранить доказательства предыдущего прогона и нужное для разбора замечаний состояние. Для UAT получить зафиксированное разрешение на изменение или завершение приёмки.
3. Остановить приложение, фоновые обработчики, расписания и другие источники записи в эту БД; завершить активную работу по инструкции проекта. Изолировать или очистить относящиеся к старому прогону очереди, кэш, файлы, моки и таймеры. Соседние среды продолжают работу.
4. Пересоздать только целевую БД/схему либо восстановить выбранный снимок. Проверить версию схемы и историю применённых изменений. Исходная история должна соответствовать поддерживаемой точке начала для миграций целевой ревизии; при отсутствии подходящего снимка использовать создание с нуля.
5. Применить изменения БД целевой ревизии в установленном порядке, автоматическим средством либо временным ручным процессом. Проверить итоговую схему и журнал применения. Не подменять выполнение миграций правкой записей об их применении.
6. Восстановить тестовые данные по рецепту для этой версии: снимок уже содержит базовые данные; дополнительные наборы загружаются в явно указанном порядке без дублей. Данные для проверки преобразования загружаются до соответствующей миграции, сценарные данные для готовой схемы — после. Задать начальное время и настройки моков.
7. Выполнить деплой выбранного артефакта из хранилища и запуск в порядке, определённом инструкцией проекта. До готовности схемы и данных приложение не обслуживает запросы и не выполняет фоновые операции. Проверить версию, smoke-сценарии, контрольные данные и отсутствие влияния на другие среды.
8. Сохранить результат подготовки: среда/БД, задача, SHA, ID артефакта, исходный комплект, применённые изменения, итоговая версия схемы и данных, исполнитель, время и доказательства проверок. Только после успешной проверки среда доступна задаче или принимающему.

При сбое миграции или загрузки данных среда получает статус «не готова». Сохраняются ошибка и фактическое состояние; повторный запуск допустим только по предусмотренному для этого состояния правилу. Иначе выполняется восстановление и повтор всей процедуры. Обратные миграции не считаются универсальным способом смены ветки: они могут быть необратимыми или терять данные; использовать их можно только по отдельно проверенной инструкции.

Сброс должен воспроизводимо давать заданные схему и данные, в том числе при повторном выполнении. Это не требование повторно применять уже выполненную миграцию: средство миграций должно учитывать историю применения.

Проверка на чистой БД не заменяет проверку обновления существующей. Для изменений схемы и преобразований данных нужен отдельный прогон с поддерживаемой предыдущей версии и характерными данными: применение изменений, сохранность и правильность преобразования. Если база восстанавливается уже в конечной схеме, такой прогон миграцию не проверяет.

Заполняемая форма — БД, сброс и миграции, пример — смена задач на одной среде.

Порядок работы в UAT

1. Команда определяет, где принимается задача или набор изменений и кто готовит результат.
2. Принимающий, другой участник, штатный процесс клиента или агент выполняет деплой выбранного артефакта из хранилища. Если нужного артефакта ещё нет, сначала выполняются сборка и публикация. Фиксируются адрес, идентификатор артефакта, ревизия, данные, готовность и ограничения; проверяется доступ агента для диагностики.
3. Человек проводит приёмку. При замечании передаёт агенту среду, версию, шаги, ожидаемое и фактическое поведение.
4. Агент использует доступ к этой UAT, чтобы разобраться в замечании, проверить состояние и собрать диагностику. При необходимости запрашивает помощь DevOps или готовит исправление.
5. Новую версию, данные или сценарии подготавливают по согласованному процессу. Агент может делать это по запросу, если такие операции ему поручены. Изменения фиксируются вместе с необходимыми повторными проверками.
6. Результат приёмки и замечания связываются с фактически проверенной версией и состоянием среды.

Для каждой приёмки фиксируются артефакт из хранилища, конфигурация целевого стенда, набор данных и настройки сценариев. Состав изменений в артефакте должен быть известен принимающему и агенту.

4. Программно управляемые моки и эмуляторы

Внешние сервисы, оборудование и получатели побочных эффектов включаются в единый порядок управления тестовыми зависимостями. Для них используются моки, эмуляторы и тестовые приёмники операций: агент задаёт сценарий, выполняет проверку, читает фактические обращения и результаты, затем сбрасывает контекст.

Адрес, порт и режим подключения задаются тестовой конфигурацией. Агент должен направить приложение на выбранную тестовую зависимость и увидеть фактически выбранное подключение. Если адрес или обращение к устройству зашиты в коде и перенаправление невозможно, до зависимых проверок требуется доработка этого механизма.

Общие требования

У каждой DEV- и UAT-среды должен быть собственный независимый контекст тестовых зависимостей. Контекст включает исходное состояние, профиль и версию протокола, ответы, данные, сценарий вызовов и событий, журнал операций, задержки и отказы. Один физический сервис допустим при подтверждённой независимости контекстов; иначе нужны отдельные экземпляры. Настройка или сброс одной среды не меняют соседние.

Через API, CLI или сценарный файл агент должен уметь:

• выбрать профиль, начальное состояние и сценарий, задать параметры;
• получить штатный ответ, ошибку, недоступность, задержку или отсутствие ответа для проверки тайм-аута;
• задать последовательность, например «два отказа, затем успех», а по применимости — повтор или повреждённый пакет;
• подать, задержать или повторить входное событие, показание, нажатие либо обратный вызов;
• прочитать запросы, команды и сообщения: параметры, адресатов, содержимое, число и порядок обращений, а также итоговое состояние тестовой зависимости;
• проверить ожидаемые и запрещённые операции, дубли, частично выполненные действия и восстановление после ошибки;
• сбросить состояние и историю отдельно для нужной среды или прогона, сохранить сценарий и журнал для повтора.

Для каждого выбранного сценария известны команды подготовки, проверки и сброса. Глобальный переключатель ошибок на несколько сред и ручная перенастройка соседнего стенда этим требованиям не соответствуют.

Применение к разным зависимостям

Попытки и завершённые эффекты наблюдаются отдельно: запрос платежа — в журнале вызовов, итоговое списание — в состоянии sandbox. Успешный ответ функции сам по себе эффект не подтверждает. Повтор операции не должен незаметно создавать второе письмо или списание. Назначения и права тестового контура исключают реальную отправку, оплату или управление оборудованием.

Для автономной разработки и тестирования аппаратных сценариев нужен эмулятор. Агент не получает доступ к физическому устройству. При недоступности эмулятора прогон завершается ошибкой без переключения на реальное оборудование; его адреса, порты и доступы не включаются в контур агента. При отсутствии эмулятора его создание включается в план, а соответствующие сценарии временно исключаются из автономного потока. Физическое устройство отдельно проверяет человек.

Соответствие реальной зависимости

Мок или эмулятор подтверждает поведение приложения в заданных условиях. Совместимость с реальным внешним сервисом проверяется отдельно в доступном тестовом контуре или другим согласованным способом. Если контур общий и не допускает изоляцию, такие проверки выполняются по отдельному расписанию.

Профиль устройства сверяет назначенный специалист: по документации протокола, эталонным обменам и отдельным аппаратным проверкам. В результатах перечисляются воспроизводимые и непроверенные свойства. Электрические характеристики, реальные помехи, механические отказы и фактическая производительность не считаются подтверждёнными эмуляцией. Пример программно создаваемого профиля устройства — Android Virtual Device; для конкретного оборудования нужен свой применимый эмулятор.

5. Управляемое выполнение сложных сценариев

Для выбранных сценариев определяются конкретные средства управления. Ниже перечислены механизмы; применимые средства должны быть доступны агенту программно до зависимой задачи. Для каждого известны команда или API, входные параметры, признак завершения, результат и способ сброса. Полный набор не требуется продукту, в котором соответствующих сценариев нет.

Время и глобальный контекст приложения

Для прогона задаётся профиль контекста: начальное время, часовой пояс, локаль, feature flags, переменные окружения, настройки арендатора и пользователя. Агент должен уметь выбрать профиль, применить его до запуска приложения и получить фактические настройки без секретов в отчёте. В ходе сценария время продвигается через отдельный механизм управления.

Если настройка или singleton меняет весь процесс и не имеет надёжного сброса, тест запускается в отдельном процессе или контейнере. Разные глобальные профили не применяются параллельно в одном общем процессе. После прогона снимаются временные обработчики и подписки, очищаются реестры; следующий запуск получает исходный профиль. Для пользователя и арендатора используются отдельные тестовые учётные данные и данные; проверяется отсутствие переноса контекста между запросами.

Виртуальное время и регулярные операции

Если в выбранных задачах есть операции по расписанию, таймеру или истечению срока, их нужно проверять без ожидания реальных часов, дней или месяцев.

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

Подход выбирается по архитектуре:

Не обязательно применять один механизм ко всему приложению. Для каждого сценария достаточно подходящего инструмента, но его область действия и ограничения должны быть описаны.

Управление временем внутри профиля

• Изменения ограничены выбранной DEV- или UAT-средой.
• Агент может задать начальное состояние, выполнить продвижение или запуск, дождаться завершения обработки и получить доказательства.
• Согласованы часы приложения, планировщика, движка процессов и моков там, где их поведение связано. Часовой пояс также задан явно.
• Повторные запуски, пропущенные интервалы и отложенные события обрабатываются по понятному правилу; сброс среды очищает накопленное состояние.
• Сценарий можно повторить из исходных данных и настроек.

Смена системных часов общей машины не подходит для независимого управления средами. Ручное присвоение записи конечного статуса также не заменяет проверку таймера и бизнес-операции.

Прямой запуск задания может проверять бизнес-логику, но сам по себе не доказывает правильность расписания. Если важны момент запуска, границы срока или повторные срабатывания, для них предусматриваются отдельные проверки.

Для функций, которые только читают текущую дату, нужен задаваемый источник времени: фиксированный момент, часовой пояс и возможность перейти через границу суток, месяца, года или применимого календарного правила. Для тайм-аутов проверяются также часы измерения длительности и таймеры; изменение календарной даты само по себе их не проверяет. В сценарии задаются начальный момент, продвижение времени, ожидаемые срабатывания и подтверждение завершения обработчиков.

Если проверка проходит через браузер и сервер, управление временем задаётся для обеих сторон по применимости. Например, Clock API Playwright управляет браузерными часами и таймерами, но сам по себе не меняет время сервера, БД или внешнего сервиса.

Случайность и недетерминированные данные

Для случайного выбора, генерации идентификаторов, перемешивания и вероятностных ветвлений нужен управляемый тестовый источник:

• задание seed и отдельного состояния генератора для прогона;
• возможность выдать конкретную последовательность значений, чтобы принудительно пройти нужную ветку или коллизию;
• сохранение seed, версии генератора и входных данных, а при нескольких источниках — их отдельных настроек;
• набор прогонов с разными seed и сохранение каждого неуспешного варианта для повторения.

Один seed не обеспечивает повтор при изменившемся порядке конкурентных вызовов: тогда нужны отдельные генераторы по участникам или запись фактически выданных значений и порядка их потребления. Детерминированная подмена применяется только в тестовом режиме и не подменяет криптографическую случайность рабочего контура. Пример отдельного генератора с собственным состоянием и seed — Python Random.

Асинхронность, очереди и многопоточность

Для сценариев с фоновой обработкой и гонками требуются:

• управляемая подача сообщений, остановка и продолжение обработчика в выбранной точке, барьеры или защёлки для согласованного старта конкурирующих действий;
• возможность задать задержку, повтор, перестановку или пропуск сообщения, разрыв соединения и перезапуск участника, если такие случаи допустимы для протокола;
• ожидание наблюдаемого условия завершения с ограниченным сроком вместо фиксированного sleep: статус задания, число обработанных сообщений, завершённая транзакция или другой проверяемый результат;
• журнал с идентификаторами задач, сообщений и обработчиков, позволяющий восстановить порядок существенных событий;
• сценарии одновременного изменения одних данных, повторной доставки, отмены и восстановления после прерывания по применимости.

Гонка воспроизводится заданным чередованием действий через барьеры, тестовые точки остановки или управляемый планировщик. Если стек поддерживает запись и повтор расписания, оно сохраняется с результатом; пример такого инструмента — Coyote. Дополнительные прогоны с реальными потоками проверяют поведение штатного выполнения. Многократный успешный запуск без управления порядком не заменяет воспроизведение известной гонки.

Удержанное состояние и последовательности действий

Для функций, зависящих от предыдущих вызовов, нужен программный способ создать известное исходное состояние и выполнить заданную последовательность команд:

• подготовка или восстановление версии набора данных, сессии, кэша, счётчиков и состояния фоновых обработчиков;
• чтение проверяемого состояния после каждого значимого перехода через API, диагностический снимок или запрос к тестовому хранилищу;
• сценарии «повторить команду», «вызвать в другом порядке», «прервать и продолжить», «перезапустить процесс и восстановиться»;
• подтверждение, что после очистки следующий прогон не наследует данные, незавершённые задания и подписки предыдущего.

В доказательства входят начальное состояние, последовательность действий и ожидаемые переходы. Для восстановления после сбоя проверяются отдельно сохраняемое состояние и исчезающее состояние процесса; чистый перезапуск не заменяет этот сценарий. Смена схемы и набора данных выполняется по порядку восстановления БД.

Сводка выбора механизмов

6. Если инструментов пока нет

Отсутствие средств управления — результат обследования и основание для плана доработок. По выбранным сценариям нужны работы на конкретные механизмы из разделов 4–5: моки и эмуляторы, приёмники эффектов, управление временем и случайностью, конкурентными событиями, состоянием и конфигурацией.

Это работы по обеспечению тестируемости, а не расширение Пилота на задачи реализации нефункциональных требований. Их трудозатраты учитываются отдельно как подготовка инфраструктуры.

Автоматические миграции: развитие без блокировки старта

Автоматические миграции — версионированные изменения схемы и данных, которые применяются штатной командой или процессом деплоя с учётом истории выполнения. Они связаны с ревизией приложения; для каждой БД сохраняется результат применения.

Как требования и автотесты, автоматические миграции не обязательны для начала внедрения, но существенно влияют на его результат. Без них каждое изменение БД требует ручной координации, обращения к специалистам и ожидания HITL. Это увеличивает трудозатраты и время решения задач, даже если код агент пишет быстро.

Если автоматических миграций нет или они покрывают не все компоненты:

• Зафиксировать состояние в реестре артефактов: какие БД покрыты, какие изменения выполняются вручную и где сохраняется их история.
• Для ближайших задач подготовить временный порядок: версионированный скрипт/инструкция, исходная и целевая схема, исполнитель, запрос HITL, подтверждение применения и восстановление при ошибке. Изменения «по памяти» не являются воспроизводимым процессом.
• Включить внедрение или дополнение миграций в план наряду с автотестами и требованиями: результат, ответственный, срок, зависимые сценарии и доказательство готовности. Работы могут идти параллельно PoC и Пилоту.
• Проверить автоматизацию на создании чистой БД, обновлении поддерживаемой предыдущей версии с данными, учёте уже выполненных изменений и обработке сбоя. Подключить инструкции к навыкам или заметкам агента.

В чек-листе проверяются временный рабочий порядок и план развития, а не обязательное наличие автоматизации. До задачи, меняющей БД, должен быть обеспечен применимый способ изменения, проверки и восстановления. Ручное участие в продуктовых задачах включается в трудозатраты людей, ожидание ответственного — в показатели ожидания реакции; создание общего инструмента учитывается отдельно как развитие инфраструктуры.

План готовности

Необязательно завершать все работы до минимального прохода онбординга на неделе 1 PoC. Однако до начала зависимых сценариев нужные инструменты должны быть готовы. К третьей фазе PoC инфраструктура должна обеспечивать проверку выбранных типов задач Пилота.

Если срок готовности не совпадает с планом, команда выбирает: изменить сроки, явно сузить область либо согласовать временный ручной способ с его стоимостью и ограничениями. Такой способ не предоставляет агенту доступ к физическому оборудованию: до появления эмулятора соответствующие проверки выполняет человек отдельно, а автономный поток ограничивается доступными сценариями. Непроверенный сценарий не отмечается как пройденный; при сохранении его в области остаётся план создания нужного инструмента.

7. Как подтвердить готовность инфраструктуры

Проверка проводится на выбранном для проекта числе сред и сохраняется со ссылками на результаты.

Неприменимость проверки обосновывается отсутствием соответствующих сценариев в выбранной области. Если сценарии есть, отсутствие инструмента оформляется работой в плане.

Итог Подготовки: перечень DEV/UAT, карта общих и изолированных компонентов, инструкции управления, подтверждения готовности и план незакрытых работ. Ответственность закрепляется за конкретными людьми; функции описаны в гайде DevOps.

8. Инфраструктура запуска тестов

Инфраструктура должна позволять воспроизводимо запускать проверки и сохранять результаты. Виды тестов, старт без готового набора и порядок его развития описаны в стратегии тестирования.

Не все проверки требуют полноценного DEV/UAT. Тестовый раннер со своими временными зависимостями планируется отдельно от пула стендов приложения. Для стендовых проверок сохраняется единая схема сборки, публикации артефакта в хранилище и деплоя.

При отсутствии нужного раннера, данных или средств наблюдения создаётся работа в плане готовности. До её выполнения согласуется временный способ проверки и явно отмечаются ограничения.