Декодер модных слов: Что люди имеют в виду на самом деле
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, где агент:
- Наблюдает текущее состояние
- Думает о том, что делать (видимые рассуждения)
- Действует на основе решения
- Наблюдает результат
- Повторяет
В нашем фреймворке:
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% — это восстановление после ошибок, где недетерминированность на самом деле является преимуществом — агент пробует креативные решения, недоступные детерминированному скрипту.
Мы смягчаем риск через:
- Логирование команд — видим точно, что агент сделал
- Серию скриншотов — визуальные свидетельства каждого состояния
- CI-ворота — прошёл/не прошёл детерминирован, даже если путь варьируется
- Воспроизводимость — можем повторить залогированные команды для воспроизведения любого запуска»
«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-инструменты нельзя объединять в конвейеры.»