Ревью изменений и проверка результатов платформу
Предлагаемый общий регламент для гайдов разработчика, тестировщика и инженеров. Для каждого потока команда согласует режимы, имена проверяющих, сроки реакции и полномочия на интеграцию. Правила клиента по обязательным согласованиям сохраняются при любом режиме.
Состав тестового набора и развитие автоматизации определяются стратегией тестирования. Готовые автотесты не требуются для старта, но для каждой задачи нужны проверяемые результаты. Временные скрипты допустимы на старте; повторяющиеся проверки включаются в поддерживаемый набор. Unit-тесты тоже являются автотестами; API и UI — не исчерпывающий перечень.
Маршрут MR
MR — запрос на слияние изменений. Если клиент использует другой механизм интеграции, сохраняются те же функции и решения.
На неделе 1 PoC минимум онбординга заканчивается проверенным деплоем на DEV, MR кода и отчётом. Качество результатов проверяется, но прохождение цикла замечаний, приёмка и merge для завершения онбординга не требуются. Полный маршрут ниже проверяется на простых и целевых задачах недель 2–4.
На Подготовке маршрут записывается в Git-процессе для выбранной области. На PoC цикл с агентом организует ИИ-инженер, на Пилоте — команда продукта. Постепенная передача технического сопровождения между двумя ИИ-инженерами не меняет этого различия и полномочий команды на ревью, приёмку и merge.
| Этап | Маршрут готового результата | Кто ведёт устранение замечаний |
|---|---|---|
| PoC | Агент → ИИ-инженер сопровождения → назначенные проверяющие → уполномоченный на интеграцию. По решению Подготовки ИИ-инженер сопровождения выполняет ревью перед командой либо вместо её ревьюеров в явно определённой области | ИИ-инженер по текущей договорённости двух специалистов; в начале внедрения обычно специалист сопровождения |
| Пилот | Агент → назначенные разработчик и тестировщик команды продукта → уполномоченный на интеграцию. ИИ-инженер анализирует качество и помогает при технических проблемах; обязательного промежуточного ревью инженером нет | Проверяющие формулируют замечания и проверяют исправления; движение задачи обеспечивает назначенный участник команды продукта. ИИ-инженер подключается при сбое обработки или повторяющейся ошибке |
Если на PoC ревью выполняет ИИ-инженер сопровождения вместо команды, явно указать виды проверок, область, полномочия, результаты и того, кто принимает продуктовые и архитектурные решения. Обязательные проверки и ограничения проекта сохраняются. Простой разбор комплектности не считается полноценным ревью. Изменение маршрута фиксируется с датой и обновлением инструкций/уведомлений. Единый гайд ИИ-инженера и типовой сценарий передачи.
Код продукта и автотесты могут находиться в одном MR или в нескольких связанных. Один MR может требовать участия и разработчика, и тестировщика: каждый рассматривает свою часть. По возможности они работают параллельно. Замечания записываются в общем месте, чтобы избежать противоречащих поручений и повторной работы.
Кто нажимает merge, кто принимает продуктовый результат и кто выполняет выпуск, назначается явно. При отсутствии отдельной роли интеграции её выполняет названный разработчик или другой уполномоченный сотрудник. Положительное ревью не означает автоматического выпуска в промышленную среду.
Ограничение итераций и передача людям
До запуска потока команда фиксирует предел циклов доработки, сроки ответа людей, признаки отсутствия прогресса и того, кто принимает решение о дальнейшем выполнении. Один цикл — согласованный пакет замечаний к текущему объёму задачи → исправление агента → повторная проверка. Новые сообщения об одном пакете не считаются отдельными циклами; смена запуска агента не обнуляет счётчик.
Предложение для начального профиля: после двух циклов доработки — обязательный разбор с человеком до следующего запуска. Число можно адаптировать заранее. Дополнительный цикл допускается по явному решению с конкретной гипотезой исправления и сроком; повторяющиеся исключения требуют изменения процесса, а не бесконечных перезапусков. При отсутствии прогресса или признаках сложности для агента разбор проводят раньше.
На разборе инженер и соответствующий специалист клиента выбирают действие: дать недостающий ответ, исправить инструмент/контекст, передать выполнение людям, сократить согласованный объём или прекратить задачу. Причина и затраты сохраняются. Передача людям не должна откладываться до конца окна оценки когорты.
Итерационная разработка приветствуется, когда у итерации ограничены объём и критерии результата. Новые требования оформляются как изменение объёма либо следующая самостоятельная задача со связью с исходной. Нельзя незаметно дополнять старую задачу неделями или переносить тот же незавершённый объём в новую карточку для сброса срока. Исправления исходного результата сохраняют его историю.
Лимит итераций управляет работой сейчас; окно оценки когорты ограничивает срок оценки результата. Эти ограничения действуют одновременно. К отсечке задача без решения, фактической передачи человеку или отмены становится просроченной («Проблемной»). Своевременная передача человеку учитывается как отдельный исход, независимо от последующего срока ручного завершения.
Режим ревью кода
| Режим | Работа разработчика |
|---|---|
| Все MR | Подробно рассматривает каждый MR: соответствие задаче, корректность, влияние на существующий код, поддержку и проверки |
| По риску и выборке | Подробно рассматривает все MR с согласованными признаками риска и выбранные MR из типовых изменений; для остальных действует согласованная процедура интеграции и обязательные проверки |
Предлагаемый старт для новой области — «Все MR». Выборочный режим возможен, когда на согласованном наборе задач команда проверила качество, повторяющиеся замечания устранены, классификация риска и доказательства работают. Число задач, допустимые отклонения, объём и способ выбора выборки устанавливаются для проекта до изменения режима; универсального порога нет.
К признакам обязательного подробного ревью можно отнести новые архитектурные решения, изменение контрактов и данных, критические сценарии, большой объём изменений, незнакомый участок или расхождение с постановкой. Это признаки риска функциональной задачи, а не включение отдельного потока нефункциональных требований.
Риск предварительно указывает руководитель выполнения, разработчик подтверждает классификацию; сомнение означает подробное ревью. Выборка задаётся правилом или выбирается разработчиком, а не агентом по удобным ему результатам. Для каждого MR виден маршрут: подробно рассмотрен либо обработан по согласованному правилу для типовых изменений.
Разработчик и архитектор согласуют изменение режима в пределах полномочий клиента; РП фиксирует область и дату. При пропущенном существенном дефекте, ненадёжной классификации или изменении области команда возвращает подробное ревью для затронутого потока и разбирает причину. Сам факт наступления Пилота не сокращает проверку.
HITL, HOTL и отсутствие плановой ручной проверки
Для выбранной работы отдельно задаётся роль проверки человека: HITL блокирует зависимый переход до решения; HOTL (human-on-the-loop) выполняется асинхронно и переход не блокирует; без плановой ручной проверки сохраняются автоматические проверки и обращения по исключениям. Пример сочетания агентских работ и контроля.
Режимы «Все MR» и «По риску и выборке» задают объём просмотра, а HITL/HOTL — блокирует ли он движение. До изменения явно определяются область, проверяющий, объём и ритм просмотра, запись находок, порядок исправления и основания возврата. Существенная находка может потребовать остановки затронутого потока и восстановления HITL. Новый тип задач не наследует режим автоматически.
Для перехода разработки на HOTL наблюдаются возвраты с тестирования; при изменении тестирования — дефекты после приёмки; для обеих областей — нагрузка проверяющих. Эти показатели дополняют проверку качества и достаточности доказательств.
Условия повышения автономности
Гейт изменения режима · Форма предложения · Критичность замечаний.
Переход к пост-ревью
HOTL — асинхронная проверка после разрешённого перехода. Находка связывается с задачей и ревизией, направляется через чат и получает исполнителя и приоритет; поздняя проверка не означает, что замечание можно оставить без исправления.
Условия повышения автономности · Изменение режима проверки.
Ревью автотестов
Тестировщик рассматривает смысл проверяемых сценариев, соответствие ожидаемого результата требованиям, негативные случаи, тестовые данные, воспроизводимость и то, способен ли тест обнаружить нужную ошибку. Разработчик помогает с кодом, инфраструктурой тестов и техническими вопросами, которые выходят за компетенцию тестировщика.
Для MR автотестов отдельно выбирается режим «Все MR» или «По риску и выборке» по тем же принципам. За условия перехода отвечают тестировщик и разработчик в своих областях; общие ограничения качества согласуются с владельцем продукта. Выборочная проверка кода продукта не означает автоматического сокращения ревью тестов, и наоборот.
Пропуск теста, ослабление утверждения или изменение ожидаемого результата рассматривается по существу: зелёный прогон сам по себе не подтверждает корректность такого изменения.
Как меняется работа тестировщика
| Режим | Что делает тестировщик | Зачем |
|---|---|---|
| Проверяет результат сам | Выполняет согласованные функциональные проверки; агент может помогать с подготовкой и доступными прогонами | Получить исходное понимание качества и покрыть проверки вне текущего охвата агента |
| Сопоставляет проверки | Рассматривает доказательства агента и независимо перепроверяет согласованные сценарии | Найти пропуски и расхождения, уточнить формат доказательств и область доверия |
| Оценивает доказательства | Рассматривает комплект по задаче, выполняет целевые проверки по риску, недостаткам доказательств и согласованной выборке | Сократить повторение уже подтверждённых проверок, сохранив контроль результата |
Переход относится к конкретным сценариям, а не к тестировщику целиком. Например, типовые формы проверяются по доказательствам, новый сложный сценарий — с независимым выполнением. Исследовательские, пользовательские и иные проверки, не покрытые агентом, остаются у назначенного человека.
Для изменения режима тестировщик показывает сопоставление результатов и известные пробелы, владелец продукта или назначенный владелец качества согласует область и условия. Отсутствие существенных расхождений на согласованном наборе, достаточность доказательств и план целевых проверок должны быть обсуждены до перехода. При недостоверных доказательствах, пропущенном дефекте или новом типе задачи возвращаются к сопоставлению или самостоятельной проверке затронутых сценариев.
Что считать доказательством
Для рассмотрения результата нужны:
- Проверяемые критерии и сценарии: что покрыто, что не проверялось и почему.
- Версия изменения: MR, точная ревизия кода и тестов; для стендовых проверок — идентификатор артефакта в хранилище и запись деплоя.
- Условия: тестовый раннер и образ либо стенд, существенные настройки, данные, моки и время; команда повторного запуска. Отмечается, использован поддерживаемый тест или временный скрипт.
- Ожидаемый и фактический результат, ссылка на прогон, отчёт, журнал или иной подходящий материал.
- Неуспешные, пропущенные и нестабильные проверки, повторные запуски и оставшиеся ограничения.
Сводка агента помогает ориентироваться, но не заменяет доступные материалы проверок. Скриншот может подтвердить отображение, но сам по себе не доказывает всю бизнес-логику. После изменения кода определяют затронутые проверки и обновляют доказательства; результаты от другой ревизии не принимаются как подтверждение нового результата без обоснования применимости.
Итог тестировщика: достаточно для принятия результата в его зоне; нужны конкретные дополнительные проверки; либо выявлен дефект и требуется исправление. Решение с основаниями передаётся руководителю выполнения и владельцу продуктовой приёмки.