# ИИ-инструмент для QA: как тестировали высокорисковый релиз

> 2026-09-26 · AI Release · @ai_release1

> #QA #ИИ-агенты #тестирование

### ⚡ Главное за 5 секунд - Суть: для тестирования высокорискового релиза в микросервисной среде с легаси команда разбила задачу на подзадачи и поручила их отдельным ИИ-агентам. - Где доступно: инструмент реализован как переиспользуемая среда для агентов Cursor в IDE с поддержкой agentic AI. - Ограничение: первая версия собирается в режиме вайб-кодинга, но прототип требует доработки и тестирования, прежде чем станет надежным командным инструментом. ### 🔍 Что обнаружено На одном из спринтов команда взяла задачу, которая на бумаге выглядела простой, но на деле новую логику нужно было встроить в высоконагруженные потоки данных, проходящие через несколько микросервисов, где хватало сюрпризов от легаси. Даже один пропущенный дефект мог создать существенный финансовый риск. Вручную просмотреть 8 000+ документов в Confluence (бизнес-требования, функциональные требования, пользовательские истории, спецификации) было нереально. Поэтому автор разработал процесс с четырьмя артефактами. Сначала параллельно искали требования, связанные с публикацией сообщений в топик Kafka и изменением данных в целевой таблице SQL-базы, а также исследовали кодовую базу (артефакты №1-3). Затем последовательно строили карту ожидаемых потоков, определяя триггеры и способы воспроизведения, после чего сравнивали её с картой реализации. Сравнение выявляло совпадения, расхождения, реализацию без требований и требования без реализации — каждое утверждение сопровождалось ссылками на Confluence и код. Отчет согласовали с разработчиками и системными аналитиками; данные оказались актуальными и полными, их использовали как точное тестовое покрытие. После того как команда справилась с задачей, автор решил превратить процесс в переиспользуемую среду для агентов Cursor. Среда отвечает на вопросы об ожидаемом и реализованном поведении с указанием источника (документация, код задеплоенной версии или конфигурация), анализирует новые требования и Git-ветку/MR, выявляет расхождения, пробелы и неоднозначности, а также по запросу обновляет базу знаний с разделением поведения в production, в ветке и документированного поведения без реализации. Инструмент уже применяется в команде для поиска дефектов реализации, пробелов в функциональных требованиях и объяснения причин поведения сервисов. ### 💡 Почему это важно Подход решает ключевую проблему тестирования в микросервисных системах с легаси: ручной анализ тысяч документов и кодовой базы занимает слишком много времени и не гарантирует полноту покрытия. Разбиение на специализированные ИИ-агенты с четкими форматами входных и выходных данных позволяет обрабатывать большие объемы информации, связывать требования с кодом и находить расхождения. Инструмент дает команде общий контекст и понимание взаимосвязей между документацией и реализацией, что критично для высокорисковых релизов, где ошибка может привести к финансовым потерям. Возможность обновлять базу знаний и указывать источники делает процесс прозрачным и проверяемым. ### 🧩 Контекст На одном из недавних планирований спринта команда взяла в работу новую задачу. В обычных условиях она заняла бы три-четыре дня, но из-за высокой нагрузки на потоки данных, проходящие через несколько микросервисов, и легаси-сюрпризов риск был значительным. Автор осознавал, что поручить всю работу одному ИИ-агенту за один заход вряд ли получится качественно, поэтому разработал структурированный процесс. Ключевые принципы: небольшие задачи с четкими границами, понятные форматы данных на каждом этапе, передача только необходимого контекста с учетом ограничений окна, параллельный запуск независимых задач, выбор моделей по сложности и стоимости, четкие инструкции с критериями успеха и проверка промежуточных артефактов. Только после согласования результатов с разработчиками и аналитиками нескольких команд отчет был признан актуальным и полным.

[Источник](https://habr.com/ru/articles/1086968/)