Qa Browser

---
name: qa-browser
description: Report-only QA-проход по вебу в браузере: чеклист флоу, severity, скриншоты-доказательства, отчет о багах - не чинит. "прогони QA", "найди баги в UI". Поднять браузер на машине - `agent-browser`.
---

# qa-browser

QA как дисциплинированный проход "глазами пользователя": с доказательствами, воспроизводимыми шагами и сравнимым между прогонами отчетом - вместо "потыкал, вроде работает".

Жесткое разделение ролей: в этом скилле ты QA-инженер, НЕ разработчик. Исходники во время прохода не читать (исключение - фаза выбора целей по диффу), файлы не править. Найденное чинится потом, отдельной задачей с обычным циклом проекта (тесты, ревью). Это снижает confirmation bias: тестируешь поведение, а не свое понимание кода.

## Когда применять / не применять

- Применять: после заметных правок UI/форм/флоу; после деплоя на dev/staging; по явной просьбе.
- Не применять: для чисто серверных изменений без UI-поверхности; вместо unit/интеграционных тестов; на чужих сайтах и на продакшне без явного указания.

## Параметры прохода

Зафиксировать перед стартом (спросить, если не очевидно из запроса):

- **target** - базовый URL и контур (dev/staging/prod; по умолчанию НЕ prod);
- **tier** - `quick` (smoke: стартовая страница + основная навигация) или `standard` (полный чеклист по выбранным целям);
- **scope** - конкретные страницы/флоу, либо "что затронуто диффом";
- **auth** - под какой учеткой заходить и откуда брать креды (по правилам секретов проекта; пароль в чат и в отчет не попадает; если источник кредов не найден - остановиться и спросить, не подбирать).

Браузерная площадка по умолчанию - серверная (`chrome-devtools`); если у устройства их несколько, выбор - по `rules/agent-browser.md`.

## Выбор целей: diff-aware

Если scope не задан явно, а работа идет на ветке или после правок - цели выбираются по диффу, а не полным обходом:

1. Список измененных файлов (`git diff --name-only` против базовой ветки) сопоставить со страницами: controller/route -> его URL; view/компонент/шаблон -> страницы, где он рендерится; model/service -> страницы контроллеров-потребителей; CSS/JS -> подключающие страницы.
2. Сопоставить не удалось - не пропускать браузерный тест, а откатиться в `quick`-tier.

## Фазы прохода

1. **Init** - открыть target, скриншот стартовой страницы, снять консоль (шум "до" - чтобы не приписать старые ошибки новым правкам).
2. **Auth** - логин оговоренной учеткой. Капча/2FA - остановиться и попросить пользователя пройти руками, не обходить.
3. **Orient** - структурный снапшот страницы, карта навигации: какие разделы достижимы, что из них в scope.
4. **Explore** - по каждой цели чеклист:
   - визуальный скан: layout, обрезанный/налезающий текст, переполнение;
   - интерактив: кнопки, меню, сортировки, фильтры, пагинация;
   - формы: обязательность полей, граничные значения, невалидный ввод, submit (перед submit оценить побочные эффекты - см. "Чего скилл НЕ делает");
   - состояния: empty / loading / error - где достижимы;
   - консоль после каждого взаимодействия;
   - для ключевых страниц в `standard`-tier - проверка в мобильном viewport (в `quick` пропускается).
5. **Document** - баг фиксируется сразу при обнаружении по evidence-протоколу, не батчем в конце.
6. **Wrap up** - сводка severity, топ-3 к починке, отчет.

## Критерий "баг / не баг"

Категории: Visual / Functional / UX / Content / Performance / Console / Accessibility.

Severity:

- **critical** - блокирует ключевой флоу или портит данные;
- **high** - функция не работает, но есть обходной путь;
- **medium** - работает неправильно или ощутимо неудобно, флоу не блокирован;
- **low** - косметика.

## Evidence-протокол

- **Repro is everything**: баг без шагов воспроизведения и скриншота в отчет не попадает.
- **Verify before documenting**: перед записью воспроизвести повторно - отсечь транзиентные состояния и флуктуации рендера.
- Интерактивный баг - скриншот ДО действия -> действие -> скриншот ПОСЛЕ; при неочевидной разнице дополнить текстовым сравнением двух структурных снапшотов (что было -> что стало).
- Статический баг (layout, типографика) - один скриншот.
- Каждый скриншот показывать пользователю в ответе - недоказанная находка невидима.
- Секреты на скриншотах, в шагах воспроизведения и в цитируемых консольных/network-логах маскировать.

## Формат отчета

Markdown-файл в рабочей папке проекта; в имени - дата и scope, чтобы повторный прогон не затирал предыдущий отчет (по конвенции проекта, например `docs/qa-reports/qa-<YYYY-MM-DD>-<scope>.md`):

- шапка: дата, target, контур, ветка/коммит, tier, scope;
- сводка: счетчики по severity, "топ-3 к починке";
- консольные ошибки: страница, сообщение, при каком действии;
- issues: ID, severity, категория, URL, шаги воспроизведения, ожидаемое/фактическое, ссылки на скриншоты.

В чат - компактная сводка (вердикт, счетчики, топ-3), не весь отчет.

## Чего скилл НЕ делает

- Не правит код, не коммитит, не деплоит.
- Не пишет регрессионные тесты сам - в отчете предлагает список "какие тесты закрыли бы найденное"; написание идет отдельной задачей по TDD-циклу проекта.
- Не сабмитит формы с необратимыми или внешними эффектами (реальные письма/SMS, платежи, удаление данных, внешние вебхуки), пока не подтверждено, что окружение песочное; сомнение трактуется как "нельзя".
- Не уходит за пределы target-домена по внешним ссылкам, если scope явно не велит иначе.
- Не тестирует чужие продакшны и не обходит защиту (капча, антибот).