Агентный ИИ в QA: как превратить тестирование высокорискового релиза в работающий инструмент
Тестирование релиза в высоконагруженной среде с легаси-компонентами и жесткими сроками традиционно сопряжено с колоссальным риском пропущенных дефектов. Однако команда разработчиков продемонстрировала, что использование агентов ИИ, специализированных на разборе требований и кода, позволяет не только гарантировать качество при введении новой логики в микросервисы, но и создать масштабируемый инструмент для постоянного мониторинга соответствия кода документации.
# От ручного анализа к агентной среде: новый подход к тестированию рискованных релизов
Вызовы сложной архитектуры и сжатые сроки
Команда столкнулась с задачей внедрения новой бизнес-логики в высоконагруженные потоки данных. Архитектура проекта характеризуется высокой степенью сложности: данные проходят через цепочку микросервисов, часть из которых содержит устаревший (легаси) код. Отсутствие возможности отложить разработку и риск финансовых потерь при даже единичном дефекте создали условия экстремального стресс-теста для отдела качества.
Обычно на подготовку тестовых сценариев для задачи подобного уровня требуется от трех до четырех дней работы целой группы аналитиков. В данном случае ограничение по времени было жестким, а объем информации для анализа превышал возможности человеческого восприятия.
Стратегия параллельной работы специализированных агентов
Первоочередной целью было обеспечить полное тестовое покрытие в рамках строгого дедлайна. Объем документации, состоящей из более чем 8 000 страниц в Confluence (бизнес-требования, пользовательские истории, технические спецификации), делал невозможным ручной полный просмотр или попытку запоминания всех деталей. Попытка передать всю эту информацию одному ИИ-агенту с последующим генерацией тестов привела бы к потере контекста и снижению точности результата.
Решение заключалось в деконструкции общей задачи на узкоспециализированные подзадачи. Вместо одного универсального агента были созданы отдельные агенты, каждый из которых отвечал за конкретный этап анализа. Этот подход позволил соблюсти три ключевых принципа: 1. Четкое разграничение зон ответственности: каждая подзадача имела ограниченный контекст и понятные входные данные. 2. Параллелизм: независимые задачи запускались одновременно, что ускорило сбор информации без потери качества. 3. Верификация контекста: для каждого агента выбирались модели, соответствующие сложности этапа, с жестким контролем входных и выходных данных.
Процесс был разбит на два основных этапа генерации артефактов:
1. Идентификация точек входа: Агенты параллельно находили в документации требования, связанные с публикацией сообщений в топик Kafka и изменениями в SQL-таблицах. Одновременно проводился анализ кодовой базы для локализации участков, отвечающих за эти операции. Результатом стала карта реализации (артефакт №3). 2. Сквозной анализ потоков: На основе найденных требований строилась карта ожидаемых потоков (артефакт №4). Сопоставление этой карты с найденным в коде реализованным поведением позволило выявить расхождения: случаи, когда код не соответствует требованиям, и требования, для которых код отсутствует.
Критически важным было создание ссылок на конкретные страницы Confluence и строки кода в каждом выводе. Это обеспечило возможность проверки каждого тезиса по первоисточнику. Полученный отчет служил основой для формирования полного покрытия тестовыми кейсами, которое было согласовано с разработчиками и системными аналитиками.
Создание переиспользуемой среды для агентов
Успех одного кейса побудил авторов систематизировать процесс в инструмент, пригодный для постоянного использования. Целью стало создание среды, работающей непосредственно в среде разработки (IDE), которая наделяет агентов пониманием взаимосвязей между документацией, кодом и фактическим поведением сервисов в продакшене.
Функционал разработанной агентной среды включает: * Ответы на вопросы: объяснение ожидаемого поведения системы или фактического поведения в текущей версии продукта, с обязательной привязкой к источнику данных (код, документация или конфиги). * Анализ изменений: по запросу Git-ветки или MR (Merge Request) система определяет, как ожидаемое поведение соотносится с реализованным, выявляя пробелы в покрытии кода. * Обновление базы знаний: автоматическое обновление эталонных данных при каждом изменении требований или кода, с разделением на поведение в продакшене, поведение в ветке разработки и теоретические требования без реализации.
Первая версия такой среды была создана в режиме экспресс-разработки (vibe coding), однако дальнейшая работа направлена на превращение прототипа в надежный инструмент для командного использования, способный не только находить дефекты, но и предотвращать их возникновение на этапе анализа требований.
В современном контексте тестирования качества программного обеспечения переход от ручных проверок к управляемым ИИ-агентам позволяет справиться с парадоксом возрастающей сложности систем и жестких временных рамок.