Modern QA2026QA-собеседование уровня архитектора: 20 вопросов и ответов
Join

Course › 01 Agent Skills for Browser Automation

Cutting-edge · Chapter 01

QA-собеседование уровня архитектора: 20 вопросов и ответов

Updated Jul 2026

Категория 1: Архитектура и проектирование

В1: «Почему вы бы выбрали агентно-управляемую автоматизацию браузера вместо традиционных Playwright/Selenium?»

Ответ: «Традиционная автоматизация детерминирована — вы пишете точные шаги, и они выполняются одинаково каждый раз. Это отлично для регрессии, но ужасно для адаптивности. Когда UI меняется, каждый затронутый тест ломается.

Агентно-управляемая автоматизация добавляет уровень рассуждений. Агент понимает намерение ("проверить, что логин работает"), а не просто шаги ("кликнуть button#submit"). Когда селектор меняется, агент может найти элемент по текстовому содержимому, структуре страницы или визуальному анализу. Когда появляется неожиданный диалог, агент может его закрыть и продолжить.

Компромисс — недетерминированность и стоимость. Мы смягчаем недетерминированность логированием каждой команды для воспроизводимости, а стоимость управляем через CLI-навыки вместо MCP, чтобы потребление токенов оставалось на уровне ~2% контекста за тест.»

В2: «Расскажите об архитектуре вашего фреймворка автоматизации тестирования.»

Ответ: «Три уровня:

Уровень 1 — Определения тестов (YAML): Шаги на естественном языке с необязательными подсказками по селекторам. Они версионируются и читаемы для человека.

Уровень 2 — Оркестратор-агент (Claude Code + Skills): ИИ-агент читает определения тестов, загружает навык vibe-check, который обучает его 22 браузерным командам, и выполняет тесты с помощью инструмента Bash. Агент определяет стратегию выполнения, обрабатывает сбои и формирует отчёты о результатах.

Уровень 3 — Браузерная инфраструктура (Vibium): Go-бинарник, управляющий Chrome через WebDriver BiDi. Работает как daemon в разработке (быстро, ~100 мс на команду) или oneshot в CI (изолированно, ~2 с на команду). Реализует проверки интерактивности в стиле Playwright на стороне сервера.

Ключевой вывод: агент работает на Уровне 2, принимая интеллектуальные решения, а инфраструктура на Уровне 3 обрабатывает механическую сложность управления браузером. Навык — это мост: 100-строчный markdown-файл, который даёт агенту все необходимые доменные знания.»

В3: «Как навык vibe-check работает изнутри?»

Ответ: «Когда агент решает, что нужна автоматизация браузера, он вызывает навык vibe-check. Система загружает markdown-файл — SKILL.md — в контекст разговора агента. Этот файл документирует 22 CLI-команды для управления браузером.

Затем агент выполняет команды через инструмент Bash: vibe-check click 'button.submit'. Это достигает демона Vibium — Go-бинарника, работающего как фоновый процесс. Демон — это WebDriver BiDi прокси: он перехватывает команду, переводит её в сообщения протокола BiDi, выполняет пять проверок интерактивности (видимость, стабильность, получение событий, активность, редактируемость) в цикле опроса, и когда все проходят, выполняет действие через BiDi input.performActions.

Полная цепочка: Навык загружает markdown → Агент отправляет Bash-команду → CLI соединяется с демоном → Демон проверяет интерактивность → Демон отправляет BiDi в Chrome → Chrome выполняет → Ответ распространяется обратно.»

В4: «Как вы справляетесь с нестабильностью тестов в ИИ-управляемом фреймворке?»

Ответ: «Мы различаем три типа «нестабильности»:

Истинная нестабильность (проблемы с таймингом): Проверки интерактивности Vibium решают это — каждый клик/ввод автоматически ожидает до 30 секунд, пока элемент не станет видимым, стабильным, не закрытым другим элементом и активным. Это устраняет 80% традиционной нестабильности.

Инфраструктурная нестабильность (сеть, падения браузера): Режим oneshot в CI даёт каждому тесту чистый браузер. Для сетевых проблем мы устанавливаем явные тайм-ауты и сохраняем артефакты сбоев (скриншот + текст страницы), чтобы агент мог порассуждать о том, что произошло.

Нестабильность логики тестов (недетерминированное поведение агента): Мы логируем каждую команду, которую агент выполняет. Если тест проходит непоследовательно, мы просматриваем лог команд, чтобы увидеть, где рассуждения агента разошлись. Затем мы добавляем подсказки по селекторам или более явные шаги теста, чтобы ограничить решения агента.

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

В5: «Какова ваша стратегия интеграции CI/CD?»

Ответ: «Headless Chrome, режим oneshot, матричная стратегия GitHub Actions.

Каждая группа тестов (auth, dashboard, checkout) запускается как отдельная матричная задача со своим экземпляром браузера. Тесты используют --headless и VIBIUM_ONESHOT=1 для чистой изоляции. При сбое мы сохраняем скриншоты, текст страницы и URL как артефакты GitHub Actions со сроком хранения 30 дней.

Мы выводим JUnit XML для интеграции с дашбордами и JSON-отчёт для программного анализа. Скрипт запуска тестов — это Bash-скрипт, который оборачивает команды vibe-check и отслеживает счётчики прошёл/не прошёл с правильными кодами выхода.

Для параллельного выполнения внутри задачи мы используем xargs -P4 для запуска до 4 тестов одновременно. Каждый экземпляр Chrome использует ~200 МБ RAM, поэтому стандартный раннер на 7 ГБ спокойно поддерживает 6 параллельных рабочих.»

Категория 2: Технические погружения

В6: «Объясните проверки интерактивности. Почему они реализованы на стороне сервера?»

Ответ: «Пять проверок выполняются перед каждым взаимодействием:

  1. Visible — Ненулевые размеры, не display:none или visibility:hidden
  2. Stable — Позиция не изменилась за 50 мс (ловит CSS-анимации)
  3. ReceivesEvents — elementFromPoint() в центре попадает в целевой элемент, а не в перекрывающий
  4. Enabled — Не disabled, aria-disabled и не в отключённом fieldset
  5. Editable — (только для ввода) Принимает текстовый ввод, не readonly

Они выполняются в цикле опроса с интервалом 100 мс до тех пор, пока все не пройдут или не наступит тайм-аут (по умолчанию 30 с).

Они на стороне сервера в Go-бинарнике, потому что:

  • Единая реализация — написаны один раз, не дублируются для JS, Python, CLI
  • Уменьшенная задержка — опрос происходит по локальному WebSocket, а не через round trip клиент→прокси→браузер
  • Простые клиенты — клиентский код тривиален: отправить команду, ждать ответа
  • Единообразное поведение — все клиенты получают идентичный тайминг

Это та же концепция, что у Playwright, но архитектурно другая. Playwright реализует их в каждой клиентской библиотеке. Vibium реализует их один раз в прокси.»

В7: «Что такое WebDriver BiDi и почему это важно?»

Ответ: «WebDriver BiDi — это стандарт W3C, который объединяет лучшее из двух предшественников. Классический WebDriver был стандартизирован и кросс-браузерен, но однонаправлен — HTTP запрос/ответ, без событий. CDP был двунаправленным с богатыми событиями, но специфичен для Chrome и нестабилен.

BiDi использует WebSocket для двунаправленного JSON-обмена сообщениями — и команды от клиента к браузеру, И события, отправляемые от браузера к клиенту. Он управляется W3C с поддержкой всех основных производителей браузеров.

Для нашего фреймворка BiDi означает:

  • Основан на стандартах — не зависит от внутреннего протокола Google
  • Защита от устаревания — по мере улучшения поддержки BiDi браузерами наши инструменты улучшаются
  • Кросс-браузерность — единый протокол для Chrome, Firefox, Edge, со временем Safari
  • События — логи консоли, сетевая активность передаются нам в реальном времени

Vibium нативно построен на BiDi, создан человеком, который начал Selenium. Go-бинарник выступает BiDi-прокси, добавляя проверки интерактивности как команды-расширения.»

В8: «Как работает BiDi-прокси Vibium?»

Ответ: «Бинарник clicker располагается между клиентами и Chrome как WebSocket-прокси.

Для стандартных команд BiDi, таких как browsingContext.navigate, он передаёт сообщения напрямую. Для пользовательских команд vibium:*, таких как vibium:click, он перехватывает их и запускает цикл интерактивности локально.

vibium:click транслируется примерно в 8-10 внутренних BiDi-вызовов: несколько script.callFunction для каждой проверки интерактивности, плюс input.performActions для фактического клика. Но клиент видит только один запрос и один ответ.

Механизм расширений — часть спецификации BiDi: модули расширений используют соглашение об именовании с двоеточием. Поэтому vibium:click — это легитимное расширение BiDi, а не хак протокола.»

В9: «Объясните экономику токенов навыков vs MCP для автоматизации браузера.»

Ответ: «Я это измерил. 20-шаговый тест через Playwright MCP потребляет примерно 92 000 токенов: ~67 000 от схем инструментов, загружаемых каждый ход (15+ инструментов x 20 ходов), ~20 000 от деревьев доступности и ~5 000 от вызовов/ответов инструментов. Это 61% контекстного окна в 200K.

Тот же тест через навык vibe-check стоит около 3 200 токенов: ~1 000 за начальную инъекцию SKILL.md, ~1 000 за описания навыков между ходами и ~1 200 за Bash-команды и их текстовый вывод.

Это 29-кратное сокращение. При $15 за миллион входных токенов каждый тест стоит $1,38 через MCP против $0,05 через навыки. При сотнях CI-запусков в день это разница между жизнеспособным и неустойчивым подходом.

Что ещё важнее, 147K сэкономленных токенов остаются доступными для рассуждений агента — анализа сбоев, сравнения состояний, поддержания истории разговора.»

В10: «Как вы реализуете самовосстанавливающиеся тесты?»

Ответ: «Три уровня:

Уровень 1 (~80% сбоев, ~500 токенов): Когда селектор не срабатывает, агент запускает vibe-check find-all для обнаружения существующих элементов, сопоставляет по текстовому содержимому и повторяет с альтернативным селектором.

Уровень 2 (~15% сбоев, ~800 токенов): Агент делает скриншот и читает текст страницы для понимания текущего состояния. Ловит проблемы с загрузкой, перенаправления и неожиданные диалоги.

Уровень 3 (~5% сбоев, ~5 500 токенов): Резервное переключение на дерево доступности MCP для семантического анализа страницы, когда структура принципиально изменилась.

Мы отслеживаем события восстановления в логе. Высокая частота восстановлений в одном тесте означает, что нужно обновить селекторы. Высокая частота по всем тестам означает крупный UI-рефакторинг. Ключевое различие: самовосстановление должно исправлять устаревшие селекторы, а не маскировать нестабильные тесты.»

Категория 3: Стратегия и компромиссы

В11: «Когда вы бы НЕ использовали агентно-управляемое тестирование?»

Ответ: «Три сценария:

  1. Тестирование производительности — Вам нужны детерминированные, повторяемые измерения. Накладные расходы агента (~200 мс рассуждений на шаг) неприемлемы для нагрузочного тестирования.

  2. Тривиальные регрессионные проверки — «Возвращает ли главная страница 200?» не требует ИИ. Простая проверка через curl быстрее, дешевле и надёжнее.

  3. Комплаенс-тестирование с аудиторскими требованиями — Некоторые регуляции требуют, чтобы тестовые скрипты были детерминированными и воспроизводимыми. Рассуждения агента вносят вариативность, которую аудиторы могут не принять.

Для этих случаев традиционные скрипты Playwright/Selenium лучше. Оптимальная область для агентов — сложные функциональные потоки, исследовательское тестирование и тесты, которые должны адаптироваться к меняющемуся UI.»

В12: «Как бы вы убедили скептически настроенного архитектора, что ИИ-тестирование готово к продакшену?»

Ответ: «Я бы ответил на три распространённых возражения:

«ИИ недетерминирован.» Верно, но мы смягчаем это логированием каждой команды для воспроизводимости. Если агент пошёл неправильным путём, мы можем точно увидеть, где и почему. На практике один и тот же тест порождает одинаковую последовательность команд в 95%+ случаев, потому что агент детерминированно следует инструкциям SKILL.md — рассуждения расходятся только при восстановлении после ошибок.

«Это слишком дорого.» С CLI-навыками каждый запуск теста стоит ~$0,05 в токенах. Набор из 500 тестов стоит ~$25 за полный запуск. Сравните это с часами инженера, сэкономленными на поддержке тестов — даже один день работы QA-инженера окупает месяцы агентно-управляемого тестирования.

«Это слишком медленно.» Каждая браузерная команда занимает 100-300 мс в режиме daemon. 20-шаговый тест выполняется за 3-5 секунд. Рассуждения агента добавляют ~200 мс на шаг. Итого: примерно сопоставимо с традиционной автоматизацией, иногда быстрее, потому что агенту не нужно ждать явных sleep().

Затем я бы показал реальные данные: 60-85% сокращение времени поддержки тестов, потому что при изменении UI агент адаптируется вместо того, чтобы требовать обновлений тестов.»

В13: «Как вы управляете тестовыми данными?»

Ответ: «Три подхода в зависимости от потребностей изоляции:

Встроенные тестовые данные: Для простых тестов данные встроены в определение теста. vibe-check type '#email' 'test@example.com' — email прямо здесь.

Настройка через API: Для тестов, которым нужно определённое состояние (учётные записи, история заказов), мы вызываем API приложения перед браузерными тестами для создания необходимых данных. Агент может это делать через curl или vibe-check eval 'fetch(...)'.

Сидинг базы данных: Для CI мы запускаем миграционные скрипты, создающие известное состояние перед набором тестов. Каждая группа тестов получает свою базу данных или раздел схемы для изоляции.

Агент не управляет тестовыми данными напрямую — он фокусируется на UI-взаимодействии. Настройка данных обрабатывается скриптами в директории /scripts/ фреймворка.»

В14: «Как выглядит ваша пирамида тестирования с ИИ?»

Ответ:

        /\
       /  \   Agent-driven E2E (browser tests via vibe-check)
      /    \  ~50 tests, critical user journeys
     /______\
    /        \  API/Integration tests (traditional)
   /          \ ~200 tests, business logic verification
  /____________\
 /              \ Unit tests (traditional)
/________________\ ~2000+ tests, code correctness

ИИ-управляемое тестирование находится на вершине пирамиды — наименьшее количество тестов с наибольшим покрытием на тест. Мы не используем ИИ для модульных тестов (детерминированные, браузер не нужен) или большинства API-тестов (нет UI). Агент добавляет ценность там, где нужна человеческая оценка: сложные потоки, визуальная верификация, адаптивное взаимодействие.»

Категория 4: Практические сценарии

В15: «Расскажите, как вы отлаживаете упавший браузерный тест.»

Ответ: «Артефакты сбоя дают нам всё необходимое:

  1. Лог команд — Я вижу точную последовательность команд vibe-check. Шаг 7 — vibe-check click '.btn-confirm', который завершился тайм-аутом.

  2. Скриншот — Я смотрю failures/test-name/screenshot.png. Вижу состояние страницы в момент сбоя. В данном случае модальное окно перекрывает кнопку.

  3. Текст страницы — failures/test-name/page_text.txt показывает «Are you sure you want to proceed?» — это диалог подтверждения, которого тест не ожидал.

  4. Исправление — Я добавляю шаг для обработки диалога подтверждения: vibe-check click '.modal-confirm' перед оригинальным кликом. Или обновляю определение теста, чтобы ожидать этот диалог.

Если агент работал, он мог бы самовосстановиться — обнаружив модальное окно, кликнув кнопку подтверждения и продолжив. Но мы всё равно проверили бы лог восстановления, чтобы решить, нужно ли обновить определение теста.»

В16: «Как бы вы тестировали Single Page Application?»

Ответ: «SPA имеют специфические сложности: навигация не вызывает полной перезагрузки страницы, контент рендерится асинхронно, а URL может не меняться.

Ключевые техники с vibe-check:

  1. Ожидание конкретных элементов, а не загрузки страницы:
vibe-check navigate https://spa.example.com
vibe-check wait '.app-loaded'  # Wait for React/Vue to render
  1. Использование --wait-open для начальной гидратации:
vibe-check navigate https://spa.example.com --wait-open 3
  1. Проверка клиентской маршрутизации по тексту, а не по URL:
vibe-check click 'a[href=\"/dashboard\"]'
vibe-check wait '.dashboard-content'
vibe-check text 'h1'  # Verify content, not URL
  1. Обработка ленивой загрузки:
vibe-check scroll down --amount 1000
vibe-check wait '.lazy-loaded-component'

Проверки интерактивности автоматически обрабатывают большинство проблем с таймингом SPA — 30-секундное авто-ожидание означает, что вам редко нужны явные ожидания.»

В17: «Как вы обрабатываете аутентификацию между тестами?»

Ответ: «Три стратегии:

Стратегия 1 — Вход через UI (реалистично, медленно):

vibe-check navigate https://app.example.com/login
vibe-check type '#email' 'test@example.com'
vibe-check type '#password' 'secret'
vibe-check click '#submit'
vibe-check wait '.dashboard'

Стратегия 2 — Инъекция cookie (быстро, надёжно):

vibe-check navigate https://app.example.com
vibe-check eval 'document.cookie = \"session=abc123; path=/\"'
vibe-check navigate https://app.example.com/dashboard  # Now authenticated

Стратегия 3 — Аутентификация через API (самая быстрая, для CI):

TOKEN=$(curl -s -X POST https://api.example.com/auth/login \
  -d '{"email":"test@example.com","password":"secret"}' | jq -r '.token')
vibe-check navigate https://app.example.com
vibe-check eval "localStorage.setItem('auth_token', '$TOKEN')"
vibe-check navigate https://app.example.com/dashboard

Мы используем Стратегию 1 для собственно теста логина, Стратегию 3 для всех остальных тестов. Это даёт нам одну тщательную верификацию входа плюс быструю настройку для всего остального.»

В18: «Как вы обрабатываете тесты, взаимодействующие со сторонними сервисами?»

Ответ: «Три подхода:

  1. Мокирование на сетевом уровне: Используем vibe-check eval для перехвата вызовов fetch():
vibe-check eval '
  window._originalFetch = window.fetch;
  window.fetch = (url, opts) => {
    if (url.includes(\"stripe.com\")) {
      return Promise.resolve(new Response(JSON.stringify({id: \"mock_pi_123\"})));
    }
    return window._originalFetch(url, opts);
  }
'

  1. Использование тестовых/sandbox-окружений: Большинство платёжных провайдеров (Stripe, PayPal) имеют sandbox-режимы. Настройте приложение на использование sandbox-учётных данных в тестовом окружении.

  2. Остановка на границе: Тестируйте до точки взаимодействия со сторонним сервисом, верифицируйте тело запроса через eval, затем пропускайте фактический внешний вызов.»

В19: «Какие метрики вы отслеживаете для автоматизации тестирования?»

Ответ: «Пять ключевых метрик:

  1. Показатель надёжности тестов — % тестов, проходящих стабильно (цель: >98%)
  2. Частота самовосстановления — % запусков, в которых агент восстановился после сбоя (отслеживать во времени — должна снижаться по мере стабилизации селекторов)
  3. Время выполнения — По каждому тесту и набору (обнаружение регрессий производительности)
  4. Стоимость токенов — По каждому тесту и набору (управление бюджетом)
  5. Время от сбоя до исправления — Сколько времени между сбоем теста и мержем исправления (измеряет ценность артефактов сбоев)

Мы отслеживаем это в JSON-отчёте за каждый запуск и строим графики трендов еженедельно. Скачок частоты самовосстановления означает, что UI-деплой что-то изменил. Скачок времени выполнения означает, что либо приложение стало медленнее, либо тест застрял.»

В20: «Куда движется ИИ-управляемое тестирование в ближайшие 2-3 года?»

Ответ: «Три направления:

  1. ИИ-управляемые локаторы — Вместо CSS-селекторов агент говорит «кликни синюю кнопку отправки». Модели зрения определяют элементы визуально. Дорожная карта Vibium V2 включает это. Задача — задержка и стоимость вызовов API зрения.

  2. Непрерывное обучение — Планируемый компонент Cortex от Vibium строит «карту приложения» из прошлых сессий. Агент использует её для планирования многошаговой навигации и избежания повторного обнаружения. Можно представить это как слой тестового интеллекта, который обучается вашему приложению со временем.

  3. Автономный QA — Агент не просто выполняет предопределённые тесты — он исследует приложение, выявляет потенциальные проблемы и генерирует тесты автоматически. OpenObserve уже делает это с подходом «Council of Sub Agents» — 8 специализированных ИИ-агентов, которые увеличили набор тестов с 380 до 700+.

Паттерн агентных навыков — легковесный markdown, который обучает агентов доменным знаниям — становится стандартным интерфейсом. В Skills Directory уже более 50 000 навыков. Автоматизация браузера — лишь одна область; тот же паттерн применим к API-тестированию, верификации баз данных и валидации инфраструктуры.»