Как мы строили своего AI-агента для генерации тестовой документации — опыт QA-команды мобильных секретарей

Привет, Хабр! На связи QA-команда мобильных секретарей — Настя и Ксюша.

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

В итоге на то, чтобы собрать все воедино, проанализировать и написать качественные чек-листы или тест-кейсы, уходит много времени. В какой-то момент мы подумали: «А что, если создать AI-агента, заточенного под наши процессы, который будет делать это за нас?». Так и родился наш проект.

Рассказываем, как это было.

Идея и задачи — зачем нам свой агент

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

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

Цель сформулировалась просто: нам хотелось бы иметь такую систему, которая способна самостоятельно:

• искать нужную информацию в Confluence,

• быстро выдавать ответы на частные вопросы (например, по параметрам тестовых тарифов и функциональности),

• автоматически генерировать тестовую документацию по новым фичам или обновлениям,

• делать саморевью с поиском противоречий и автоматическим улучшением итоговых кейсов.

Архитектура и стек технологий

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

Jay Flow ― low-code среда для проектирования логики агента, настройки сценариев и интеграции с внешними источниками данных. Именно в Jay Flow мы собирали основной workflow: от запроса пользователя до генерации и саморевью документации.

Jay Knowledge Hub ― рабочая база знаний, индексирующая документацию из Confluence по принципу RAG:

• Агент ищет релевантные фрагменты по ключевым словам в базе знаний.

• Затем определяет, где лежит нужный документ, и через отдельный модуль Connect Confluence получает к нему доступ.

Модуль Connect Confluence ― отдельный компонент, позволяющий агенту работать не только с фрагментами, но с полным текстом нужного документа.

LLM Gemini 2.5 Pro ― используемая языковая модель для генерации и последующего анализа тестовой документации.

Web UI Jay Flow — интерфейс взаимодействия. При создании Агента, чат не нужно самостоятельно создавать чат, он уже встроен.

В планах ― интеграция с TestOps (для выгрузки кейсов непосредственно в тест-менеджер), а также доступ к Jira, SharePoint, Git как к дополнительным источникам знаний о проекте.

Как все работает

В самом начале мы решили идти простым путем — использовать хорошо знакомые инструменты: Jay Flow как среду для сборки логики агента, Jay Knowledge Hub для хранения и поиска знаний, и интеграцию с Confluence как источник всей живой информации проекта.

Первые дни были похожи на исследовательский спринт: тест-документации в проекте много, структуры порой пересекаются, названия похожи. Мы задумали так: если умеем искать по ключевым словам через собственный Knowledge Hub, пусть агент находит релевантные куски текста, а дальше уже по ссылке идет и читает целый документ через дополнительный модуль Connect Confluence.

В итоге в типовом сценарии агент реализует следующий цикл:

1. В интерфейсе Web UI Jay Flow появляется запрос — например, «сформируй чек-листы по новой объективке»

2. Агент обращается в Knowledge Hub и ищет релевантные документы.

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

4. Запускается LLM (Gemini 2.5 Pro). В зависимости от запроса пользователя, модель выбирает один из двух специальных промптов — для генерации чек-листа или тест-кейсов — и создает черновой вариант документации, следуя принятым в нашей команде правилам.

5. Срабатывает наш custom-промпт для саморевью: модель анализирует свою же работу на соответствие требованиям, указывает на недочеты и выявляет пробелы.

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

Проблемы и решения

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

Вот с какими сложностями мы столкнулись:

Авторизация и токены

Один из неожиданно частых источников сбоев был процесс авторизации. Токен был указан в функции API ConnectConfluence. Агент периодически терял токен доступа к Confluence, из-за чего переставал видеть актуальные документы. Он его просто забывал, иногда делал в нем опечатку или почему-то отправлял в кавычках.

Решение нашли самое простое: писали агенту «Используй токен», и он возвращался к своим инструкциям и брал его в работу.

Полезный лайфхак был таким: если Confluence API возвращал ошибку 403 — скорее всего, это была проблема на стороне агента, и нужно было попросить его повторить попытку. А вот 401 уже означала более серьезную ситуацию — токен действительно истек.

Запоминание контекста. А где ревью?

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

Проблема решается простым пингом с вопросом: «А где ревью?». Он тут же извиняется и доделывает работу. Ему не нужно объяснять, что делать, он помнит контекст диалога, но легкий толчок бывает необходим.

Обработка внешних ссылок

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

Языковые нюансы

Промпты сразу настраивались на работу на русском, но иногда часть ответа «перерабатывалась» на английском (особенность используемой LLM). В этом случае помогало прямое указание в промте, что ответ должен быть всегда только на русском языке.

Ограничения поиска
Порой, найдя несколько релевантных документов, он брал в работу только один — самый, на его взгляд, релевантный. Приходилось спрашивать: «А все ли ты учел?». После этого он находил и остальные источники и дорабатывал документацию.

Многие из этих проблем нашего агента — не уникальные баги, а прямое следствие ограничений, присущих самим языковым моделям. Чтобы лучше понимать, почему он ведет себя так, а не иначе, и не требовать от него невозможного, полезно сделать небольшое отступление. О нем пойдет речь дальше.

Типовые проблемы LLM, о которых важно помнить

1. Лимит контекстного окна и «забывчивость». Модель может помнить лишь ограниченный объем информации за раз. Если диалог становится слишком длинным, модель начинает вытеснять из памяти ранние детали. Это ведет к потере связности и нарушению логики в длинных сессиях. Именно поэтому наш агент иногда забывал про ревью — у него нет долгосрочной памяти, как у человека.

2. Склонность к галлюцинациям и избыточная уверенность. Языковая модель всегда старается дать ответ, даже если не знает его. Она может уверенно синтезировать ложные факты, несуществующие ссылки или программный код, опираясь на вероятность, а не на реальность. Наш случай, когда агент уверенно заявлял о доступе к SharePoint, — яркий тому пример.

3. Зависимость от качества промпта. Модель точно следует структуре и тону запроса. Нечеткая или двусмысленная инструкция почти гарантированно приведет к неверному результату, который легко принять за «глупость» модели, хотя это лишь следствие неточного промпта.

Это закономерное поведение LLM. Когда понимаешь их природу, агент перестает казаться «капризным» и становится вполне управляемым инструментом.

А дальше — о том, как он действительно нам помогает и экономит время.

Что агент умеет хорошо и почему он уже экономит нам время

Ксения Волкова

QA Engineer

Несмотря на все эти причуды, агент оказался невероятно полезным. Уже через несколько недель стал выполнять значительную часть рутинных задач QA-команды:

• Нам не приходится вручную собирать и перепроверять чек-листы при обновлениях в проекте. Ранее среднее время на анализ документации, написание черновика тестовой документации и командное ревью составляло 4-5 человеко-часов, часто растягиваясь на несколько дней из-за отвлечений, восстановления контекста и ожидания коллег. С Агентом этот процесс занимает около 5 минут на генерацию и примерно 20 минут на проверку его вопросов и доработку.

• Первичное формирование тест-кейсов и последующие доработки теперь — вопрос нескольких минут.

• Поиск конкретных параметров или значимых артефактов происходит мгновенно.

• Агент сигнализирует о возможных противоречиях в документации и выводит замечания без необходимости ручного сопоставления файлов.

Благодаря продуманным промптам, структура генерируемых тест-кейсов и чек-листов уже удобна, что позволяет сразу брать их в работу. До переноса в TestOps мы храним их прямо в Confluence.

Ожидаемый экономический эффект — сокращение времени на оформление тестовой документации на десятки человеко-часов в месяц, а также повышение качества покрытия за счет автоматизированной валидации и поиска пробелов.

Что дальше

В планах — расширить интеграцию с TestOps для полностью бесшовного перехода от генерации к публикации кейсов, подключить дополнительные источники знаний (Jira, Git, SharePoint) и постепенно унифицировать логику работы с различными проектами.

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

Выводы

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

Если же вы вы хотите построить целую систему из нескольких AI-агентов, которые вместе управляют сложными рабочими процессами и решают задачи с повышенными требованиями к безопасности, — тогда присмотритесь к нашей Agent Platform. Она позволяет централизованно управлять интеграциями и коннекторами, а также легко масштабироваться и тонко настраивать поведение агентов.

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

P.S. Друзья, будем рады вопросам. Если вы внедряете AI-помощников в свои QA-процессы — делитесь опытом в комментариях, вместе получится быстрее и эффективнее.

А для более глубокого погружения в тему — архитектуру агентов, RAG-подход, интеграции с корпоративными системами или реальные сложности, с которыми вы сталкиваетесь в проектах, — присоединяйтесь к нашему Telegram-комьюнити для разработчиков. Там мы делимся находками, сложностями и решениями. Обсуждаем, как выжать максимум из AI-инструментов в продакшене. Будем рады видеть вас в чате!