Approxima: QA-агент на LLM, который не ищет кнопки по CSS-классам

Помните этот момент, когда ваш Playwright-тест падает из-за того, что дизайнер переименовал класс кнопки с .btn-primary на .btn-cta? А логика осталась той же — кнопка всё так же добавляет товар в корзину. Вы идёте фиксить селектор, тест зелёный, но чувство, что вы тратите жизнь впустую, остаётся. Approxima предлагает другой путь: пусть LLM сама разбирается, куда нажать и что проверить.

Зачем плодить сущности?

Классические UI-тесты (Selenium, Playwright, Cypress) хрупки по определению. Они привязаны к DOM-структуре. Если вёрстка меняется — тест красный, даже если функциональность на месте. Это порождает «ложные срабатывания», которые раздражают и заставляют тратить время на поддержку тестов, а не на проверку нового функционала.

Решение — дать агенту «глаза» (скриншоты, HTML) и «мозг» (LLM), чтобы он сам понимал, что происходит на экране. Approxima делает ровно это: он делает шаги и на каждом этапе спрашивает LLM, всё ли ок, и куда идти дальше. Никаких жёстких селекторов — только описание намерения.

Что под капотом?

Архитектура напоминает того самого локального AI-агента для автотестирования чат-ботов, который мы собирали на Agno, но здесь всё ориентировано именно на веб-интерфейсы.

• Оркестратор (Python) — управляет браузером через Playwright и делает снимки.
• LLM-прокси — шлёт сценарий + скриншот + HTML в модель и получает инструкцию: «нажать на кнопку с текстом „Оформить“».
• Пайплайн проверок — после выполнения шагов запускает ассерты, описанные на естественном языке.

В итоге вы пишете тест примерно так:

scenarios:
  - name: "Покупка товара"
    steps:
      - action: "open"
        url: "https://shop.example.com"
      - action: "click"
        target: "кнопка 'Добавить в корзину' на карточке первого товара"
      - action: "go_to_cart"
      - check: "в корзине отображается 1 товар с ценой < 5000р"

И агент сам найдёт ту самую кнопку, даже если она переехала на три пикселя влево и поменяла класс.

Как это выглядит в деле?

Допустим, вы тестируете форму регистрации. Вместо того чтобы писать await page.fill('#email', 'test@test.com'), вы просто говорите: «заполни поле Email значением test@test.com и нажми Зарегистрироваться». Approxima смотрит на скриншот, находит поле по подписи (а не по id) и взаимодействует.

А ещё он умеет проверять не только текст, но и логику. Например, проверить, что после смены тарифного плана цена пересчиталась. Для этого нужно описать ожидание в свободной форме: «сумма в корзине равна 1990 рублей». Модель сравнивает скриншот с ожиданием и возвращает Pass/Fail.

Сравнение с альтернативами

Очевидно, что Approxima выигрывает в гибкости и цене, но проигрывает в скорости (LLM отвечает 2-5 секунд вместо миллисекунд). Так что это не замена unit-тестам, а инструмент для E2E и мониторинга production.

Установка: от репозитория до первого прогона

Всё, что нужно — Docker и желание сэкономить нервы. Клонируйте репозиторий, откройте терминал и начните с docker compose up:

git clone https://github.com/approxima/qa-agent
cd qa-agent
cp .env.example .env
# отредактируйте .env: выберите LLM (например, OPENAI_API_KEY) или укажите endpoint для Ollama
docker compose up -d

После запуска веб-интерфейс будет доступен на http://localhost:8080. Там можно сразу написать первый сценарий и запустить его. Approxima откроет headless-браузер, пройдёт сценарий и покажет вам логи с пояснениями, почему каждый шаг прошёл или упал.

1 Выбор LLM

В .env есть параметр LLM_BACKEND. По умолчанию стоит openai, но можно переключить на anthropic (Claude), google (Gemini), ollama (локальная модель), vllm и даже mocked для отладки. На 16 июня 2026 года отлично работает связка Claude 4 Sonnet + GPT-4o-mini (первый для понимания сложных сценариев, второй для быстрых ассертов).

2 Настройка пользовательского сценария

Сценарии описываются в YAML. Вот пример для проверки входа в личный кабинет:

name: "Вход в ЛК"
steps:
  - action: "open"
    url: "https://my.app/login"
  - action: "fill"
    target: "поле ввода email"
    value: "user@example.com"
  - action: "fill"
    target: "поле ввода пароля"
    value: "secret123"
  - action: "click"
    target: "кнопка 'Войти'"
  - check: "на странице отображается приветствие 'Здравствуйте, Иван'"

Обратите внимание: ни одного селектора, только описание смысла. Approxima сам найдёт поле email по метке или placeholder, а кнопку — по тексту.

Подводные камни (и как с ними жить)

Ещё один нюанс — стоимость токенов. Если гонять Approxima каждые 5 минут на production, можно потратить заметную сумму (при использовании GPT-4o). Решение: комбинировать быстрые модели (Gemini 2.0 Flash) для простых проверок и Claude для сложных. Либо поднять локально Llama 3 70B через Ollama — будет дольше, но бесплатно.

Кому это реально нужно

• QA-инженерам, уставшим чинить селекторы. Особенно если у вас микросервисная архитектура с частыми переездами UI (спасибо, дизайн-система).
• DevOps/SRE-инженерам, которые хотят мониторить критические пользовательские пути в production (логин, оплата, регистрация) без тонны кода.
• Продуктовым командам, которые хотят быстро проверить гипотезу или протестировать новую фичу, не внося изменения в репозиторий тестов.

Как и в случае с Totogi BSS Magic (где заменили 20 инженеров мультиагентным фреймворком), Approxima берёт на себя рутинную работу. Но не ждите, что он заменит весь QA — пока это скорее «умный помощник», чем полноценный заменитель.

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

Подписаться на канал