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

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

Принцип: никогда не менять рабочую базу напрямую

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

Схема движения изменений:

1. Разработка — в базе программиста
2. Перенос в тестовую базу
3. Проверка по сценариям
4. Приёмка ответственным со стороны бизнеса
5. Перенос в рабочую базу в согласованное время
6. Контроль после переноса

Что проверять

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

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

Права доступа. Видят ли пользователи то, что должны, и не видят ли лишнего.

Обмены. Работают ли выгрузки и загрузки с сайтом, банком, ЭДО, другими базами.

Сценарии проверки

Сценарий — это пошаговое описание операции и ожидаемого результата. Например:

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

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

Тестирование обновлений

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

Автоматизированные тесты

Для 1С существуют инструменты автоматизированного тестирования: сценарные тесты, которые повторяют действия пользователя в интерфейсе, и модульные тесты, проверяющие отдельные функции кода. Есть как механизмы самой платформы, так и открытые инструменты сообщества. Автоматизация окупается, когда изменений много и регрессия регулярная. Для небольших баз с редкими доработками часто достаточно ручных сценариев, но описанных письменно.

Кто участвует

• Программист проверяет свою доработку перед передачей
• Тестировщик или аналитик прогоняет сценарии и фиксирует ошибки
• Ключевой пользователь принимает доработку с точки зрения бизнеса
• Администратор переносит изменения в рабочую базу и делает резервные копии

В небольших компаниях роли совмещаются, но важно, чтобы доработку проверял не только тот, кто её написал.

Как фиксировать ошибки

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

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

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