Мой QA-инженер — это LLM

Claude может нажимать на кнопки.

Звучит банально, но это меняет то, как я создаю UI. С Playwright MCP Claude не просто пишет код — он открывает браузер, переходит на localhost и проверяет, что все действительно работает. Он находит баги, которые я пропустил бы при ревью кода.

Настройка

Playwright MCP дает Claude автоматизацию браузера. Я запускаю его с headless Chromium:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@anthropic-ai/mcp-server-playwright", "--headless"]
    }
  }
}

Теперь Claude может перемещаться, кликать, печатать и делать скриншоты. Он видит то, что видят пользователи.

flowchart LR
    Claude([Claude Code]) -->|browser_snapshot| PW[Playwright MCP]
    PW --> Browser[Headless Chrome]
    Browser --> App[localhost:1313]
    Browser -.->|screenshot| Issue[(GitHub Issue)]
    Issue -.->|visual history| PR[Pull Request]
flowchart TB
    Claude([Claude Code]) -->|browser_snapshot| PW[Playwright MCP]
    PW --> Browser[Headless Chrome]
    Browser --> App[localhost:1313]
    Browser -.->|screenshot| Issue[(GitHub Issue)]
    Issue -.->|visual history| PR[Pull Request]

Поток: Claude Code → Playwright MCP → Браузер → Скриншоты → GitHub Issues → PR

Матрица Viewport

Каждое изменение UI тестируется на трех точках останова:

ViewportРазмерПочему
Desktop1440×900Стандартный ноутбук
Tablet1024×768iPad портретный
Mobile390×844iPhone 14

Claude изменяет размер браузера, делает скриншот, загружает его в GitHub Issue. Три скриншота на изменение состояния. Если мобильная навигация сломана, я вижу это немедленно — не после развертывания.

Тестирование Тем

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

// Claude переключает тему
await page.click('[data-testid="theme-toggle"]');
// Скриншоты обоих состояний

Согласованность CSS-переменных имеет значение. Компонент, который хорошо выглядит в светлом режиме, может иметь невидимый текст в темном режиме. Claude обнаруживает это, фактически глядя на оба.

Интерактивное Тестирование

Здесь становится интересно. Claude не просто делает скриншоты — он использует UI:

Когда он находит баг — скажем, drawer не закрывается при нажатии снаружи — он сообщает об этом, исправляет код и повторно тестирует. Цикл обратной связи короткий.

GitHub Issue как Отчет о Тестировании

Каждый скриншот загружается в GitHub Issue. Тело Issue перестраивается на каждом этапе:

## Текущее Состояние

### Desktop (1440×900)
![desktop](https://user-images.githubusercontent.com/...)

### Tablet (1024×768)
![tablet](https://user-images.githubusercontent.com/...)

### Mobile (390×844)
![mobile](https://user-images.githubusercontent.com/...)

## Чек-лист Тестирования
- [x] Ссылки навигации работают
- [x] Мобильный drawer открывается/закрывается
- [x] Переключение темы сохраняется
- [ ] Валидация формы показывает ошибки

Issue становится живым отчетом о тестировании. Любой, кто проверяет PR, может увидеть точно, что было протестировано.

Полный Цикл

Типичная функция проходит через этот цикл:

  1. Issue создан: “Добавить боковую навигацию”
  2. Claude реализует: Пишет компонент
  3. Визуальная проверка: Скриншоты всех viewport
  4. Интерактивное тестирование: Кликает по UI
  5. Баг найден: Drawer не закрывается при клике на фон
  6. Исправление применено: Обновляет обработчик клика
  7. Повторное тестирование: Свежие скриншоты, все пройдено
  8. PR создан: Ссылка на Issue с полной визуальной историей

Никакого ручного QA-этапа. Никакого “выглядит хорошо” без фактического просмотра. Claude проверяет свою собственную работу.

Что Это Обнаруживает

Реальные баги, которые я видел, как Claude находит:

Это баги, которые проскакивают через ревью кода, потому что они появляются только в браузере. Claude видит их, потому что он фактически запускает код.

Каждый PR теперь идет с доказательством, что он работает.