Обновили в пятницу — в понедельник склад не смог отгрузить: автотестирование 1С через Vanessa + AI

Кирилл ГуфайзенБизнес-аналитик 1С

23 сентября 2026 · 17 минут

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

Почему проверка руками перестаёт работать

Пока доработок пять, их держит в голове один человек. Когда их пятьдесят, начинается арифметика: обновили релиз — надо заново пройти все места, которые трогали за год. Это два-три дня работы аналитика, и не один раз, а при каждом обновлении.

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

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

Что делает тест, который нажимает кнопки

Есть инструмент, который заходит в 1С как обычный пользователь: открывает документ, жмёт кнопки, вводит значения, читает, что появилось на форме, и ругается, если выскочило окно с ошибкой. Называется Vanessa Automation, инструмент бесплатный и с открытым кодом, один из самых распространённых для такой работы. Стандартом в отрасли он не является: кто-то пишет свои обработки, кто-то не проверяет вовсе.

Простой сценарий пишется почти человеческим языком — это не код, который понимает один разработчик, а описание того, что делает человек:

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

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

Как это устроено у нас: минуты вместо дней

Технически это выглядит так: на нашей стороне поднимается служебная программа, которая и нажимает кнопки в вашей базе. Вот честные замеры, снятые на этой неделе.

Запуск — около сорока секунд. Это разово и на нашей стороне: дальше проверки идут одна за другой без пауз. Для вас это значит, что прогон можно ставить хоть перед каждым обновлением, а не выпрашивать окно у подрядчика.

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

По копии складской базы клиента — столько же. На копии 1С:УНФ мы гоняем документы складской цепочки: заказ покупателя, поступление от поставщика, перемещение между складами, отгрузка покупателю. Каждый сценарий открывает реальный документ базы, нажимает «Провести» и следит, чтобы не выскочило ни одного предупреждения. Тройка документов одного вида — меньше минуты. То есть проверить, что после обновления склад по-прежнему может отгрузить, стоит десять минут машинного времени и ноль часов кладовщика.

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

Где здесь AI и что он делает руками аналитика

Сам по себе инструмент кнопки нажимает, но сценарии кто-то должен написать. Это и есть та работа, из-за которой автотесты в 1С годами оставались историей для больших проектов: описать полсотни путей руками — месяцы аналитика. Сейчас черновик сценария пишет модель, а человек его проверяет и правит.

• Сценарии. Модель не выдумывает шаги: ей отдаётся библиотека шагов самой Vanessa Automation, и она собирает из них путь — открыть документ, заполнить реквизиты, провести, проверить движения. Аналитик читает результат обычными словами и говорит, где это не похоже на работу вашего кладовщика.
• Что покрывать первым. Модель разбирает историю изменений конфигурации и список доработок и предлагает порядок: что трогали чаще всего, что ближе к деньгам и отгрузке. Это заметно честнее, чем «давайте начнём с того, что вспомнили на планёрке».
• Разбор падения. Когда прогон покраснел, модель читает отчёт и говорит, на что это похоже: сценарий устарел вместе с доработкой, поменялась форма или дело в самих данных. Вывод всё равно подтверждает человек — но искать причину начинают не с нуля.

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

Кейс: вечер на копии складской базы и три разные находки

Копия базы автосервиса с оптовым складом запчастей: 1С:Управление нашей фирмой, свежий релиз, полсотни расширений сверху — и типовые патчи, и свои доработки. Обновление прошло, конфигуратор доволен, база открывается. Вопрос ровно тот, с которого начата статья: склад по-прежнему работает или уже нет.

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

Находка первая: шесть документов, которые не может провести никто

Зелёной оказалась вся ходовая часть — заказы, поступления, перемещения, отгрузки. Красными — все списания и оприходования запасов до единого. Картина странная: документы в базе числятся проведёнными, то есть когда-то провелись, а сейчас на кнопку «Провести» отвечают окном «Не удалось провести» и больше ничем.

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

Дальше выводов два, и оба рабочие. Сценарии по этим двум видам документов надо запускать под автором — поправка на один параметр. А сама проверка неожиданно превратилась в тест на права: если после очередного обновления чужое списание вдруг проведётся, это увидит прогон вечером, а не ревизия через полгода.

Находка вторая: расширение включено, а его нет

Это самое интересное, что мы достали за вечер, и заметить это руками почти невозможно.

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

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

22.09.2026 23:16:50  Предупреждение Расширение конфигурации не применено: критичная ошибка. Значение контролируемого свойства у объекта не совпадает со значением в расширяемой конфигурации.

Одна и та же запись, 1424 раза с 8 августа. Пользователю на экран она не выходит.

Находка третья: проверка, которая устарела вместе с доработкой

Тот же вечер, другой набор по той же базе. Сценарий открывает карточку нашей внешней обработки и сверяет версию: ждёт 1.0.0.1, а в базе стоит 1.0.0.4. Обработку обновляли, а строчку в проверке поправить забыли.

Красный сценарий здесь показал не поломку базы, а ровно то, чего боятся при разговоре про автотесты: проверки стареют вместе с доработками. Разница в том, что устаревание вылезло за 49 секунд и чинится одной строкой, а не выясняется через полгода на совещании.

Находка четвёртая: шум, в котором тонут настоящие ошибки

Пока гоняли документы, в журнал базы легли 73 предупреждения за сутки: типовой код при проведении складских документов ругается, что одно из служебных полей не заполнено заранее. Работать это не мешает, но такие записи идут постоянно, сотнями.

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

Что в итоге принёс вечер

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

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

Зелёный тест сам по себе ничего не доказывает

Это главное, чему мы научились, и это то место, где автотесты у большинства превращаются в декорацию.

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

Что такая проверка ловит, а что нет

Честная граница важнее громкого обещания, поэтому скажу прямо.

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

Ловит плохо или дорого: расчёты, у которых нет отражения на экране, обмены с сайтом и терминалами сбора данных, регламентные задания, тонкие места прав и ограничений на уровне записей, поведение под нагрузкой. Тут нужны другие проверки, и продавать под видом автотестов их нечестно.

И отдельно про ответственность. Прогон находит и показывает. Починка — это уже работа по доработке: чья именно и за чей счёт, зависит от того, чей код сломался. Зелёный отчёт не страховка от простоя, он снижает риск по тем путям, которые в него включены, и ровно настолько.

Честно: где это буксует

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

Говорю об этом, потому что в статьях про автоматизацию всё обычно гладко. Подрядчик, у которого «всё всегда работает с первого раза», просто не показывает вторую половину картины.

«Тесты устареют раньше, чем окупятся»

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

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

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

Пять сценариев, с которых стоит начинать

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

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

Что это даёт руководителю

Не «у нас есть автотесты», а три понятные вещи.

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

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

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

С чего начать

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

Мы в iTeal используем этот стенд на своей базе и на копиях баз клиентов. Если хотите посмотреть, как это выглядит на вашей конфигурации, напишите: подберём пять сценариев под ваши процессы и покажем прогон. Заодно посмотрите соседние материалы — про обновление доработанной 1С и про то, что показывает диагностика базы.

← 1С для руководителей понятным языком