AI-агенты сами тестируют приложения: что уже работает

Что происходит

За 2024–2025 годы вокруг тестирования выросла отдельная категория инструментов, где вместо жёстко прописанных сценариев работает LLM-агент¹: ему дают доступ к приложению и задачу «проверь оформление заказа», а он сам находит нужные кнопки, кликает, вводит данные и решает, прошёл сценарий или нет. Ключевые игроки — Browserbase с открытым фреймворком Stagehand, стартап QA.tech, а также Playwright, в который Microsoft добавила экспериментальную интеграцию с моделями для генерации и починки тестов. Отдельно стоят агенты общего назначения вроде OpenAI Operator и Anthropic Computer Use, которые тоже умеют управлять браузером, хотя тестирование — не единственная их задача.

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

Чем это отличается от привычной автоматизации

Классический автотест на Selenium или Playwright ищет элемент по селектору: #submit-button или XPath. Поменяли вёрстку — тест падает, даже если для пользователя ничего не изменилось. Такие падения (flaky-тесты и хрупкие локаторы) съедают огромную долю времени QA-инженеров: тесты не находят баг, а сами требуют постоянной починки.

Агентный подход работает иначе. Агент получает не селектор, а намерение: «нажми кнопку оформления заказа». Он смотрит на страницу — скриншот, дерево доступности или DOM — и сам решает, куда кликнуть. Если кнопку переместили или переименовали, агент всё равно её найдёт, пока она визуально осталась кнопкой оформления. Это и есть главный аргумент: устойчивость к косметическим изменениям интерфейса.

Агент не проверяет, что кнопка называется «Оформить». Он проверяет, что пользователь может оформить заказ. Это разные вещи, и вторая ближе к тому, ради чего вообще пишут тесты.

Где заканчивается магия

Три проблемы, о которых редко пишут в анонсах:

• Недетерминированность. Один и тот же прогон может пройти по-разному, потому что модель — вероятностная. Для CI, где нужен воспроизводимый результат, это плохо: непонятно, баг в приложении или агент «передумал».
• Цена и скорость. Каждый шаг агента — это вызов модели, часто с картинкой. Прогон, который на Playwright занимает секунды и стоит доли копейки, у визуального агента может тянуться минуты и стоить заметно дороже за счёт токенов.
• Ложная уверенность. Агент может отрапортовать «тест пройден», потому что нашёл хоть какую-то кнопку и нажал не туда. Проверять его вердикты приходится человеку — по крайней мере на этапе внедрения.

Сравнение подходов

Тарифы у всех перечисленных продуктов меняются часто и зависят от объёма прогонов и модели под капотом — актуальные цены смотрите на официальных страницах, а не в этом тексте. Публичных бенчмарков, которые честно сравнивали бы эти инструменты между собой на одинаковых сценариях, на сегодня практически нет, поэтому цифр «X быстрее Y на Z процентов» здесь не будет.

Кому это пригодится, а кому нет

Стоит попробовать, если

• У вас часто меняется вёрстка (редизайны, A/B-тесты), и половина времени QA уходит на починку локаторов.
• Нужно быстро набросать smoke-тесты² для нового продукта, где ещё нет стабильных селекторов.
• Есть сценарии, которые тяжело описать кодом: «пройди онбординг как новый пользователь и проверь, что нигде не застрял».
• Вы готовы держать человека, который вычитывает вердикты агента хотя бы первые месяцы.

Пока не стоит, если

• У вас строгий CI с требованием воспроизводимости: недетерминированный агент будет давать шум в отчётах.
• Тесты гоняются тысячами раз в день — стоимость вызовов модели превратится в отдельную статью бюджета.
• Критичные финансовые или платёжные сценарии, где цена ложного «пройдено» слишком высока.
• У вас уже стабильный набор автотестов, который редко ломается — менять его на агента нет причин.

Как встроить без боли

Разумный сценарий на 2025 год — не «заменить QA агентами», а добавить их точечно:

1. Возьмите 5–10 самых хрупких сценариев, которые чаще всего падают из-за косметики, и переведите их на агентный инструмент.
2. Оставьте критичные и часто прогоняемые тесты на классическом Playwright — там важны скорость и воспроизводимость.
3. Настройте, чтобы вердикт агента дублировался скриншотом и логом действий: без этого разбирать падения невозможно.
4. Месяц сравнивайте: сколько ложных падений убрали агенты и сколько новых ложных «прошло» они внесли. Решение принимайте по этим двум числам, а не по маркетингу вендора.

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

¹ LLM-агент — большая языковая модель, которой дали инструменты (браузер, клавиатуру, доступ к API) и цель, после чего она сама выбирает последовательность действий для её достижения, а не следует заранее прописанному сценарию.

² Smoke-тесты — базовая проверка, что ключевые функции приложения вообще запускаются и работают: не глубокий тест, а быстрая проверка «не сломалось ли всё сразу».