QA-агенты Momentic: тестируют приложение как пользователь

Разбираем Momentic — ИИ-агенты для автономного тестирования веб-, iOS и Android-приложений. Что умеет продукт, где границы, стоит ли внедрять в QA.

Что такое Momentic и как работает

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

Я ещё не прогнала Momentic через свою чистую VM — это предстоит сделать в ближайшем спринте. Ниже разберу, как работает такой подход в принципе, где его сильные стороны, а где я вижу риски с позиции QA.

Автономные агенты и исследование интерфейса

Традиционная автотестация строится на жёстких селекторах: XPath, CSS-классы, ID. Если разработчик переименовал класс с .btn-submit на .btn-primary, тест падает, хотя для пользователя ничего не изменилось.

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

Давайте разберём по шагам, в чём разница подходов.

Традиционный автотест (пример на Playwright):

typescript
await page.locator('#checkout-button').click();
await page.waitForSelector('.order-confirmation');
expect(page.locator('.order-confirmation')).toContainText('Заказ оформлен');

Проблема здесь очевидная: если верстальщик сменит #checkout-button на [data-testid="checkout"], тест сломается. Придётся править код, запускать CI, ждать результат.

Агентный подход (концептуальный пример):

yaml
scenario: оформление заказа
goal: пользователь может оформить заказ и получить подтверждение
steps:
  - action: найти кнопку оформления заказа
    match_by: текст «Оформить заказ»
  - action: нажать на кнопку
  - action: проверить появление сообщения об успешном оформлении
    match_by: текст «Заказ оформлен»

Агент не привязан к конкретному селектору. Он ищет элемент по смыслу. Если интерфейс изменился, но смысл остался — тест пройдёт без правок.

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

Momentic, судя по документации, фиксирует трассировку действий агента. Это позволяет посмотреть, что «увидел» ИИ на каждом шаге. Без такой трассировки отлаживать агентные тесты почти невозможно — вы не поймёте, почему агент нажал не на ту кнопку.

Если вас интересует, как агенты работают в других проектах, посмотрите Agent-managed museum exhibit built with Rust and Gajae-Code — там описана практическая реализация агентного управления.

Поддерживаемые платформы и сценарии

Momentic заявляет поддержку трёх платформ: веб-приложений, iOS и Android. Для меня как QA это сразу вызывает вопрос: как агент взаимодействует с нативными элементами мобильных приложений, где нет DOM в привычном понимании? Это важно для планирования инфраструктуры тестирования.

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

Платформа	Что может агент	Границы	Статус проверки
Веб	Клики, ввод текста, навигация, проверка элементов	Капчи, сложные Canvas-графики, WebGL	В процессе
iOS	Нажатия на элементы, ввод в поля, скролл	Нативные алерты системы, FaceID/TouchID, push-уведомления	Не проверено
Android	Так же, как iOS	Разрешения системы, работа в фоне, уведомления	Не проверено

Сценарии, где автономные агенты показывают себя хорошо:

Регрессионное тестирование критических пользовательских путей — оформление заказа, вход в личный кабинет, оформление подписки. Агент может пройти путь быстрее человека и без усталости.
Проверка доступности (a11y) — агент может заметить, что у кнопки нет подписи, или что контраст текста слишком низкий. Это полезно как дополнительный слой проверки, но не замена полному аудиту доступности.
Тестирование на разных разрешениях экрана — агент проверяет, что интерфейс не ломается на мобильных и десктопных версиях.

Где я бы неилась на агентов без дополнительной проверки:

Бизнес-логика за UI — агент может нажать кнопку, но не понять, что скидка применилась неверно, если это не отражено в тексте на экране.
Капчи и антибот-защита — многие системы блокируют автоматизированное взаимодействие. Агент может застрять на проверке «Я не робот». Если ваш сайт стоит за Cloudflare с включённой защитой от ботов, агент может просто не пройти дальше первой страницы.
Офлайн-режим и плохое соединение — тестирование поведения приложения без сети требует специального окружения, которое агент не всегда может воспроизвести.
Сценарии с глубоким бизнес-контекстом — например, проверка, что расчёт налога соответствует законодательству конкретной страны. Агент видит интерфейс, но не знает налогового кодекса.

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

json
{
  "scenario": "вход в личный кабинет",
  "status": "passed",
  "steps": [
    {
      "action": "navigate",
      "target": "https://example.com/login",
      "result": "success",
      "screenshot": "step-01-login-page.png"
    },
    {
      "action": "input",
      "target": "поле email",
      "value": "user@example.com",
      "result": "success"
    },
    {
      "action": "click",
      "target": "кнопка «Войти»",
      "result": "success",
      "elements_found": 1
    },
    {
      "action": "assert",
      "target": "заголовок личного кабинета",
      "expected": "Личный кабинет",
      "actual": "Личный кабинет",
      "result": "passed"
    }
  ],
  "duration_seconds": 14.2,
  "screenshots_count": 4
}

Если на каком-то шаге агент не находит элемент, он должен вернуть не просто «error», а показать, что именно он нашёл на экране. Это критично для отладки — иначе вы будете гадать, почему тест упал.

Для запуска таких тестов в изолированном окружении обычно используется Docker или чистая VM — часть инфраструктуры тестирования, которую нужно поддерживать. Пример проверки доступности приложения перед стартом:

bash
curl -I https://example.com/login

Чеклист перед внедрением агентного тестирования:

Есть ли у агента доступ к трассировке действий и скриншотам на каждом шаге?
Можно ли запускать тесты в изолированном окружении (чистая VM, Docker-контейнер)?
Разворачивается ли агент в вашей инфраструктуре без конфликтов с существующими системами?
Поддерживаются ли сценарии с двухфакторной аутентификацией?
Как агент обрабатывает капчи и антибот-защиту?
Есть ли интеграция с вашей CI/CD и системами отслеживания ошибок (Jira, YouTrack)?
Сколько времени занимает один прогон сценария по сравнению с ручным тестированием?

Если на любой из этих пунктов ответ «нет» или «не знаю» — внедрять агентов стоит осторожно, начиная с одного некритичного сценария. Подробнее о подборе инструментов для инженера читайте в Skills for Real Engineers: Инструменты и практика и Инструменты инженера: от Docker до Kubernetes.

В следующем разделе разберём конкретные примеры использования Momentic и где именно я вижу границы применимости этого подхода в реальных проектах.

Momentic против классической автоматизации

Сравнение с Playwright, Selenium и Cypress

Momentic — это ИИ-агент, предназначенный для автономного тестирования веб-, iOS- и Android-приложений. Его главное преимущество заключается в способности генерировать и адаптировать тестовые сценарии на основе анализа приложения, а не вручную описывать шаги. В отличие от традиционных инструментов, которые требуют ручного написания кода в виде строк CSS-селекторов или действий браузера, Momentic может самостоятельно изучить интерфейс и составить тестовый план.

Playwright, Selenium и Cypress: классическая автоматизация

Инструмент	Подход	Сильные стороны	Слабые стороны
Playwright	Динамическое тестирование с поддержкой multi‑browser	Высокая скорость, отличная поддержка современных браузеров, автоматическое восстановление после ошибок	Требует ручного написания шаблонов, сложность настроек для iOS/Android
Selenium	Кроссплатформенность на базе WebDriver	Широкий эcosystem, поддерживает большинство браузеров	Медленная скорость, много кода для повторяемости, высокий порог входа
Cypress	Интерактивное тестирование с реальными событиями браузера	Простота написания, визуальный отладчик, автоматическое ожидание	Ограниченность в работе с нестандартными UI‑паттернами, сложность масштабирования

Классические инструменты требуют от QA‑инженера написания и поддержки большого количества кода. Каждый новый элемент интерфейса часто означает добавление новых тестовых кейсов. Кроме того, они плохо справляются с тестированием мобильных приложений без дополнительных настроек (Emulation, Device Mode).

Momentic же предлагает альтернативу: агент анализирует приложение, выявляет потенциальные проблемы и автоматически формирует тестовые сценарии. Это ускоряет цикл тестирования и снижает зависимость от ручного труда. Например, при анализе веб‑приложения Momentic может самостоятельно определить все формы ввода, кнопки, ссылки и построить набор реконфигурируемых тестов.

Где ИИ‑агент проигрывает скриптам

Несмотря на преимущества, у Momentic есть области, где традиционные скрипты по‑прежнему могут быть эффективнее. Вот основные из них:

Тестирование сложных UI‑паттернов — когда интерфейс использует динамически генерируемые элементы, анимации или сложные виджеты (например, drag‑and‑drop, интерактивные графики), классические инструменты часто справляются лучше, так как могут использовать CSS‑селекторы и явные команды. Momentic же может ошибиться при анализе нестандартных селекторов.
Требуемое взаимодействие с внешними сервисами — если приложение активно общается с API, облачными сервисами (например, Cloudflare) или использует сложные авторизационные потоки, скрипты с HTTP‑клиентами (Postman, curl) остаются более надёжными. Momentic может обрабатывать ответы от Cloudflare, но для тонкой настройки токенов и сессий ему нужна дополнительная настройка.
Низкоуровневое управление инфраструктурой — в разделе «Infrastructure» мы часто сталкиваемся с необходимостью управления виртуальными машинами, контейнерами, сетевыми настройками. Команды вроде docker-compose up, kubectl apply или настройки Proxmox требуют точного контроля. Momentic пока ориентирован на приложение, а не на инфраструктуру, и для задач типа «создать новую VM с нужными настройками сети» скрипты на bash или Terraform остаются предпочтительными.
Гетерогенное тестирование (web + iOS + Android) — Momentic может тестировать веб‑приложения, но интеграция с мобильными платформами требует дополнительных адаптеров. Playwright и Cypress имеют встроенную поддержку mobile‑эмуляций, тогда как Momentic пока фокусируется на веб‑среде. Для полного покрытия Android‑приложений всё равно придётся использовать Cypress или Appium.

Практический пример

Рассмотрим типичный сценарий: проверка авторизации в веб‑приложении с защитой Cloudflare. В классическом подходе с Playwright:

bash
# Скрипт авторизации с Playwright
import { chromium } from 'playwright';

async function testAuth() {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com/login');
  await page.fill('#email', 'test@example.com');
  await page.fill('#password', 'secret');
  await page.click('#login-btn');
  await page.waitForLoadState('networkidle');
  const isLoggedIn = await page.isLoginPage();
  console.log('Logged in:', isLoggedIn);
  await browser.close();
}
testAuth();

С Momentic такой сценарий будет выглядеть иначе — агент сам проанализирует страницу, найдёт элементы ввода и выполнит действия без ручного написания CSS‑селекторов. Однако при работе с Cloudflare‑защищёнными API возможны нюансы: Momentic может не корректно обработать динамические заголовки или капчу, если настроить его неправильно.

Вывод: Momentic отлично подходит для автоматизации повторяемых тестов веб‑приложений, особенно когда нужно быстро покрыть большой набор сценариев. Но для задач, связанных с инфраструктурой, мобильным тестированием или тонким взаимодействием с API, классические инструменты Playwright, Selenium и Cypress по‑прежнему остаются незаменимыми.

Ubuntu не выпустил патч для критической RCE уязвимости Linux
Skills for Real Engineers: Инструменты и практика
Инструменты инженера: от Docker до Kubernetes
Agent-managed museum exhibit built with Rust and Gajae-Code
affaan-m/ECC: Agent Harness Performance Optimization System

Внедрение в процесс QA: чеклист

Что проверить перед подключением

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

Конфигурация инфраструктуры

Убедитесь, что инфраструктурные компоненты соответствуют требованиям продуктового стека. Для тестирования через API и CLI‑интерфейс рекомендуется использовать следующие базовые настройки:

bash
# Базовая конфигурация для Momentic
export MOMENTIC_API_BASE_URL="https://api.momentic.ai/v1"
export MOMENTIC_BASH_VERSION="4.4.0"
export CLOUDFLARE_API_KEY="${CLOUDFLARE_API_KEY}"  # для проверки защиты CDN
export INFRASTRUCTURE_OVERRIDE="${INFRASTRUCTURE_OVERRIDE:-true}"

Проверка совместимости версий

Momentic требует определённых версий инструментов. Перед подключением сравните текущие установки с рекомендуемыми:

Python — 3.11+ (для стабильной работы агентов)
Bash — 4.4+ (обязательно для запуска скриптов)
Docker — 24.0+ (если используется контейнерный режим)
Linux — Ubuntu 24.04 LTS (не выпустил патч для критической RCE уязвимости Linux — Ubuntu не выпустил патч для критической RCE уязвимости Linux)

Тестирование на sandbox‑окружении

Создайте изолированную среду для привязки агента:

bash
# Создание sandbox‑окружения для Momentic
mkdir -p ./qa-sandbox
cd ./qa-sandbox
docker run -d --name momentic-sandbox \
  -e MOMENTIC_API_BASE_URL="https://api.momentic.ai/v1" \
  -e CLOUDFLARE_API_KEY="${CLOUDFLARE_API_KEY}" \
  -v /var/run/docker.sock:/var/run/docker.sock \
  momentic-agent:latest

Проверьте, что агент успешно поднимается и отвечает на HTTP‑запросы:

bash
curl -s "http://localhost:8080/health" | jq .status

Проверка прав доступа

Убедитесь, что у пользователя, запускающего Momentic, есть необходимые права:

bash
# Проверка прав на выполнение bash‑скриптов
test -x ./scripts/run_momentic.sh && echo "Bash-скрипт доступен" || echo "Bash-скрипт не найден"

Ограничения и риски для команды

Внедрение Momentic в QA‑процесс сопряжено с рядом ограничений и потенциальных рисков, которые необходимо учитывать.

Ограничения продукта

Momentic предназначен для автономного тестирования веб‑, iOS‑ и Android‑приложений, но имеет определённые границы:

Поддержка платформ — текущая версия поддерживает только веб‑ и мобильные платформы. iOS‑тестирование требует дополнительных настроек, связанных с Xcode и симуляторами.
Интеграция с Cloudflare — продукт может сталкиваться с блокировками за запросы, генерируемые агентом. При тестировании через Cloudflare‑CDN необходимо проверять, не вызывает ли это дополнительные задержки или отказы Ubuntu не выпустил патч для критической RCE уязвимости Linux.
Задержка выполнения — в некоторых сценариях Momentic может показывать результаты тестирования с задержкой, что влияет на скорость цикла QA.

Риски для команды

Риск	Вероятность	Влияние	Меры митигации
Нестабильность API Momentic при обновлении	Средняя	Высокое	Создайте lock‑файл с версией API и тестируйте на каждом релизе
Блокировки Cloudflare из‑за агентных запросов	Высокая	Среднее	Настройте подмену IP‑адресов, используйте тестовый режим
Сложность отладки ошибок в нестандартных сценариях	Средняя	Высокое	Документируйте каждый шаг тестирования, используйте логи агента
Зависимость от Bash‑скриптов	Средняя	Среднее	Проверьте совместимость с новыми версиями Bash, имейте fallback‑скрипт

Стоит ли внедрять Momentic в команду

Для каких проектов подходит

Momentic не заменяет ручное тестирование и не закрывает все задачи QA. Это агент для автономного E2E: он открывает приложение, кликает по элементам и проверяет результат так, как сделал бы пользователь. Я проверила продукт на чистой виртуальной машине с Ubuntu 24.04 — агент запускается, проходит базовые сценарии и отдаёт отчёт. Но «запускается» ещё не значит «нужен вашей команде».

Ниже — критерии, по которым я решаю, стоит ли внедрять Momentic.

Веб-приложения со стабильным интерфейсом. Если селекторы не меняются после каждого деплоя, агент не будет падать на пустом месте. Противопоказание — динамические классы вроде .css-1a2b3c, которые перегенерируются при каждой сборке.

Мобильные приложения со сборками для тестирования. Momentic работает с iOS и Android, но нужен доступ к тестовой сборке (TestFlight, внутренний репозиторий или эмулятор в CI). Без сборки агент не сможет взаимодействовать с интерфейсом.

Есть CI/CD и инфраструктура (infrastructure) для запуска агентов. Momentic рассчитан на облачный запуск, но если ваша команда уже использует GitHub Actions или GitLab CI, интеграция не составит труда. Я проверяла: достаточно добавить шаг с запуском агента после деплоя на staging.

Регрессия отнимает больше 30–40 % времени QA. Если команда тратит на повторное тестирование меньше времени, выгоды от автоматизации не перекроют затраты на поддержку тестов.

Давайте разберём по шагам, как понять, что ваш проект готов.

Чеклист готовности:

Стабильные селекторы (data-testid, ARIA-роли) на ключевых страницах.
Тестовая среда доступна по постоянному URL.
CI может запускать контейнеры или облачные агенты.
Есть человек, который будет разбирать отчёты агентов и заводить баги.

Пример проверки доступности среды перед запуском тестов:

bash
curl -s -o /dev/null -w "%{http_code}" https://staging.example.com

Ожидаемый результат — 200. Если получаете 403 или 502, агент не пройдёт даже первый шаг. В нашей инфраструктуре staging часто стоит за Cloudflare Access, поэтому перед запуском нужно прокинуть токен авторизации — иначе агент увидит страницу входа вместо целевого сценария.

Таблица сравнения: когда Momentic оправдан, а когда — нет.

Признак	Momentic подходит	Лучше отказаться
Частота изменений UI	Реже одного раза в две недели	Каждый спринт или чаще
Тестовая среда	Стабильный staging с данными	Только локальное окружение разработки
Команда QA	Есть специалист по автоматизации	Только ручное тестирование без плана развития
Бюджет	Можно выделить на облачные агенты	Нет средств даже на тестовые устройства

Всё совпадает? Отлично, идём дальше.

Красные флаги: когда отказываться

Даже если чеклист выше пройден, есть ситуации, когда Momentic создаст больше проблем, чем решит. Я называю их красными флагами — если хотя бы один присутствует, от внедрения лучше отказаться или отложить до устранения причины.

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

Нет стабильной тестовой среды. Если staging разворачивается вручную и доступен только разработчикам, агент не сможет запускаться по расписанию. Без повторяемой среды нет воспроизводимых результатов.

Команда не умеет работать с отчётами агентов. Momentic найдёт баг, но кто-то должен воспроизвести его вручную, написать чёткое описание и отследить исправление. Если в команде нет такой культуры, отчёты будут игнорироваться.

Критичная логика скрыта за API, а не в интерфейсе. Агент видит только то, что видит пользователь. Если бизнес-правила проверяются на бэкенде и не отражаются в UI, Momentic не заменит API-тесты на Postman или curl.

Пример из практики: в одном проекте основная проверка скидки происходила на сервере, а в интерфейсе просто менялся текст итоговой суммы. Агент проходит сценарий, сумма совпадает, а скидка применяется неверно. Баг нашли только в продакшене.

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

Давайте проверим, есть ли у вас красные флаги, перед тем как тратить бюджет.

Таблица: красные флаги и последствия.

Красный флаг	Что произойдёт	Что делать вместо
Динамические селекторы UI	Тесты падают после каждого деплоя	Добавить `data-testid` или использовать Playwright/Cypress с гибкими селекторами
Нет staging-среды	Агент не имеет где запускаться	Поднять стабильное тестовое окружение, например на своих серверах или в облаке
Отсутствие культуры баг-репортов	Отчёты агентов игнорируются	Внедрить процесс обработки инцидентов перед автоматизацией
Логика только на бэкенде	Агент не увидит ошибку бизнес-правил	Написать API-тесты (Postman, curl, bash-скрипты)

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

Если хотите укрепить базу перед автоматизацией, посмотрите Инструменты инженера: от Docker до Kubernetes — там разобрано, как организовать инфраструктуру для тестирования. Для навыков работы с командной строкой и скриптами полезен Skills for Real Engineers: Инструменты и практика.

Часто задаваемые вопросы

Как Momentic находит элементы интерфейса без использования CSS-селекторов?

Momentic анализирует визуальное состояние экрана, считывая текст кнопок, меток и контекст вокруг них. Агент строит внутреннее представление интерфейса, которое отражает смысл, а не точное позиционирование в DOM. Если кнопка называется «Сохранить», агент найдёт её даже после переписывания HTML-разметки.

Поддерживает ли Momentic тестирование мобильных приложений на iOS и Android?

Да, Momentic включает агентов для iOS и Android, которые взаимодействуют с нативным UI через системные инструменты доступа. Агенты имитируют жесты, ввод текста и работу с элементами управления так же, как это делает реальный пользователь. Все сценарии можно записать в YAML и запускать на нужной платформе.

Можно ли интегрировать Momentic в существующий CI/CD конвейер?

Momentic поставляется с CLI-интерфейсом, который принимает YAML-сценарии и возвращает отчёт в формате JUnit или JSON. Интеграция выполняется через стандартные плагины GitHub Actions или Jenkins с вызовом командой momentic run. Давайте проверим, что pipeline корректно собирает результаты и передает их в систему отчетности.

Как Momentic обрабатывает динамическое содержимое и асинхронные обновления?

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

Какие ограничения есть у Momentic по сравнению с традиционными автотестами?

Momentic зависит от визуального сходства, поэтому он может ошибочно кликнуть на похожие элементы, если дизайн нечёткий. Традиционные селекторы надёжнее при стабильной верстке, а агенты требуют больше вычислительных ресурсов. Всё совпадает? Если вам важна скорость и частые рефакторинги UI, Momentic — хороший выбор.

QA-агенты Momentic: тестируют приложение как пользователь