1c Tester

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

Локализация (сначала, если есть)

Если в скилле есть каталог references/local/ — прочитай его ПЕРЕД работой: version-stack.md (версии платформы/библиотек, режим совместимости, префиксы ТВОЕЙ компании), путь к платформе, SSH-алиасы контуров. При противоречии локальное побеждает generic. Контракт — docs/SKILL_LOCALIZATION.md toolkit.

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

Главное правило: вердикт — по файлу/выводу, не по ощущению

Клиентский запуск кода не даёт кода возврата; Сообщить()/журнал регистрации в /Out не попадают; «скомпилировалось» не значит «работает»; тишина в консоли не значит «упало» и не значит «прошло». Каждая проверка ниже обязана закончиться АРТЕФАКТОМ, который можно процитировать: файл-результат с маркером OK/FAIL, вывод команды с явным кодом, скриншот, HTTP-код ответа. Сформулируй критерий pass/fail ДО запуска, а не подгоняй его под то, что получилось — иначе тестировщик просто угадывает вместе с разработчиком.

Дерево решений: что изменилось → какая ступень ДОСТАТОЧНА

Правило — самая низкая ступень, которой достаточно для утверждения. Не гони через все пять, если вопрос закрывает первая. Полное описание ступеней, команды запуска, чего каждая НЕ проверяет и от каких доступов зависит — references/testing-ladder.md.

Отдельная ось — не «ведёт ли себя код правильно», а «что реально лежит в данных / что видит конкретный пользователь» (отладка RLS, проверка на живых данных, доступ AI к данным). Это доступ к данным (OData / HTTP-сервис расширения), не поведение — путь и конкретные команды (включая три обязательные поправки на кодировку при проверке через curl) — references/data-access-verification.md.

⚠ Но развилка не по слову «данные», а по задаче, и порядок предпочтения такой:

1. Данные чувствительные (персональные, платёжные, зарплатные; вообще всё, что не должно утечь в отчёт прогона) — сначала onec-data, даже если чтение разовое: он read-only by design и отдаёт данные под RLS исследуемого пользователя. Раннер ступени 2 исполняет произвольный BSL, платформа не гарантирует там read-only и не маскирует ПДн. Запрета на раннер нет — публикации может не быть, а данные нужны сейчас, — но тогда обезличивание результата целиком на человеке: агрегаты и маски вместо строк, прежде чем результат попадёт в отчёт, наружу или в контекст AI (предупреждение в §B.2 references/data-access-verification.md).
2. Разовое чтение нечувствительного (что лежит в константе-настройке, сколько записей, заполнен ли реквизит) — ступень 2, батч ENTERPRISE + раннер-EPF; она же ЕДИНСТВЕННЫЙ канал, когда публикации у базы нет. Публикация и отладочное расширение не нужны (расширение — предусловие L3, а L2 — стандартный OData), rac тоже.
3. Повторяемый или интерактивный доступ, чтение под конкретным пользователем, сам HTTP-контракт — references/data-access-verification.md.

Цена ступени 2, чтобы не обещать лишнего: доступы наследуются от ступени 1 — сборка раннера (--deploy) идёт Дизайнером, то есть нужны права конфигуратора; прогон идёт под /N /P, данные приходят под RLS этого пользователя, а «Защита от опасных действий» может встать модальным окном. Сценарий держать строго читающим. Подробности и команды — там же, в references/data-access-verification.md.

Юнит-тесты и BDD-сценарии — конвенции, не только «какой фреймворк»

Если решение — ступень 4 и нужен модульный тест (YAxUnit) или сценарий (Vanessa/Gherkin), конвенции именования, обязательные типы кейсов, паттерн структуры теста и чек-лист самопроверки ПЕРЕД тем, как писать — references/unit-test-conventions.md. Не изобретай собственный стиль на каждый тест — расхождение в конвенциях дороже самого теста при ревью.

Чек-лист антипаттернов (проверь себя перед «готово»)

• Тестируешь реализацию, а не поведение. Проверка «функция называется так и вызывает то-то» переживёт рефакторинг хуже, чем «на входе X — на выходе Y». Если тест ломается от безобидного рефакторинга — он проверял не то.
• Пропустил статику, потому что «скомпилировалось». Компиляция и BSL LS ловят разные классы проблем (анти-паттерны, целостность СКД) — «скомпилировалось» не заменяет ступень 0.
• Объявил «готово» без показанного вывода прогона. Не «должно работать» и не голый код возврата — цитируемый артефакт (см. «Главное правило» выше).
• Тест написан ПОСЛЕ фикса и подогнан под него. Порядок обратный: сначала тест ловит проблему (падает), потом фикс делает его зелёным. Тест, написанный постфактум под уже работающий код, не доказывает, что он ловит регресс.
• Гоняешь дорогую ступень, потому что «на всякий случай». Если вопрос закрывает CheckConfig — не разворачивай Vanessa/UI-автоматизацию ради того же ответа (см. ниже).
• Молчание принято за успех. Пустой лог/вывод — это отдельный диагноз («защита от опасных действий», занятая база, GUI-приложение без окна), не «всё ок» и не «зависло» автоматически — см. таблицу диагностики в references/testing-ladder.md и references/data-access-verification.md.

Правило эскалации по стоимости

Каждая следующая ступень дороже предыдущей не только временем, но и тем, что ставит на кон: ступень 2–3 расходует клиентскую лицензию и сеанс; ступень 3–4 требует машины с клиентом и может занимать часы на настройку. Если ступень 0–1 уже даёт ответ на вопрос («применяется ли расширение», «нет ли анти-паттерна») — не поднимайся выше ради того же ответа. Обратное тоже верно: если вопрос — «увидит ли пользователь кнопку», ступень 0–2 в принципе не может на него ответить, сколько её ни гоняй, — сразу к ступени 3.

Границы с соседними скиллами

1c-dev пишет и правит сам BSL-код (реализация, а не проверка) — тестировщик находит, ЧТО не так, разработчик чинит. Это же разделение действует и для доступа к данным: когда любой скилл (в первую очередь 1c-dev) упирается в вопрос «что реально лежит в данных / что видит пользователь» (посчитать записи, прочитать регистр, отладить через OData), это не повод изобретать доступ вручную — вызывай 1c-tester. Он выбирает канал в том же порядке, что и блок выше: чувствительные данные (персональные, платёжные, зарплатные) — ось доступа даже при разовом чтении; разовое чтение нечувствительного — ступень 2 (батч ENTERPRISE + раннер-EPF, без публикации и без отладочного расширения); повторяемый и интерактивный доступ — по references/data-access-verification.md (автономный сервер, обязательные поправки на кодировку кириллицы, диагностика по коду ответа); не копируй рецепт к себе, он будет расходиться версией. 1c-expert расследует ПОЧЕМУ медленно/падает/не масштабируется на живой нагрузке (ТЖ, планы запросов, блокировки) — это отдельный вопрос от «работает ли функционально», хотя ступень 2 (batch smoke) иногда всплывает в обоих: если смоук висит не из-за защиты/блокировки базы, а из-за реальной деградации — это уже задача 1c-expert, не тестировщика. 1c-analyst разбирает ЧТЗ/требования ДО того, как есть код для проверки.

Безопасность

Учётки ИБ, пароли SSH-хостов — только в env/.env, никогда в чат/коммит/лог прогона (маска пароля в командной строке — обязательна, см. mask_password в раннере). Данные из проверок на живых базах (значения полей, представления объектов) могут содержать ПДн — обезличивай перед тем, как класть в отчёт или показывать вовне.