Amazon AMET Payments ускорил генерацию тест-кейсов в 20 раз: как мультиагентная ИИ-система трансформировала QA

Команда Amazon AMET Payments, управляющая платёжными системами для 10 миллионов клиентов в пяти странах, ежемесячно выпускает около пяти новых функций. Раньше глубокое тестирование каждой из них занимало целую неделю ручного труда: анализ документации, макетов, требований, прошлых тестовых подготовок. После внедрения мультиагентной ИИ-системы тот же объём работы стал укладываться в несколько часов. Ускорение составило 20 раз, а ресурс, который раньше требовал одного штатного инженера на целый год, перестал быть узким местом.

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

Как выглядел процесс до ИИ-агентов

До автоматизации каждый новый проект в Amazon AMET Payments начинался одинаково: QA-инженер брал стопку документов и начинал разбирать их вручную. Бизнес-требования, проектная документация, макеты пользовательского интерфейса, записи о прошлых тестовых кампаниях — всё это нужно было прочитать, сопоставить и превратить в конкретный набор тест-кейсов. На один проект уходила неделя. При пяти новых функциях в месяц это означало, что один инженер буквально весь год занимался только этим.

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

Почему простой ИИ не закрывал вопрос

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

Генерация тест-кейсов, это не поиск по документу и не пересказ требований. Это мыслительный процесс: нужно понять, кто пользователь, какой путь он проходит, где система может повести себя неожиданно, какие граничные случаи важны именно для платёжного сервиса. Опытный QA-инженер делает это интуитивно, потому что держит в голове одновременно несколько слоёв: бизнес-логику, UX, сегменты клиентов, переходы состояний. Один агент с большим контекстом не мог воспроизвести этот процесс: он либо скользил по поверхности, либо тонул в деталях без структуры.

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

Каким спроектировали мультиагентную систему

Систему назвали SAARAM (QA Lifecycle App). Её ключевая идея, декомпозиция сложной задачи на управляемые подзадачи, каждую из которых выполняет специализированный агент. Такой подход имитирует работу реальной команды, где разные специалисты отвечают за разные аспекты тестирования.

• Агенты анализа документов. Первый слой системы, извлечение и структурирование информации. Эти агенты разбирали бизнес-требования, проектную документацию и макеты, вычленяя критерии приёмки, пользовательские сценарии, требования к UX и данные о целевых пользователях. Результатом становилась первичная база знаний, с которой работали следующие агенты.
• Агенты разработки тестов. Второй слой, систематическое создание тест-кейсов. Агенты анализировали пользовательские пути, выявляли потенциальные сценарии, картировали потоки данных и на основе всего этого формировали конкретные, детализированные тест-кейсы с пошаговыми инструкциями и ожидаемыми результатами. Не «проверить оплату», а точный сценарий с входными данными, действиями и ожидаемым исходом.
• Специализированные агенты для итераций. Третий слой отвечал за глубину охвата. Отдельные агенты занимались сегментацией клиентов: «новые пользователи», «постоянные клиенты», «пользователи из разных стран» — каждый сегмент получал собственный набор сценариев. Другие агенты картировали пользовательские пути для каждого сегмента, анализировали покрытие и управляли переходами состояний в системе: «до оплаты», «в процессе», «после оплаты», «при ошибке».

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

Как внедряли и адаптировали команду

Внедрение началось с пилотной группы. Принципиальное решение, не ломать привычные рабочие процессы, а встроить систему в них. SAARAM дополнял самые трудоёмкие этапы, не требуя от инженеров осваивать принципиально новый интерфейс или менять логику работы. Агенты брали на себя анализ и первичную генерацию; инженер получал готовый набор тест-кейсов и работал с ним дальше.

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

Результаты

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

Как перенести это на ваш бизнес

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

• Найдите задачу, которая требует анализа большого объёма текстов. QA, юридический отдел, комплаенс, аналитика — везде, где специалист регулярно разбирает документацию и создаёт на её основе структурированные выводы, ИИ-агенты могут взять на себя первичный анализ и черновую генерацию.
• Декомпозируйте задачу на узкие слои. Один агент, одна специализация. Агент, который извлекает требования, не должен одновременно генерировать тест-кейсы. Разделение по слоям даёт точность, которой не добиться от единого универсального агента.
• Имитируйте мышление лучшего специалиста, а не среднего. Перед проектированием агентов поговорите с самым опытным человеком в команде: как он декомпозирует задачу, на что обращает внимание в первую очередь, какие сегменты и граничные случаи проверяет. Эта логика и должна лечь в основу агентов.
• Встраивайте, не заменяйте. Агенты должны дополнять привычный рабочий процесс, а не требовать его перестройки. Чем меньше инженер меняет свои привычки, тем быстрее система станет частью ежедневной работы, а не экспериментом.
• Начните с пилота и дорабатывайте по обратной связи. Запустите систему на одном типе задач, соберите обратную связь от первых пользователей и откалибруйте агентов. Только после этого масштабируйте на остальные команды.

Если этот кейс похож на то, что происходит у вас, наш менеджер поможет разобраться: бесплатно проанализирует ваш бизнес и нишу и подскажет, где ИИ-агент даст реальный результат именно в вашем случае. Написать менеджеру