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 явно не велит иначе.
• Не тестирует чужие продакшны и не обходит защиту (капча, антибот).

Модель и текущие назначения

Перед новым заданием и запуском применяй маршрутизацию моделей: свежий MODELS выше канонического дефолта. Границы данных и полномочий этого навыка сохраняются.