1С:Предприятие — регресс обновлений без таблиц в почте

Что обычно болит

Обновление конфигурации выкатывают раз в месяц, а иногда и чаще: платформа, релиз типового решения, свои доработки. Проверять после каждого приходится одно и то же — закрытие месяца, обмен, печатные формы, права. В большинстве команд этот регресс живёт в файле Excel, который ведёт один человек, и о котором никто не помнит, пока не сломается расчёт зарплаты на проде.

Отдельная беда — формулировка дефекта. «Не проводится документ» без релиза платформы, релиза конфигурации и базы, на которой это воспроизвелось, стоит разработчику одного дня переписки.

Что даёт QA Деск

Готовые чек-листы вместо чистого листа. В каталоге лежат разобранные пакеты кейсов под типовые конфигурации: 1С:ERP 2.5, 1С:Бухгалтерия 3.0, 1С:ЗУП 3.1. Их можно прочитать на сайте целиком, а в проект добавить из каталога и дальше править под свою доработанную конфигурацию — это ваши кейсы, а не защищённый от изменений шаблон.

Релиз — поле, а не текст в описании. Окружение, платформа и сборка у дефекта отдельные поля. Значит, можно отобрать всё, что упало на конкретном релизе конфигурации, и увидеть, что после обновления 2.5.15 → 2.5.16 сломалось три вещи, а не «кажется, стало хуже».

Один реестр на весь портфель. Если кроме 1С у команды есть портал на Битрикс24 и сайт, они живут в тех же проектах, с общими метриками. Отдельный инструмент «только под 1С» не нужен, а руководитель видит качество релиза целиком.

Дефект из упавшего шага прогона. Тестировщик идёт по чек-листу в прогоне; на шаге, который не прошёл, заводится дефект — шаги воспроизведения и наблюдение переносятся из кейса, не набираются заново.

Веб-клиент: обычный браузер, обычные автотесты

Веб-клиент 1С — это интерфейс в браузере, и автотесты для него пишутся так же, как для любого веб-приложения: Playwright, Selenium, что уже принято в команде. QA Деск не запускает тесты и не диктует раннер — он принимает результат.

Пометьте тест ключом кейса, и его результат ляжет в ту же строку покрытия, где стоит ручная проверка:

// Playwright: ключ кейса прямо в имени теста
test('QAD-C41 проведение реализации из заказа клиента', async ({ page }) => {
  // ...
});

Тонкий и толстый клиент: Vanessa Automation

Сценарии на Gherkin, которые Vanessa Automation прогоняет в вашем CI, отдают отчёт в формате JUnit XML или Allure. Дальше — тот же приём, что для веба: qadesk-cli из шага пайплайна или один HTTP-запрос.

# шаг после прогона Vanessa Automation
QADESK_TOKEN=qdit_… qadesk-cli upload --run "ERP регресс" --env stage ./build/allure

Ключ кейса берётся из явной разметки: property с именем qadesk.case в JUnit XML или label qadesk_case в Allure; если разметки нет — из имени сценария. Тесты, у которых ключа не нашлось, не записываются молча: утилита печатает их поимённо с причиной. Подробнее — на страницах JUnit XML и Allure.

Чего в продукте нет

Честно, чтобы не тратить ваше время:

• QA Деск не запускает сценарии 1С и не ходит в базу — он принимает отчёты из вашего CI и хранит результаты;
• прямой интеграции с хранилищем конфигураций и с Git-конвертером нет; связь с задачей разработки делается через SourceCraft или Битрикс24;
• разбора логов технологического журнала нет и не планируется — это задача мониторинга.

С чего начать

1. Заведите проект и добавьте пакет кейсов под свою конфигурацию из каталога.
2. Пройдите первый ручной прогон на тестовой базе — так вы увидите, какие кейсы вообще неприменимы к вашей доработке, и вычистите их.
3. Если сценарии Vanessa Automation уже есть — добавьте в пайплайн шаг выгрузки отчёта и проставьте ключи кейсов у первых десяти сценариев.
4. Регламент, по которому это ставится на поток, разобран в статье регламент тестирования обновления 1С.

Рядом по теме

Платформы

1С-Битрикс

Сайт на 1С-Битрикс проверяется по готовому смоуку каталога и заказа, обновление ядра фиксируется в поле сборки, а ошибки прода из Sentry становятся дефектами без ручного пересказа стек-трейса.

1С-Битрикс — обновление ядра без сюрпризов на проде Автотесты, CI и мониторинг

Playwright

Playwright пишет отчёт, QA Деск делает из него прогон: ключ кейса связывает автотест с ручной проверкой, повтор задания не плодит дубли, а упавший сценарий превращается в дефект.

Playwright — сценарии в браузере, результат в покрытии Автотесты, CI и мониторинг

Allure

Каталог allure-results уезжает в QA Деск одним шагом. Отличие от отчёта-артефакта в том, что прогон остаётся: с историей, покрытием вместе с ручными кейсами и дефектами из упавших шагов.

Allure — результаты, которые не пропадают вместе со сборкой