Автотесты 1С: автоматизация регрессионного тестирования без ошибок после релизов

Автотесты 1С — это сценарии, которые программа выполняет сама: открывает формы, создаёт и проводит документы, сверяет движения и остатки, проверяет обмены. Их главная задача — регрессионное тестирование, то есть проверка, что новая доработка или обновление не сломали то, что уже работало. Когда регресс перед релизом занимает дни, а ошибки всё равно находят пользователи, автоматизация тестирования переводит проверку из разряда «на что хватило времени» в «каждый раз, полностью и одинаково».

Ниже — для руководителя и ИТ-директора: когда ручное тестирование перестаёт справляться, какие инструменты есть для 1С, как посчитать окупаемость и с чего начать, чтобы получить результат в первые недели.

Почему ручной регресс в 1С перестаёт работать

Конфигурации 1С в компаниях редко остаются типовыми. Появляются доработки, обмены с сайтом и маркетплейсами, CRM, WMS, BI. Изменение в одном модуле затрагивает соседние: поправили расчёт скидки — изменилась себестоимость, поменяли проведение — поехал обмен.

Пока система небольшая, хватает проверки «руками». С ростом проявляются три проблемы:

• Объём проверок растёт быстрее команды. Каждая доработка добавляет сценарии, а люди и время перед релизом — нет.
• Проверяют только изменённое. На полный регресс нет времени, поэтому смотрят то, что меняли, а ломается часто соседнее.
• Человеческий фактор. Разные специалисты проверяют по-разному, шаги пропускаются, внимание падает на десятом повторе одного и того же сценария.

Итог знаком многим: релиз ставят в пятницу вечером, а в понедельник склад не может отгрузить, касса не пробивает, обмен с интернет-магазином стоит.

Чем ошибки после релиза обходятся бизнесу

Цена ошибки зависит от того, насколько глубоко 1С встроена в операционные процессы.

К прямым потерям добавляется скрытая стоимость: разработчики бросают плановые задачи и чинят прод, а исправления «на горячую» сами становятся источником новых ошибок.

Какие бывают автотесты 1С и инструменты

Для 1С сложилось два основных уровня тестов.

Сценарные (функциональные) тесты повторяют действия пользователя через интерфейс: открыть документ, заполнить, провести, проверить результат. Платформа 1С поддерживает такой режим штатно — одна сессия управляет другой как клиент тестирования. На этом построены популярные инструменты:

• Vanessa Automation — открытый инструмент, сценарии пишутся на языке Gherkin, в том числе по-русски, поэтому их может читать аналитик и даже заказчик;
• 1С:Сценарное тестирование — инструмент фирмы «1С» для записи и воспроизведения сценариев.

Модульные тесты проверяют отдельные алгоритмы кода без интерфейса: расчёт цены, распределение затрат, формирование движений. Для них используют, например, YAxUnit — фреймворк, тесты в котором оформляются расширением конфигурации.

Упрощённый пример сценария в стиле Gherkin, чтобы было понятно, как это выглядит:

Функционал: Отгрузка товара со склада

Сценарий: Проведение реализации уменьшает остаток
  Дано на складе «Основной» остаток товара «Кабель ВВГ 3х2.5» 100 м
  Когда я создаю реализацию на 30 м и провожу её
  Тогда остаток товара «Кабель ВВГ 3х2.5» на складе «Основной» равен 70 м

Реальные шаги в инструменте формулируются по его библиотеке шагов, но смысл тот же: сценарий описывает бизнес-правило и проверяет его каждый раз одинаково.

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

Как посчитать окупаемость автотестов

Руководителю важна экономика. Её удобно считать из двух составляющих.

1. Трудозатраты на ручной регресс. Формула простая:

часы регресса в год = часы на один регресс × число релизов в месяц × 12.

Допустим, регресс занимает 16 часов, релизы выходят дважды в месяц: 16 × 2 × 12 = 384 часа в год только на повторяющиеся проверки. Автотесты не обнуляют эту цифру — нужно поддерживать сценарии и разбирать падения, — но основную часть проверок забирают.

2. Потери от ошибок в рабочей базе. Оцените, сколько часов простоя и ручных исправлений было за прошлый год после релизов, и умножьте на стоимость часа простоя для вашего бизнеса. Эту цифру обычно недооценивают, а в производстве и рознице она часто больше первой.

Против экономии ставятся затраты: настройка инструментов и стенда, написание первых сценариев, обучение команды, поддержка тестов. Срок окупаемости = затраты / годовая экономия. Подставьте свои числа — универсальных процентов здесь нет, всё зависит от частоты релизов и цены ошибки. Ориентир для оценки трудозатрат по моей работе — 2 500 ₽/ч.

Признаки, что пора внедрять автотесты

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

Если совпали два-три пункта, ручной регресс уже стал узким местом, и каждый следующий релиз только увеличивает риск.

Как внедрить автотесты 1С: план на первые месяцы

Начинать с цели «покрыть всё» — верный способ ничего не получить. Рабочий порядок такой.

1. Выбрать 5–10 критичных сценариев. Те, поломка которых стоит дороже всего: продажа и отгрузка, поступление, оплата, закрытие месяца, ключевой обмен.
2. Подготовить тестовую базу. Стабильный набор данных, который разворачивается заново перед каждым прогоном. Без этого тесты будут падать из-за данных, а не из-за ошибок.
3. Написать первые сценарии и прогнать их вручную. Убедиться, что они стабильны и действительно ловят ошибки.
4. Встроить в процесс выпуска. Тесты запускаются автоматически при сборке релиза или на ночном стенде — это уже элемент DevOps для 1С.
5. Наращивать покрытие. Правило: каждая найденная ошибка получает свой тест, каждая новая доработка — свои сценарии.

Кто пишет и поддерживает тесты

Частый вопрос руководителя — нужен ли отдельный штат. Для старта — нет. Сценарии ключевых процессов формулирует аналитик или ключевой пользователь, который знает, как должно работать: какие документы, какие данные, какой результат считается правильным. Технически оформляет и встраивает их в процесс разработчик или специалист по тестированию.

Важно распределить ответственность сразу:

• кто решает, какие сценарии критичны и в каком порядке их автоматизировать;
• кто разбирает упавшие тесты после ночного прогона и отделяет ошибку в системе от ошибки в тесте;
• кто обновляет сценарии, когда меняется бизнес-процесс.

Поддержка тестов — постоянная, но небольшая работа. Если её не закладывать, набор тестов устаревает и перестаёт приносить пользу.

Типичные ошибки

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

Отдельный плюс — спокойные обновления. С набором автотестов обновление 1С проверяется прогоном тестов на копии, а не неделей ручных проверок. Подробнее о подходе — на странице тестирования 1С.

Итог

• Автотесты 1С нужны для регрессионного тестирования: убедиться, что изменения не сломали работающие процессы.
• Ручной регресс перестаёт справляться, когда растёт число доработок, интеграций и релизов.
• Используют сценарные тесты (Vanessa Automation, 1С:Сценарное тестирование) и модульные (например, YAxUnit), лучше в сочетании.
• Окупаемость считается из сэкономленных часов регресса и снижения потерь от ошибок — по вашим цифрам, а не по чужим процентам.
• Начинайте с нескольких критичных сценариев, стабильной тестовой базы и встраивания тестов в выпуск релизов.