Регламент тестирования обновления 1С: порядок, роли, чек-листы

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

Регламент нужен не для того, чтобы обновление стало дольше, а чтобы оно стало предсказуемым: заранее известно, кто что делает, что считается «проверено» и в какой момент можно трогать рабочую базу. Ниже — регламент, который мы применяем к доработанным базам; он опирается на три пакета тест-кейсов из Каталога QA Деск: 1С:Бухгалтерия 3.0, 1С:ЗУП 3.1 и 1С:ERP 2.5.

Определения

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

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

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

Приёмка — решение ответственного за учёт (главного бухгалтера, расчётчика, руководителя проекта) о том, что рабочую базу можно обновлять. Приёмка опирается на результат регресса, а не на слова «вроде всё нормально».

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

Роли

Регламент работает, когда у каждого шага есть один ответственный. В небольшой организации несколько ролей совмещает один человек — это нормально, важно, чтобы ни одна роль не осталась без владельца.

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

Регламент по шагам

Шаг 1. Подготовка

За день-два до окна обновления:

1. Прочитать описание релиза от вендора: изменения в учёте, новые обязательные реквизиты, изменённые регламентные операции. Всё, что касается доработанных участков, — записать как отдельные пункты проверки.
2. Составить перечень доработок базы: расширения, изменённые объекты конфигурации, внешние обработки и отчёты, правила обмена. Если перечня нет — это первая проблема, которую регламент выявляет; без него неизвестно, что проверять.
3. Собрать чек-лист: типовой пакет для конфигурации плюс пункты по доработкам и по описанию релиза.
4. Согласовать окно обновления и назначить ответственных по ролям.

Шаг 2. Копия базы

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

Шаг 3. Обновление копии

Установка релиза, запуск обработчиков обновления, подключение расширений. Здесь регламент требует зафиксировать три факта до начала регресса:

• обработчики обновления завершились без ошибок — журнал регистрации проверен, а не просто «база открылась»;
• номер версии конфигурации соответствует установленному релизу;
• все расширения подключены, активны и не выдают ошибок при запуске.

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

Шаг 4. Регресс

Тестировщик проходит чек-лист. Для 1С:Бухгалтерии типовой пакет — 24 тест-кейса: справочники, покупки и продажи с НДС, банк и касса, зарплата, основные средства, закрытие месяца, отчётность, обмены и печатные формы. Каждый кейс заканчивается ожидаемым результатом в проводках, движениях регистров или суммах отчёта — не «документ проведён», а «Дт 41 Кт 60 на сумму без НДС, Дт 19 Кт 60 на сумму НДС». Расхождение с ожиданием видно без бухгалтера-эксперта.

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

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

Шаг 5. Дефекты и повторный прогон

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

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

Шаг 6. Приёмка

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

Шаг 7. Обновление рабочей базы

В согласованное окно администратор повторяет шаг 3 на рабочей базе: резервная копия, релиз, обработчики, расширения, проверка журнала регистрации и версии. Затем тестировщик проходит короткий смоук — кейсы с критичным приоритетом из того же пакета, 20–30 минут: первый запуск, вход под типовым профилем, поступление, реализация, оплата, начисление зарплаты. Полный регресс на рабочей базе не повторяется — для этого была копия.

Шаг 8. Наблюдение

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

Особенности по конфигурациям

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

Типовые ошибки регламента

Обновление сразу на рабочей базе «потому что маленькая». Размер базы не влияет на количество доработок. Копия делается за минуты, откат из резервной копии после дня работы пользователей — за часы и с потерей данных.

Регресс под администратором. Администратор видит всё; бухгалтер с типовым профилем после обновления может не видеть новый раздел или, наоборот, увидеть лишнее. Прогон под типовым профилем находит это до пользователей.

Проверка «документ проведён». Проведение без ошибок — не результат. Результат — правильные проводки и суммы. Кейсы с ожиданием по проводкам находят изменение счёта учёта, кейсы с «проведён» — нет.

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

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

Пропущенное закрытие месяца. Самые дорогие дефекты обновления всплывают на закрытии, а тестовая база за две недели до конца месяца «ещё не готова закрываться». Закрытие месяца на копии проверяется всегда — на предыдущем месяце, если текущий не закрыт.

Чек-лист регламента

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

Как вести регламент в QA Деск

Регламент на бумаге живёт до второго обновления. Чтобы он работал, результаты каждого прогона должны накапливаться в одном месте. В QA Деск это устроено так: пакет для конфигурации добавляется из Каталога в проект один раз, кейсы по доработкам дописываются рядом в той же библиотеке. На каждое обновление создаётся тест-план из нужных кейсов, прогон стартует с конфигурацией среды — например, «копия, релиз 3.0.xxx», — и хранит её снимок. Тестировщик отмечает результат по каждому шагу, заводит дефект из упавшего шага, таймер по строке считает время прогона. Ответственный за учёт открывает сводный экран прогона и видит, сколько прошло, сколько упало и какие дефекты открыты, — это и есть материал для приёмки.

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