Epsilon, компания в области данных, технологий и маркетинговых услуг и часть Publicis Groupe, перевела UI-тестирование в формат управляемого сервиса. Внутренняя команда Agentic Platform из 50 инженеров собрала мультитенантную платформу, в которой тест описывается обычным английским текстом, а браузер для выполнения приходит со стороны AWS. Роли распределены так: Amazon Nova Act выполняет намерения, сформулированные на естественном языке, Amazon Bedrock AgentCore Browser Tool предоставляет управляемые браузерные сессии.
Границы кейса стоит обозначить сразу. Сервис не заменяет регрессионный набор на Playwright: тот остаётся регрессионной основой и сегодня. Интент-тесты добавляют второй класс проверок, устойчивый к косметическим правкам интерфейса, и не требуют ни инспекции DOM, ни подбора селекторов.
Цифры, которые Epsilon приводит в своей публикации: 18-шаговый сценарий пишется за 5–10 минут, а эквивалентный скрипт на Playwright занимает 30–90 минут и 80–150 строк кода. Сохранённые траектории при повторном воспроизведении проходят в 100% случаев. Это внутренние замеры компании на её сценариях и её стеке, а не независимый бенчмарк. Исходный разбор кейса опубликован в блоге AWS Machine Learning.
Дальше по порядку: почему команда вообще взялась за второй инструмент, из чего состоит сервис, как выглядит шаг теста на естественном языке и где у подхода пределы.
Почему Playwright перестало хватать и почему его не выбросили
Playwright хорошо делает то, для чего его писали: детерминированные регрессионные проверки. Слабое место в другом. Скрипт жёстко связан с селекторами и структурой страницы. Дизайнер поменял разметку кнопки, функциональность осталась рабочей, а тест упал. Каждое такое падение требует ручной инспекции DOM и правки локаторов.
Основная цена держится не в написании теста, а в его обслуживании. Локаторы устаревают после каждого редизайна, падения приходят пачками и часть из них не про баг, а про вёрстку. Инженер вместо проверки нового функционала чинит селекторы. Чем активнее продуктовая команда меняет интерфейс, тем дороже выходит такой набор.
Поэтому в Epsilon разделили два класса проверок. Детерминированная регрессия осталась на Playwright: точные проверки конкретных элементов и сценариев, где важна строгая воспроизводимость. Проверка пользовательских намерений ушла на Nova Act: тест фиксирует, что пользователь хотел сделать и какой результат увидел. Это разные задачи, и подменять одну другой никто не пытался.
Историю про масштабирование агентного QA на несколько команд с ролями, приложениями и health score разбирает отдельный материал: QA Studio на Amazon Nova Act.
Что такое Amazon Nova Act и AgentCore Browser Tool и как они работают вместе
Amazon Nova Act отвечает за слой выполнения намерений. Шаг теста формулируется как цель или действие в интерфейсе, а не как последовательность кликов по координатам и селекторам. Агент сам решает, куда нажать и что проверить, чтобы прийти к описанному результату.
Amazon Bedrock AgentCore Browser Tool даёт управляемые браузерные сессии. Браузер живёт на стороне AWS, поэтому команде не нужно держать собственные бинарники браузеров, display-серверы и головную боль с их обновлением и масштабированием. Browser Tool входит в состав возможностей платформы Amazon Bedrock AgentCore.
Связка получается простой по смыслу: Nova Act решает, что делать, Browser Tool предоставляет браузер, в котором это делается. Для Epsilon такое разделение сняло целый слой инфраструктурной работы.
У управляемых сервисов есть обратная сторона, и её честно держать в голове. Вы получаете браузерные сессии как услугу и одновременно попадаете в зависимость от доступности, квот и поведения внешнего провайдера. Свой парк браузеров вы контролируете полностью, но платите за это инженерным временем.
Архитектура сервиса: от API платформы до шага в браузере
Продуктовые команды Epsilon обращаются к той же поверхности API, что и для остальных агентных возможностей платформы. Это принципиальный момент: UI-тестирование не отдельный зоопарк с собственными кредами и контрактами, а ещё одна возможность внутри общей платформы. Сама платформа даёт командам skills-based agent builder, федеративную идентификацию и pre-flight авторизацию, интеграцию Model Context Protocol (MCP) и кросс-аккаунтное провижинирование.
Дальше запрос проходит через очередь, попадает к исполнителю, поднимается браузерная сессия, выполняется шаг, результат возвращается в платформу. Публичное описание кейса даёт этот поток на уровне компонентов; конкретные конфигурации очередей, лимиты и политики в открытом тексте не раскрыты, поэтому ниже речь о принципах, а не о готовых настройках.
Очередь SQS и runner на ECS: как разделяются запросы команд
Очередь Amazon SQS развязывает приём запроса и его выполнение. Браузерная сессия с работой AI-агента занимает заметно больше времени, чем обычный синхронный вызов API, и держать HTTP-соединение всё это время незачем. Запрос встаёт в очередь, runner на Amazon ECS забирает задачу и запускает прогон.
Такая схема выдерживает несколько продуктовых команд на одном сервисе. Задачи не выполняются в одном процессе, у каждого прогона своя сессия, а общая нагрузка распределяется по исполнителям. Очередь заодно даёт буфер на пиках: всплеск прогонов перед релизом не роняет сервис, а просто удлиняет очередь.
Интеграция через CDP WebSocket и изоляция runtime Nova Act
Подключение исполнителя к управляемому браузеру идёт по CDP WebSocket. Chrome DevTools Protocol остаётся стандартным способом управлять браузером снаружи, и Nova Act работает через ту же механику, что и привычные инструменты автоматизации.
Изоляция runtime Nova Act — одна из рекомендаций команды. Runtime не должен смешиваться с остальной логикой сервиса, иначе любое обновление или отладка задевает всю платформу. Отдельный слой проще обновлять, проще локализовать сбой и проще ограничить, что именно может делать агент внутри сессии.
Мультитенантность через кросс-аккаунтные IAM-роли
Доступ к ресурсам Epsilon строит на кросс-аккаунтных IAM-ролях, а не на общих ключах, разложенных по командам. Роль привязана к тенанту, права выдаются по необходимости, и это стыкуется с pre-flight авторизацией платформы: проверка доступа происходит до запуска работы, а не после. Детали политик в публичном тексте не приведены, но принцип понятен: границы между командами задаются на уровне IAM, а не соглашениями в коде.
Интент-тесты на естественном языке: как выглядит шаг и где живёт условная логика
Главный принцип, который команда вынесла из проекта: шаг теста пишется как намерение. Сценарий из 18 шагов читается как чек-лист для человека, который впервые открыл продукт. Ни селекторов, ни координат, ни ожидания конкретных CSS-классов в нём нет.
Шаги как намерения: примеры формулировок
- Слабая формулировка: «кликнуть по #save-btn, дождаться появления .toast-success, проверить текст в div.notification».
- Сильная формулировка: «сохранить изменения в профиле и убедиться, что интерфейс подтвердил сохранение».
- Слабая формулировка: «ввести значение в input[name=email] и нажать .edit-icon».
- Сильная формулировка: «открыть настройки профиля и проверить, что поле email доступно для редактирования».
- Сильная формулировка: «добавить товар в корзину и убедиться, что итоговая сумма пересчиталась».
Устойчивость к косметике появляется именно здесь. Кнопку перекрасили, перенесли в другой угол, поменяли класс — намерение осталось тем же, и агенту не нужно объяснять новый путь. Формулировка описывает цель, а не дорогу к ней.
Условная логика и переиспользование траекторий
Ветвления в шагах описываются через наблюдаемое состояние интерфейса, а не через проверку DOM. Формулировки выглядят так:
- «если показан баннер о cookie, принять его и продолжить»;
- «если в списке нет записей, проверить пустое состояние и завершить шаг»;
- «если появилось модальное окно с подтверждением, подтвердить действие, иначе продолжить».
Синтаксис API Nova Act в публичном разборе не приводится, поэтому примеры выше — это формулировки шагов и логика ветвления, а не готовый код. Агент получает условие на человеческом языке и сам определяет, какое состояние он видит на странице.
Отдельная история — траектории. Агент записывает фактический путь по интерфейсу, и сохранённую траекторию можно использовать при повторном прогоне. Epsilon сообщает о 100% прохождении при воспроизведении сохранённых траекторий: повторный запуск не начинается с нуля, а опирается на уже пройденный маршрут. Для стабильных сценариев это дешевле и предсказуемее, чем каждый раз заново просить модель найти нужную кнопку.
Цифры: сколько времени экономит подход и что они на самом деле значат
Все замеры ниже взяты из публикации Epsilon. Это данные одной компании на её сценариях, её приложениях и её стеке. Независимого сравнения с другими командами в источнике нет.
| Показатель | Интент-тест на Nova Act | Эквивалентный скрипт Playwright |
|---|---|---|
| Сценарий из 18 шагов, время написания | 5–10 минут | 30–90 минут |
| Объём кода | шаги на естественном языке | 80–150 строк |
| Повторное воспроизведение сохранённой траектории | 100% прохождение по замерам Epsilon | не применимо |
Что эти цифры значат на практике. Разница в 5–10 минут против 30–90 — это про скорость написания, а не про стоимость прогона. Автор теста экономит время на локаторах и инспекции DOM, зато платит за вызовы LLM внутри сессии. В публикации стоимость прогона не раскрыта, и подставлять сюда свои догадки смысла нет: её нужно считать на своём сценарии и своём тарифе.
Экономия на поддержке селекторов в цифрах тоже не измерена, хотя именно она выглядит самой крупной в долгую. Ломающиеся от косметики тесты — известная боль любого Playwright-набора, но конкретных часов, сэкономленных Epsilon на ремонте локаторов, источник не приводит. Про 100% воспроизведения траекторий стоит помнить оговорку: это результат на их сценариях, а не гарантия для произвольного приложения с динамическим интерфейсом.
Ограничения и подводные камни подхода
- Детерминированную регрессию интент-тесты не заменяют. Playwright остаётся основой, и в Epsilon его не выводили из эксплуатации. Если проверке нужна побитовая точность по элементам, скрипт надёжнее.
- Зависимость от управляемых сервисов AWS. Nova Act и AgentCore Browser Tool — внешние компоненты. Их доступность, квоты и региональные ограничения становятся вашими ограничениями в CI.
- Недетерминированность выполнения. Агент на естественном языке может пройти путём, отличным от прошлого раза, особенно на изменившемся интерфейсе. Отладка такого падения отличается от чтения стектрейса Playwright: нужно смотреть траекторию и понимать, как агент прочитал шаг.
- Стоимость LLM-вызовов на прогон. В источнике она не раскрыта, но она существует, и на больших регрессионных наборах её придётся считать отдельно от инфраструктуры браузеров.
- Качество формулировок влияет на стабильность. Размытый шаг даёт размытый результат. Команде нужен человек, который умеет писать шаги как намерения, и ревью этих формулировок.
- Мультитенантная платформа избыточна для маленькой команды. Очередь, runner, кросс-аккаунтные роли и общий API оправданы, когда продуктовых команд много. Для одного продукта с одним набором тестов это лишний слой.
Практические рекомендации команды Epsilon: что забрать в свой проект
Рекомендации команды сводятся к пяти пунктам, и каждый проверяется на своей ситуации.
- Писать шаги как намерения. Формулируйте цель и ожидаемый результат, а не последовательность кликов: так тест переживает редизайн.
- Изолировать runtime Nova Act. Держите агентный слой отдельно от остальной логики сервиса, чтобы обновления и сбои не расходились по всей платформе.
- Переиспользовать сохранённые траектории. Для стабильных сценариев повторный прогон по записанному маршруту даёт предсказуемость, которую не даёт новый поиск пути каждый раз.
- Закладывать мультитенантность через кросс-аккаунтные IAM-роли. Разграничивайте доступ ролями с узкими правами, а не общими ключами, и проверяйте авторизацию до запуска работы.
- Не отказываться от Playwright. Оставляйте детерминированные проверки на скриптах и добавляйте интент-тесты туда, где интерфейс часто меняется.
Кому подход подходит: организациям с несколькими продуктовыми командами и общей платформой, продуктам с большим числом UI-сценариев и частой косметикой интерфейса, командам, которые готовы отдать браузерную инфраструктуру внешнему провайдеру. Кому нет: небольшой команде с одним продуктом, проектам с жёсткими требованиями к детерминизму и полному контролю над окружением, а также тем, кто по регуляторным причинам не может пускать тестовые прогоны через внешние сервисы.
Если задача сейчас не в написании новых тестов, а в разборе накопленной базы, полезнее окажется другой кейс: аудит 2600 автотестов силами ИИ-агента. А тем, кто хочет сначала разобраться с методологией оценки агентов, пригодится разбор бенчмарка Deep Agents.
Вывод без восторгов: Epsilon решила конкретную организационную задачу. У них 50 инженеров на платформе и много продуктовых команд, поэтому управляемый сервис с общей очередью, изолированным runtime и IAM-ролями окупается. Начните с одного сценария, который чаще всего ломается от косметики, прогоните его через Nova Act рядом с текущим Playwright-тестом и сравните время написания, стабильность и стоимость прогона на своих данных. Дальше решение будет арифметическим, а не вкусовым.