Подрядчик показывает новую обработку, отчёт или обмен. На подготовленном примере всё работает. После запуска появляются дубли, старые документы считаются иначе, обновление становится сложнее, а вопрос «что именно изменили» остаётся без ответа.
Приёмка нужна до переноса в рабочую базу. Она связывает обещанный деловой результат с конкретными сценариями, данными и ограничениями. Руководителю необязательно читать код, однако он должен получить проверяемый ответ о результате и рисках.
Ситуация простыми словами
Представьте новый лифт в работающем здании. Красивый подъём с первого на пятый этаж показывает, что кабина движется. Приёмка включает другие вопросы: что будет при перегрузе, как откроются двери при сбое, кто обслуживает оборудование и где лежит схема.
Доработка 1С тоже живёт среди существующих процессов. Она встречается со старыми данными, разными правами, обменами, обновлениями и действиями пользователей, которые разработчик мог не показать на демонстрации.
Что видит бизнес
Бизнес заказывает доработку ради конкретного изменения: сократить ручной ввод, исключить потерю заказа, ускорить отчёт, провести новый процесс. Приёмка начинается с этой цели. Если проверяется только наличие формы или кнопки, связь с исходной задачей теряется.
Критерий стоит формулировать через наблюдаемый результат. Например: документ из внешней системы появляется в 1С один раз, содержит обязательные реквизиты, а ошибка видна ответственному сотруднику. Такая формулировка понятна руководителю и превращается в технический сценарий.
Что проверяет специалист
Граница изменения
Какие объекты и расширения затронуты, что осталось типовым, какие системы зависят от нового поведения.
Сценарии
Обычная операция, пустые или неверные данные, повтор, отмена, большой объём и одновременная работа нескольких пользователей.
Эксплуатация
Журналы, сообщения об ошибках, права, расписание, мониторинг и действия ответственного при сбое.
Сопровождение
Исходный код, описание настроек, совместимость с обновлениями, порядок установки и возврата.
Код оценивают в контексте системы. Обращение к большой таблице может выглядеть коротким и создавать тяжёлый запрос. Новое регламентное задание может работать быстро на тесте и накладываться на рабочие обмены. Изменение типовой конфигурации увеличивает стоимость будущих обновлений.
Для интеграций проверяют уникальный идентификатор сообщения, повторную отправку, частичный ответ и журнал маршрута. Для отчётов — источник данных, отборы, права и контрольный расчёт. Для печатных форм — правила заполнения и поведение на старых документах.
Отдельный вопрос — данные, созданные предыдущей версией. Новая логика должна корректно читать их или иметь согласованный способ преобразования. Проверка только на свежем документе пропускает этот риск.
Как провести приёмку безопасно
- Записать деловую цель и границу задачи одним абзацем.
- Составить сценарии вместе с владельцем процесса и аналитиком.
- Подготовить обезличенные контрольные данные, включая ошибки и повторы.
- Зафиксировать исходные показатели времени и результата.
- Проверить установку, работу и возврат на тестовом контуре.
- Согласовать рабочее окно и наблюдение после выпуска.
У каждого сценария есть входные данные, действие и ожидаемый результат. Фраза «работает корректно» слишком широка. Полезная запись выглядит так: повторная отправка сохраняет один документ; журнал связывает обе попытки с одним идентификатором.
Если тестовая база отличается от рабочей, расхождения фиксируют до приёмки. Важные сценарии повторяют после выпуска в согласованном режиме. На период наблюдения назначается ответственный, который видит ошибки и знает порядок возврата.
Что должно остаться после приёмки
После работы остаются описание цели, перечень изменённых объектов, сценарии с результатами, инструкция установки, настройки, известные ограничения и порядок возврата. Для интеграций добавляется схема потока данных. Для сложных расчётов — контрольные примеры.
Руководитель получает короткий итог: цель достигнута или остались условия, которые мешают приёмке. Аналитик видит соответствие процессу. IT-команда понимает, как сопровождать решение и что проверять при следующем обновлении.
Если подрядчик не передаёт доказательства, независимая экспертиза может восстановить границу изменения по расширениям, журналам и сравнению конфигураций. Такой разбор полезен перед оплатой крупного этапа, сменой исполнителя или рискованным обновлением.
Переведём технический результат на язык бизнеса и соберём сценарии, по которым работу можно принять.
Обсудить вторую экспертизу