За последние пару лет 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-инженера, а становится мощным инструментом, позволяющим нам меньше заниматься рутиной и больше — качеством продукта и сложными исследованиями.
ссылка на оригинал статьи https://habr.com/ru/articles/1024608/