Modern QA2026Декодер модных слов: Что люди имеют в виду на самом деле
Join

Course01 Agent Skills for Browser Automation

Cutting-edge · Chapter 01

Декодер модных слов: Что люди имеют в виду на самом деле

Updated Jul 2026

«Agentic Testing»

Что говорят: «Нам нужны возможности agentic testing.»

Что имеют в виду: Тесты, которые могут принимать решения, а не просто следовать скриптам. Тестовая система должна уметь:

  • Исследовать приложение (а не только проверять известные потоки)
  • Восстанавливаться из неожиданных состояний
  • Генерировать новые тестовые случаи на основе наблюдений
  • Сообщать результаты на естественном языке

Что вы должны сказать: «Agentic testing означает, что тестовая система имеет цикл рассуждений — она наблюдает состояние приложения, решает, что делать дальше, действует и оценивает результат. В нашем фреймворке Claude Code является агентом. Он читает определения тестов, решает, как взаимодействовать с приложением через навык vibe-check, и рассуждает о том, соответствуют ли результаты ожиданиям.»

«Self-Healing Tests»

Что говорят: «Ваши тесты самовосстанавливаются?»

Что имеют в виду: Когда UI меняется, тесты автоматически адаптируются вместо того, чтобы ломаться?

Уровни самовосстановления:

Уровень Механизм Пример
Базовый Повтор с резервными селекторами ID → класс → текст → CSS-путь
Средний Визуальное сопоставление Поиск элемента по внешнему виду, а не по коду
Продвинутый Рассуждения ИИ Агент понимает структуру страницы и находит альтернативу

Что вы должны сказать: «Да, через три уровня. Первый: когда селектор не срабатывает, агент обнаруживает существующие элементы через find-all и сопоставляет по текстовому содержимому — это решает 80% случаев дёшево. Второй: агент анализирует скриншот и текст страницы для более глубокого понимания. Третий: переключается на деревья доступности MCP для семантического анализа. Ключевое отличие от традиционных инструментов самовосстановления — наш агент рассуждает о контексте, а не просто применяет правила.»

«ReAct Pattern»

Что говорят: «Ваш агент использует паттерн ReAct?»

Что имеют в виду: Паттерн Reason + Act, где агент:

  1. Наблюдает текущее состояние
  2. Думает о том, что делать (видимые рассуждения)
  3. Действует на основе решения
  4. Наблюдает результат
  5. Повторяет

В нашем фреймворке:

Observe: vibe-check text → reads page content
Think:   Agent reasons: "I see a login form. I need to enter credentials."
Act:     vibe-check type "#email" "user@test.com"
Observe: vibe-check text ".error" → checks for validation errors
Think:   Agent reasons: "No errors. Submit the form."
Act:     vibe-check click "#submit"

Что вы должны сказать: «Claude Code естественно следует паттерну ReAct. Каждая команда vibe-check — это действие, а между командами агент рассуждает о выводе. Навык предоставляет словарь (22 браузерные команды), а агент предоставляет интеллект (решает, какую команду запустить дальше на основе наблюдений).»

«Shift-Left Testing»

Что говорят: «Как ИИ помогает нам сдвинуться влево?»

Что имеют в виду: Перенос тестирования на более ранние этапы процесса разработки — поиск багов до того, как они дойдут до QA.

Что вы должны сказать: «ИИ-агенты могут генерировать браузерные тесты из требований или описаний PR, запуская их на feature-ветках до того, как код вообще будет проверен. Разработчик пушит код, CI-конвейер поднимает приложение, и агент запускает исследовательские тесты на новом UI — всё до того, как человек-QA-инженер к нему прикоснётся. Это ловит ошибки вёрстки, сломанные потоки и регрессионные проблемы на этапе PR, а не на этапе QA.»

«Test Observability»

Что говорят: «Какова ваша стратегия наблюдаемости тестов?»

Что имеют в виду: Можете ли вы видеть, что происходит внутри тестов? Можете ли вы эффективно отлаживать сбои?

Что вы должны сказать: «Мы сохраняем пять артефактов на тест: лог команд (что делал агент), скриншоты (как выглядела страница), текст страницы (каким было содержимое), данные о времени (сколько занял каждый шаг) и историю URL (куда мы переходили). При сбое мы добавляем рассуждения агента — почему он решил, что тест не прошёл. Это даёт и людям-проверяющим, и ИИ-агентам всё необходимое для диагностики проблем.»

«Test Maintenance Debt»

Что говорят: «Как вы управляете долгом по поддержке тестов?»

Что имеют в виду: Со временем наборы тестов накапливают сломанные, медленные и нестабильные тесты, поддержка которых стоит дороже, чем они приносят ценности.

Что вы должны сказать: «Агентно-управляемые тесты радикально сокращают долг по поддержке, потому что агент адаптируется к изменениям UI. Когда ID кнопки меняется с btn-submit на submit-button, традиционные тесты ломаются — кто-то должен найти тест, обновить селектор, проверить работоспособность и смержить исправление. Наш агент находит кнопку по текстовому содержимому и продолжает работу. Мы всё же отслеживаем события восстановления и периодически обновляем подсказки по селекторам, но это задача на проверку, а не аварийное исправление.»

«Page Object Model»

Что говорят: «Вы используете паттерн Page Object?»

Что имеют в виду: Паттерн проектирования, где каждая страница/компонент имеет соответствующий класс, инкапсулирующий селекторы элементов и взаимодействия.

В агентно-управляемом тестировании: Page Object Model менее актуален, потому что агенту не нужна классовая абстракция — он взаимодействует со страницей напрямую через CLI-команды. Однако концепция отображается так:

Что вы должны сказать: «Мы используем облегчённую версию этой концепции. Вместо классов page object у нас есть файлы определений тестов с подсказками по селекторам для каждой страницы. Агент читает эти подсказки, но может также обнаруживать элементы самостоятельно. Это больше похоже на "гайд по странице", чем на "объект страницы" — агент использует подсказки, когда они доступны, и рассуждает об альтернативах, когда они устарели.»

«Context Window» / «Token Budget»

Что говорят: «Как вы управляете контекстным окном?»

Что имеют в виду: У ИИ-моделей ограниченный размер контекста. Как вы гарантируете, что у агента достаточно места для рассуждений?

Что вы должны сказать: «Именно поэтому мы выбрали CLI-навыки, а не MCP. Каждое определение инструмента MCP стоит 200-500 токенов, загружаемых при каждом вызове API. С 15+ браузерными инструментами это 3 000-12 500 токенов за ход только на схемы. Наш CLI-навык стоит около 50 токенов за ход на описание навыка, плюс ~80 токенов за команду. 20-шаговый тест стоит 3 200 токенов через навык vs 92 000 через MCP — оставляя 98% контекстного окна для рассуждений вместо 39%.»

«Deterministic vs Non-Deterministic Testing»

Что говорят: «Как вы справляетесь с недетерминированной природой ИИ?»

Что имеют в виду: Традиционные тесты дают одинаковый результат каждый раз (детерминированные). ИИ-агенты могут идти разными путями (недетерминированные).

Что вы должны сказать: «Мы достигаем "практической детерминированности" — агент следует одному и тому же пути в 95%+ случаев, потому что инструкции SKILL.md и определения тестов ограничивают его решения. Оставшиеся 5% — это восстановление после ошибок, где недетерминированность на самом деле является преимуществом — агент пробует креативные решения, недоступные детерминированному скрипту.

Мы смягчаем риск через:

  1. Логирование команд — видим точно, что агент сделал
  2. Серию скриншотов — визуальные свидетельства каждого состояния
  3. CI-ворота — прошёл/не прошёл детерминирован, даже если путь варьируется
  4. Воспроизводимость — можем повторить залогированные команды для воспроизведения любого запуска»

«AI-Native» / «Agent-Native»

Что говорят: «Ваш инструмент AI-native?»

Что имеют в виду: Был ли он спроектирован с нуля для ИИ-агентов, или это традиционный инструмент с прикрученным ИИ?

Что вы должны сказать: «Vibium — AI-native, спроектирован с нуля для интеграции с агентами. Ключевые признаки: настройка без конфигурации (нет ручной установки браузера), CLI-first интерфейс (агенты используют Bash, а не API), вывод в stdout/stderr (агенты читают текст, а не парсят объекты), авто-ожидание готовности элемента (агенту не нужна логика повторов), и SKILL.md, который обучает агентов интерфейсу на их собственном языке (markdown). Сравните это с добавлением MCP-обёртки поверх Playwright — это AI-compatible, а не AI-native.»

«Composability»

Что говорят: «Насколько компонуем ваш фреймворк?»

Что имеют в виду: Могут ли компоненты использоваться независимо и комбинироваться разными способами?

Что вы должны сказать: «Высокая компонуемость. Каждая команда vibe-check независима и может комбинироваться с любым другим CLI-инструментом:

# Combine with jq for JSON parsing
vibe-check eval 'JSON.stringify(data)' | jq '.users[].email'

# Combine with diff for comparison
vibe-check text > before.txt
# ... do something ...
vibe-check text > after.txt
diff before.txt after.txt

# Combine with grep for assertions
vibe-check text | grep -q 'Welcome' && echo PASS || echo FAIL

Это преимущество философии Unix — маленькие инструменты, компонуемые через конвейеры. MCP-инструменты нельзя объединять в конвейеры.»