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

В QA эта проблема особенно ощутима. Многие считают, что тестирование сводится к запуску тестов и поиску багов. На самом деле значительная часть времени уходит на подготовку: чтение требований, сбор информации, понимание бизнес-логики и создание тестовой документации.

В IT-кластере «СВОЙ Тех», входящем в финтех-группу «Свой», мы системно подошли к этой задаче и начали оптимизировать подготовительные процессы с помощью ИИ.

С чего началось внедрение ИИ в QA

ИИ появился у нас не сразу. Первым шагом стало внедрение двух внутренних регламентов:

• регламент оценки задач QA (estimation);
• регламент учёта рабочего времени QA.

Это позволило впервые увидеть реальную картину загрузки команды. Анализ показал, что большая часть времени тратится не на тестирование, а на подготовку к нему:

• анализ требований из Jira и Confluence;
• поиск связанной документации;
• разбор бизнес-правил;
• подготовка тестовых сценариев и чек-листов;
• оценка объёма тестирования.

В сложных системах это занимает часы и даже дни. Поэтому мы выбрали два ключевых процесса для автоматизации:

• оценка тестирования;
• подготовка тестовой документации.

Именно здесь мы начали применять ИИ.

Почему именно анализ требований

Проблема знакома многим QA: информация о фиче разбросана по разным источникам:

• Jira-тикет;
• acceptance criteria;
• страницы Confluence;
• вложения;
• комментарии в задачах.

Чтобы подготовиться к тестированию, нужно собрать всё вместе и понять:

• как должна работать система;
• какие сценарии возможны;
• какие данные участвуют;
• какие ошибки могут возникнуть.

По сути, QA-инженер выполняет роль аналитика. Мы решили: если эту работу можно формализовать, её можно частично автоматизировать.

Система из трёх ИИ-агентов

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

1. Агент-координатор (Workflow Coordinator)

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

2. Агент исследования требований (Requirements Researcher)

Этот агент собирает информацию:

• описание Jira-тикета;
• acceptance criteria;
• связанные страницы документации;
• вложения.

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

3. Агент архитектуры тестирования (QA Test Design Architect)

Третий агент помогает QA подготовиться к тестированию. На основе структурированных требований он:

• разбивает функциональность на сценарии;
• выявляет ключевые ветки логики;
• формирует базовое тестовое покрытие;
• помогает оценить объём тестирования.

Pipeline работы ИИ-агентов

┌─────────────────────────────┐
│     QA / Product        │
│   Jira / Confluence / Docs │
└──────────────┬──────────────┘
┌────────────────────────────┐
│   Agent 1: Workflow      │
│     Coordinator       │
│                          │
│ • управляет процессом    │
│ • делегирует задачи      │
│ • объединяет результаты  │
└──────────────┬─────────────┘
┌────────────────────────────┐
│   Agent 2: Requirements  │
│     Researcher        │
│                          │
│ • собирает требования    │
│ • извлекает данные из    │
│   Jira / Confluence      │
│ • формирует корпус       │
└──────────────┬─────────────┘
┌─────────────────────────────┐
│   Agent 3: QA Test Design  │
│   Architect                │
│                            │
│ • анализирует требования  │
│ • строит тестовые сценарии │
│ • оценивает объём тестов  │
└──────────────┬──────────────┘
┌─────────────────────────────┐
│     QA Engineer       │
│   Ревью чек-листа +       │
│   уточнения требований   │
└─────────────────────────────┘

Финальные решения по-прежнему принимает QA. Но значительная часть аналитики уже выполнена автоматически.

Что изменилось в работе QA

После внедрения цепочки агентов подготовка к тестированию стала значительно быстрее. Раньше QA вручную:

• искал информацию по разным страницам;
• разбирал требования;
• составлял структуру тестов.

Теперь большая часть этой работы автоматизирована. QA получает:

• структурированные требования;
• список потенциальных пробелов в них;
• базовую структуру тестового покрытия.

На этой основе инженер формирует финальные тесты.

Результат: минус 70% времени на подготовку

По нашим оценкам, время подготовки к тестированию сократилось на 70%.

Важно понимать: речь не о полной автоматизации. ИИ не заменяет QA. Он снимает рутинную аналитическую нагрузку.

Теперь QA могут больше времени уделять:

• сложным сценариям;
• исследовательскому тестированию;
• анализу рисков;
• UX-тестированию.

Практика: где реально экономится время

Возьмём типичную задачу с оценкой 4 часа на подготовку. Раньше QA тратил это время на чтение, поиск информации и написание документации.

Теперь процесс выглядит иначе:

Исследование
AI анализирует требования, выявляет пробелы и связанные сущности (например, таблицы БД).
Экономия: –1 час

Тест-дизайн
Агент генерирует тестовую модель: сценарии, critical path, регрессионные проверки.
Экономия: –2 часа

Итог: вместо 4 часов — 1–2 часа активной работы QA. Экономия — до 70%.

Что оказалось самым полезным

Самый ценный эффект — не ускорение, а раннее выявление проблем в требованиях. ИИ быстро находит:

• отсутствующие сценарии;
• неполные бизнес-правила;
• ссылки на несуществующие документы;
• противоречия между требованиями.

Иногда такие проблемы обнаруживаются до начала разработки — это напрямую снижает стоимость исправлений.

Обратная сторона: почему нельзя слепо доверять ИИ

На практике выявился важный нюанс. Возьмём простую задачу — добавление поп-апа на страницу, оценённую в 4 часа.

ИИ-агенты работают корректно: собирают требования и строят чек-лист. Но возникает проблема:

• Человек мыслит узко: «Есть поп-ап — тестируем его поведение».
• ИИ мыслит широко: «Есть страница + поп-ап + весь связанный функционал — проверяем всё».

Это приводит к избыточным проверкам и завышенной оценке. ИИ делает «слишком хорошо», но не оптимально. Поэтому финальное ревью тестовых сценариев остаётся за инженером.

Безопасность и данные

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

Мы изначально выстроили ограничения на уровне инфраструктуры:

• агент по анализу требований работает под учётной записью в Confluence с ограниченными правами;
• он видит только явно переданные источники (Jira, связанные страницы, вложения);
• не использует внешние данные.

Принцип — минимально необходимый доступ. Агент видит ровно столько, сколько нужно для задачи. Разделение ролей (сбор и анализ) дополнительно снижает риски. Это делает использование ИИ в QA предсказуемым и контролируемым — особенно важно для enterprise-команд.

Что дальше

Мы продолжаем развивать систему. В планах — применение ИИ-агентов для:

• анализа регрессионного покрытия;
• обновления тестовой документации;
• поиска зон риска в изменениях;
• создания AI-баг-репортов;
• анализа прогонов автотестов.

Это пока экспериментальная область, но уже ясно: ИИ может стать для QA тем же, чем когда-то стали системы автоматизированного тестирования. Он не заменяет инженера, а становится мощным инструментом, позволяющим меньше заниматься рутиной и больше — качеством продукта и сложными исследованиями.

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

В QA эта проблема особенно заметна. Многие думают, что тестирование — это в основном запуск тестов и поиск багов. На практике значительная часть времени уходит на совсем другие вещи: чтение требований, сбор информации из разных источников, попытки понять реальную бизнес-логику и подготовку тестовой документации.

В «СВОЙ Тех»,  IT-кластере финтех-группы «Свой», мы решили посмотреть на эту проблему системно и попробовать оптимизировать часть этой работы с помощью AI.

С чего началось внедрение AI в QA

Интересно, что AI появился у нас в процессе не сразу. Первым шагом стало внедрение двух внутренних регламентов:

·       регламент оценки задач QA (estimation);

·       регламент учёта рабочего времени QA.

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

·       анализ требований из Jira и Confluence;

·       поиск связанной документации;

·       разбор бизнес-правил;

·       подготовка тестовых сценариев и чек-листов;

·       оценка объёма тестирования.

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

1. Эстимация тестирования2. Подготовка тестовой документации

Именно здесь мы решили попробовать использовать AI.

Почему именно анализ требований

Проблема знакома почти каждому QA:

информация о фиче обычно разбросана по нескольким источникам:

·       Jira тикет

·       acceptance criteria

·       Confluence страницы

·       вложения

·       иногда ещё и комментарии в задачах

Чтобы подготовиться к тестированию, нужно собрать всё это вместе и понять:

·       как должна работать система;

·       какие сценарии возможны;

·       какие данные участвуют в процессе;

·       какие ошибки могут возникнуть.

По сути, QA-инженер выполняет роль аналитика и исследователя. Мы подумали: если эту часть работы можно формализовать, возможно её можно хотя бы частично автоматизировать.

Система из трёх AI-агентов

Вместо одного «умного» промпта мы решили разделить задачи между несколькими AI-агентами. Получилась небольшая цепочка, где каждый агент выполняет свою роль.

1. Агент-координатор (Workflow Coordinator)

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

2. Агент исследования требований (Requirements Researcher)

Второй агент занимается сбором требований. Он собирает всю информацию, связанную с задачей:

·       описание Jira тикета

·       acceptance criteria

·       связанные страницы документации

·       вложения

После этого данные структурируются и превращаются в единый корпус требований.

Важный момент — агент не интерпретирует требования и не переписывает их. Он только извлекает и структурирует информацию. Это позволяет сохранить исходный смысл документации.

3. Агент архитектуры тестирования (QA Test Design Architect)

Третий агент помогает QA-инженеру подготовиться к тестированию. На основе собранных требований он:

·       разбивает функциональность на сценарии;

·       выявляет основные ветки логики;

·       помогает сформировать тестовое покрытие;

·       помогает оценить объём тестирования.

Pipeline работы AI-агентов

┌─────────────────────────────┐

│    QA / Product     │

│   Jira / Confluence / Docs │

└──────────────┬──────────────┘

┌────────────────────────────┐

│   Agent 1: Workflow     │

│    Coordinator      │

│                         │

│ • управляет процессом   │

│ • делегирует задачи     │

│ • объединяет результаты │

└──────────────┬─────────────┘

┌────────────────────────────┐

│   Agent 2: Requirements │

│    Researcher       │

│                         │

│ • собирает требования   │

│ • извлекает данные из   │

│   Jira / Confluence     │

│ • формирует корпус      │

└──────────────┬─────────────┘

┌─────────────────────────────┐

│   Agent 3: QA Test Design │

│  Architect          │

│                         │

│ • анализирует требования │

│ • строит тестовые сценарии │

│ • оценивает объём тестов │

└──────────────┬──────────────┘

┌─────────────────────────────┐

│    QA Engineer      │

│   Ревью чек-листа +  │

│   уточнения требований  │

└─────────────────────────────┘

QA по-прежнему принимает финальные решения, но значительная часть подготовительной аналитики уже сделана.

Что изменилось в работе QA

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

·       искать информацию по нескольким страницам,

·       разбирать требования,

·       составлять первичную структуру тестов,

то теперь большая часть этой работы выполняется автоматически.

QA-инженер получает:

·       структурированный набор требований;

·       список потенциальных пробелов в требованиях;

·       базовую структуру тестового покрытия.

И уже на этой основе формирует финальные тесты.

Результат: минус 70% времени на подготовку

По нашим внутренним оценкам, время подготовки к тестированию сократилось примерно на70%.

Важно понимать, что речь не идёт о полной автоматизации QA. AI не заменяет инженера. Он просто снимает значительную часть рутинной аналитической работы.

В результате QA может больше времени уделять тому, что действительно важно:

·       сложным сценариям;

·       исследовательскому тестированию;

·       анализу рисков;

·       UX тестированию

Практика: где реально экономится время

Чтобы не быть голословными, разберём на простом примере, как это работает в реальной задаче.

Представим типичную задачу с оценкой 4 часа на подготовку к тестированию. В классическом процессе QA тратит это время на чтение требований, поиск недостающей информации, понимание связей и написание тестовой документации.

В нашей модели процесс выглядит иначе. Координатор запускает цепочку агентов, и уже на этапе изучения требований мы получаем первую экономию. Агент автоматически собирает требования из Jira и Confluence, выявляет пробелы (GAP’ы) и находит связанные сущности — например, таблицы в базе данных или связанные части функциональности. Это даёт примерно –1 час за счёт сокращения ручного анализа.

Основной выигрыш происходит дальше. Агент архитектуры тестирования берёт готовый корпус требований и генерирует тестовую модель: сценарии, critical path, регрессионные проверки. Здесь экономится ещё около 2 часов, потому что QA не пишет всё с нуля, а работает уже с подготовленной структурой.

Действие агента

Исследование

AI анализирует требования, выявляет пробелы и связанные сущности (БД, смежный функционал).

–1 час ручного анализа.

Тест-дизайн

Генерирует тестовую модель: сценарии, Critical Path, регресс.

–2 часа, так как QA работает с готовой структурой, а не с чистым листом.

Итог:Вместо 4 часов мы получаем1–2 часаактивной работы QA. Экономия времени на подготовку составляетдо 70%.

Что оказалось самым полезным

Самым неожиданным эффектом стало даже не ускорение работы. Гораздо ценнее оказалосьраннее выявление проблем в требованиях. AI довольно быстро находит вещи, которые часто остаются незамеченными:

·       отсутствующие сценарии;

·       неполные бизнес-правила;

·       ссылки на несуществующие документы;

·       противоречия между требованиями.

Иногда такие проблемы обнаруживаются ещё до начала разработки. А это уже напрямую влияет на стоимость исправления ошибок.

Обратная сторона: почему нельзя слепо доверять AI

Но есть важный нюанс, который быстро проявился на практике. Возьмём похожую задачу — тоже с оценкой 4 часа, только уже на тестирование, но, по сути, более простую: например, добавление поп-апа на страницу.

AI-агенты отрабатывают корректно: агент исследования собирает все требования по странице, агент тест-архитектуры строит чек-лист. Но возникает проблема:

• Человекмыслит узко (оптимально): «Есть поп-ап — тестируем его поведение».
• ИИ-агентмыслит максимально широко: «Есть страница + поп-ап + весь связанный функционал — проверяем всё».

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

Безопасность и данные

Для финтеха вопрос конфиденциальности критичен. Когда агенты начинают работать с требованиями, они фактически получают доступ к чувствительной информации: бизнес-логике, внутренним процессам, архитектурным решениям. Поэтому здесь важно изначально выстраивать ограничения не на уровне «доверия к AI», а на уровне инфраструктуры доступа. Например, для конфиденциальности наших спецификаций для агента по анализу требований заведен юзер в Confluence с ограниченной ролью, где недоступны определенные страницы. Это позволяет гарантировать, что агент физически не сможет получить доступ к данным вне своего рабочего контура.

Дополнительно безопасность обеспечивается самим подходом к работе агентов: они обрабатывают только явно переданные источники (Jira, связанные страницы, вложения) и не используют внешние данные. Вся логика построена вокруг принципа минимально необходимого доступа — агент видит ровно столько, сколько нужно для выполнения задачи, и не больше. В сочетании с разделением ролей (отдельный агент на сбор требований, отдельный — на анализ) это снижает риск утечек и делает использование AI в QA-процессах предсказуемым и контролируемым, что особенно критично для продуктовых и enterprise-команд.

Что дальше

Сейчас мы продолжаем развивать эту систему. В планах — использовать AI-агентов и для других задач QA:

·       анализ регрессионного покрытия;

·       помощь в обновлении тестовой документации;

·       поиск потенциальных зон риска в изменениях,

· создание AI баг-репортов,

· анализ прогона автотестов

Пока это всё ещё экспериментальная область, но уже сейчас понятно: AI может стать для QA тем же, чем когда-то стали системы автоматизированного тестирования. При этом ИИ не заменяет QA-инженера, а становится мощным инструментом, позволяющим нам меньше заниматься рутиной и больше — качеством продукта и сложными исследованиями.