Начните с ожидаемого результата

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

Требование желательно связать с документом или согласованным сообщением. Если условие звучит как «сделать удобный отчёт», сначала уточняют состав колонок, отборы, период и контрольные значения. Техническая проверка не может самостоятельно превратить неоговорённое пожелание в обязательный критерий.

Зафиксируйте конфигурацию и тестовый контур

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

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

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

Сочетайте технические проверки и бизнес-сценарии

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

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

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

Чек-лист приёмки

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

Условный пример: скидка с ограничением

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

В протоколе нужны исходные строки документа, параметры скидки, действия после возврата и ожидаемая сумма. Сообщение «скидки иногда ломаются» не позволяет повторить проверку. Если сценарий возврата не обсуждался, это отдельно отражают и уточняют критерий; сам факт отсутствия пункта не объясняет техническое поведение.

Где заканчивается такая проверка

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