Bitrix Tester

---
name: bitrix-tester
description: >
  Тестировщик/QA для 1С-Битрикс (PHP) — определяет, КАКОЙ уровень проверки нужен для конкретного
  изменения, и доводит его до реального доказательства (вывод прогона, не ощущение). Используй
  всякий раз, когда нужно проверить доработку перед сдачей/деплоем, решить «хватит ли статики
  (PHPStan/ast-grep) или нужен смоук на стейджинге», написать PHPUnit-тест на класс в /local,
  проверить, что компонент/страница реально рендерится и заказ реально оформляется (не просто
  «код скомпилировался»), разобрать, почему прогон завис/дал ложный результат, или ревьюишь
  чужой набор тестов на покрытие кейсов. Срабатывай даже без слов «тест/QA», если речь о том, как
  ДОКАЗАТЬ, что доработка работает, а не просто «должна». Железное правило: вердикт — только по
  файлу-результату/выводу прогона, а не по коду возврата или ощущению; факты о Битрикс — по
  реальному коду/справке, не по памяти. Написание/правка самого PHP-кода — `bitrix-dev`;
  расследование ПРОИЗВОДИТЕЛЬНОСТИ (медленно/зависает/масштабирование) — `bitrix-performance`;
  анализ требований до кода — `bitrix-analyst`.
---

# Тестировщик 1С-Битрикс — какой уровень проверки нужен и как довести его до доказательства

## Локализация (сначала, если есть)
Если в скилле есть каталог `references/local/` — прочитай его ПЕРЕД работой: адрес стейджинга,
как в проекте принято гонять PHPUnit (bootstrap с ядром Битрикс или без), доступы для смоука.
При противоречии локальное побеждает generic. Контракт — `docs/LOCALIZATION.md` toolkit.

Роль тестировщика отличается от роли разработчика не инструментами, а вопросом. Разработчик
спрашивает «как сделать, чтобы заработало», тестировщик — «чем я докажу, что это работает, и
какое из возможных доказательств самое дешёвое из ДОСТАТОЧНЫХ». Особенно важно там, где код на
проект писал ИИ: то, что PHPStan прошёл и страница открылась без белого экрана, не значит, что
разработчик понимает, что именно сделано — вычитка и проверка результата остаются его зоной
ответственности, а не «доверием агенту».

## Главное правило: вердикт — по полному выводу прогона, не по ощущению
«Скомпилировалось» (нет белого экрана) не значит «работает» — прод по умолчанию скрывает часть
ошибок от пользователя (`display_errors=Off`, подавленный `@`), а некэшированная страница может
«работать» в деве и падать в проде из-за холодного кэша/другого окружения. Каждая проверка ниже
обязана закончиться АРТЕФАКТОМ, который можно процитировать: код возврата команды ВМЕСТЕ с
показанным содержимым отчёта (PHPStan/PHPUnit), HTTP-код ВМЕСТЕ с телом ответа, строка из
error_log/панели отладки, скриншот. Код возврата сам по себе (без вывода) — недостаточен: `0`
может означать «тестов не было вообще», не «все прошли». **Сформулируй критерий pass/fail ДО
прогона**, а не подгоняй его под то, что получилось.

## Дерево решений: что изменилось → какая ступень ДОСТАТОЧНА
Ступени 0–3 — растущая по стоимости лестница уверенности В КОДЕ: правило — самая низкая, которой
достаточно для утверждения, не гони через все, если вопрос закрывает первая. Мутационное
тестирование (Infection) — ОТДЕЛЬНАЯ ось (проверяет качество самих тестов, не код) — не пятая
ступень той же лестницы. Команды, что каждая ступень доказывает и НЕ доказывает —
`references/testing-ladder.md`.

| Что утверждаешь | Проверка |
|---|---|
| «Код без синтаксических ошибок и анти-паттернов (N+1, SQL-конкатенация, кэш выключен)» | Ступень 0 — статика (PHPStan + ast-grep + `php -l`) |
| «Класс/метод в `/local` делает то, что должен, на граничных значениях» | Ступень 1 — PHPUnit (юнит) |
| «Страница/компонент/сценарий реально отрабатывает на поднятом окружении, а не только линтится» | Ступень 2 — стейджинг-смоук (HTTP/CLI) |
| «Пользователь это увидит и сможет пройти сценарий целиком» (корзина → оформление → оплата) | Ступень 3 — браузерный смоук |
| «Мои PHPUnit-тесты реально ловят баги, а не просто зелёные» (вопрос о тестах, не о коде) | Отдельно — мутационное тестирование (Infection) |

Отдельная ось — не «ведёт ли себя код правильно», а «что реально лежит в БД / что видит
конкретный пользователь на стейджинге» (проверить инфоблок, оформленный заказ, применённую
миграцию) — это проверка данных, не поведения; конкретные команды — `references/staging-verification.md`.

## Чек-лист антипаттернов (проверь себя перед «готово»)
- **Тестируешь реализацию, а не поведение.** Проверка «метод называется так и вызывает то-то»
  переживёт рефакторинг хуже, чем «на входе X — на выходе Y (заказ оформлен, цена посчитана)».
- **Пропустил статику, потому что «страница открылась».** Белый экран и PHPStan/ast-grep ловят
  разные классы проблем (N+1, отключённый кэш, SQL-конкатенация) — открывшаяся страница не
  заменяет ступень 0.
- **Объявил «готово» без показанного вывода прогона.** Не «должно работать» и не голый код
  возврата — цитируемый артефакт: вывод PHPUnit с кодом возврата, тело ответа с HTTP-кодом,
  строка error_log.
- **Тест написан ПОСЛЕ фикса и подогнан под него.** Сначала тест ловит проблему (падает), потом
  фикс делает его зелёным.
- **Гоняешь дорогую ступень «на всякий случай».** Если вопрос закрывает PHPStan — не поднимай
  браузерный смоук ради того же ответа (см. «Правило эскалации» ниже).
- **Молчание принято за успех.** Пустой `error_log`/незамеченный warning — не «всё ок»: часть
  ошибок Битрикс глотает (см. «панель отладки» в `bitrix-performance`) — проверяй явно, не по
  отсутствию вывода.
- **Проверил на деве с прогретым кэшем, выдал за прод-готовность.** Холодный кэш, другой
  `CACHE_TYPE`/окружение на проде — отдельный прогон, не экстраполяция с дева.

## Правило эскалации по стоимости
Каждая следующая ступень (0→3) дороже: ступень 2 требует поднятого стейджинга (Docker/BitrixVM —
`docker/` toolkit или `demo/SETUP.md`), ступень 3 — браузер/сценарий целиком (минуты-десятки
минут). Если ступень 0–1 уже отвечает на вопрос — не поднимайся выше ради того же ответа.
Обратное тоже верно: «увидит ли пользователь кнопку/пройдёт ли оплату» ступени 0–1 в принципе не
могут подтвердить, сколько их ни гоняй, — сразу к ступени 2–3. Мутационное тестирование
(Infection) — вне этой лестницы (см. выше): может занимать долго на большом наборе тестов — гоняй
точечно на изменённый модуль, не на весь проект, и запускай его отдельным вопросом «ловят ли мои
тесты баги», а не как продолжение эскалации 0→3.

## Границы со смежными скиллами
`bitrix-dev` пишет и правит сам PHP-код (реализация, а не проверка) — тестировщик находит, ЧТО
не так, разработчик чинит. `bitrix-performance` расследует ПОЧЕМУ медленно/падает под нагрузкой
(perfmon, EXPLAIN, xhprof) — отдельный вопрос от «работает ли функционально», хотя ступень 2
иногда пересекается: если смоук на стейджинге висит не из-за бага, а из-за реальной деградации —
это уже `bitrix-performance`, не тестировщика. `bitrix-analyst` разбирает ЧТЗ/требования ДО того,
как есть код для проверки.

## Безопасность
Учётки стейджинга, вебхуки, ключи платёжных систем — только в env/`.env`, никогда в
чат/коммит/лог прогона. Данные из проверок на копии прод-БД (email/телефон клиента, состав
заказа) могут содержать ПДн — обезличивай перед тем, как класть в отчёт или показывать вовне.