На одном из недавних планирований спринта наша команда взяла в работу новую задачу. На бумаге она выглядела простой и не содержала сложной логики. В обычных условиях мы могли бы завершить её за три-четыре дня. Но в действительности новую логику предстояло встроить прямо в высоконагруженные потоки данных, проходящие через несколько микросервисов, где хватало сюрпризов от легаси. И вишенка на торте: даже один пропущенный дефект мог создать существенный финансовый риск. Забегая вперед, - мы быстро справились со всеми сложностями, сохранив необходимый уровень качества. А по пути ещё и создали новый эффективный инструмент для команды. Как нам это удалось? Читайте далее.

Моей первой целью было обеспечить максимально полное тестовое покрытие в отведённое на тестирование время. Но вручную просмотреть 8 000+ документов в Confluence (бизнес-требований, функциональных требований, пользовательских историй и различных спецификаций) было нереально. Я не смог бы удержать весь этот объём информации в голове, связать между собой нужные детали, и на их основе подготовить подходящую тестовую документацию, особенно с учётом дедлайна. Я также понимал, что попытка поручить всю эту работу одному ИИ-агенту за один заход вряд ли дало бы качественный результат.

Решение состояло в том, чтобы разбить общую задачу на небольшие специализированные подзадачи и поручить каждую из них отдельному ИИ-агенту в рамках структурированного процесса. Чтобы процесс оставался управляемым, а результаты надёжными, я придерживался определенных принципов:

• разбивать процесс на небольшие задачи с чёткими границами и одной зоной ответственности;

• задавать для каждого этапа понятные и структурированные форматы входных и выходных данных;

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

• параллельно запускать независимые задачи там, где это повышает эффективность без снижения качества;

• выбирать модели с учётом сложности задачи, требуемой точности и стоимости;

• давать каждому агенту чёткие инструкции, ограничения и критерии успешного выполнения;

• проверять промежуточные артефакты.

В моём случае процесс выглядел следующим образом.

Этап 1. Параллельно определить исходные точки

1. Найти в документации Confluence требования, связанные:

   1. с публикацией сообщений в определённый топик Kafka. Результат - артефакт № 1;

   2. с изменением данных в целевой таблице SQL-базы. Результат - артефакт № 2.

2. Исследовать кодовую базу и найти участки кода, отвечающие за публикацию сообщений в топик Kafka или изменение данных в таблице. Результат - артефакт № 3, карта реализации.

Этап 2. Последовательно проследить сквозные потоки

1. Использовать артефакты № 1 и № 2 как исходные точки для дальнейшего поиска в Confluence. Определить, какие события запускают каждый из ожидаемых потоков и как их можно воспроизвести при тестировании. Результат - артефакт № 4, карта ожидаемых потоков.

2. Сравнить артефакт № 4 с артефактом № 3 и определить:

   1. требования, совпадающие с поведением, найденным в исследованном коде;

   2. ожидаемое поведение, которое, судя по коду, реализовано иначе;

   3. ожидаемое поведение, для которого не удалось найти соответствующую реализацию;

   4. реализованную логику, для которой не удалось найти соответствующие требования.

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

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

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

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

1. Отвечать на вопросы об ожидаемом поведении и поведении, реализованном в текущей production-версии, если для этого достаточно данных, + явно указывать источник ответа: документацию, код задеплоенной версии или конфигурацию.

2. На основе новых требований и Git-ветки/MR объяснять ожидаемое поведение и его реализацию, выявлять возможные расхождения между ними, а также подсвечивать затронутый ранее реализованный функционал и риски покрытия кодом полученных функциональных требований.

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

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

Первую версию такой среды можно собрать в режиме вайб-кодинга (vibe coding) прямо в IDE с поддержкой agentic AI. Но работающий прототип ещё не является надёжным командным инструментом. Рабочие процессы, инструкции и результаты всё равно нужно тестировать и дорабатывать.

High-level architecture of the agentic QA environment

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

Эта статья является переводом моей же публикации Through a High-Risk QA Challenge to an AI-Powered Assistant