# 1c Tester > Тестировщик/QA для 1С:Предприятие (BSL) — определяет, КАКОЙ уровень проверки нужен для конкретного изменения, и проводит его до реального доказательства (вывод прогона, не ощущение). Используй всякий раз, когда нужно проверить доработку перед сдачей, решить «CheckConfig хватит или нужен смоук», написать модульный тест на YAxUnit или сценарий Vanessa Automation/Gherkin, проверить доступ к данным живой ИБ (OData/HTTP-сервис расширения) для отладки или для AI, разобрать, почему прогон завис или дал ложный результат, или ревьюишь чужой набор тестов на покрытие кейсов. Срабатывай даже без слов «тест/QA», если речь о том, как ДОКАЗАТЬ, что доработка работает, а не просто «должна». Железное правило: вердикт — только по файлу-результату/выводу прогона, а не по коду возврата или ощущению; факты о 1С — по реальному коду/платформе через MCP, не по памяти. Написание/правка самого BSL-кода — `1c-dev`; расследование ПРОИЗВОДИТЕЛЬНОСТИ (медленно/ зависает/масштабирование) — `1c-expert`; анализ требований до кода — `1c-analy - Skill: `vgtitov/1c-tester` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add vgtitov/1c-tester` - Raw SKILL.md: https://api.skillmd.com/api/skills/vgtitov/1c-tester/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: vgtitov (https://skillmd.com/u/vgtitov) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/vgtitov/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`. | Что утверждаешь | Ступень | |---|---| | «Код без синтаксических ошибок и анти-паттернов, СКД цела» | 0 — статика (BSL LS) | | «Расширение применяется к базе, метаданные валидны, компилируется во всех контекстах» | 1 — batch CheckConfig | | «Печатная форма/отчёт/API реально формируется на реальных данных» | 2 — batch Enterprise smoke (runner-epf) | | «Пользователь это увидит и сможет нажать» (видимость, доступность команды) | 3 — UI-смоук веб-клиент/браузер | | «Регресс не сломан по всему контуру» / «модуль покрыт юнит-тестами» | 4 — фреймворк (Vanessa/YAxUnit/Тестер) | Отдельная ось — не «ведёт ли себя код правильно», а «что реально лежит в данных / что видит конкретный пользователь» (отладка 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` в раннере). Данные из проверок на живых базах (значения полей, представления объектов) могут содержать ПДн — обезличивай перед тем, как класть в отчёт или показывать вовне.