Сколько времени уйдёт на проверку и правку доработки в 1С

Тестирование и исправление ошибок в 1С обычно съедают от 30 до 50% времени всей доработки. Мелкую правку отчёта проверяют за пару часов, а обмен с внешней системой или перенос учёта в новую конфигурацию тестируют неделями. Единой цифры нет: срок складывается из размера изменения, качества постановки и скорости обратной связи от заказчика.

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

Сколько занимает проверка и правка: ориентиры по типам задач

Чтобы назвать срок, сначала определите класс задачи. Одна и та же кнопка «Провести» может быть мелочью или источником недели работы, если за ней стоит цепочка регистров.

Правило большого пальца: на несложных задачах проверка занимает 30–50% от времени разработки, на задачах с проведением и регистрами сравнивается с ней, а на интеграциях нередко превышает её. Если исполнитель закладывает на тесты 10%, ждите возврата на доработку.

Из чего состоит цикл: от найденной ошибки до закрытой задачи

Исправление ошибки — не одно действие, а цепочка. Время теряется не на самой правке, а на передачах между участниками.

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

Что должно быть в описании ошибки

Хорошее описание сокращает цикл на порядок. Минимум для разработчика:

1. Что делали: документ, пользователь, роль, время.
2. Что ожидали и что получили, дословный текст сообщения в кавычках.
3. Данные, на которых ошибка проявилась: номер документа, организация, период.
4. Повторяется ли ошибка всегда или иногда.
5. Скриншот окна с ошибкой целиком, вместе с кнопкой «Подробно».

Без пункта 3 разработчик сначала пытается воспроизвести ошибку на тестовой базе, где нужных данных нет. Это самая частая причина потерянного дня.

Что делает разработчик

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

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

От чего зависит длительность тестирования

Две одинаковые по размеру доработки проверяют за разное время. Причины обычно одни и те же.

• 🔗 Связность объектов. Документ, который пишет в десять регистров, надо проверять по каждому регистру и по отчётам над ними.
• 📦 Объём и качество тестовых данных. На пустой базе половина сценариев не воспроизводится. На копии рабочей базы уходит время на выгрузку, загрузку и обезличивание.
• 🧩 Типовая или нетиповая конфигурация. В измененной конфигурации каждое обновление релиза требует повторной проверки доработок.
• 👥 Число ролей и сценариев. Бухгалтер, кладовщик и руководитель видят разные формы и права. Проверка под одной ролью ничего не гарантирует для другой.
• 🔌 Внешние системы. Обмен зависит от чужих тестовых стендов, а их часто приходится ждать.
• ⏳ Скорость ответов заказчика. Вопрос без ответа два дня — это два дня простоя, которые не видны в трудозатратах.
• 📄 Постановка задачи. Когда критерии приёмки не записаны, «готово» каждый понимает по-своему, и тест превращается в переговоры.

Что почти всегда недооценивают

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

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

Чем автоматизировать отладку и проверки

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

С чего начать, если автоматизации ноль

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

Простой прогон такого набора на тестовой базе занимает 10–30 минут против нескольких часов ручной проверки. Окупается он уже после трёх-четырёх релизов.

Типовые ошибки и сколько уходит на их устранение

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

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

Как выстроить работу с заказчиком, чтобы не терять дни

Основные потери в цикле возникают на стыке «исполнитель — заказчик». Они не видны в часах разработчика, зато хорошо видны в календаре.

Критерии приёмки до начала работ

Перед стартом запишите проверяемые условия: «при проведении документа на сумму 100 000 рублей в регистре появляется движение на ту же сумму», «отчёт за январь совпадает с ручным расчётом на контрольной выборке». Такие формулировки закрывают споры о том, что значит «работает».

Одно окно для замечаний

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

Приоритеты

Не все ошибки равны. Договоритесь о трёх уровнях:

• 🔴 Критичная. Останавливает учёт или искажает данные. Реакция в тот же день.
• 🟠 Значимая. Есть обходной путь. Исправление в ближайшем релизе.
• 🟢 Косметическая. Неудобство без влияния на результат. Копится и исправляется пачкой.

Фиксированное окно на приёмку

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

Как сократить сроки без потери качества

Ускорение даёт не работа быстрее, а меньше возвратов. Вот приёмы, которые действительно работают.

1. Ранний показ. Покажите заказчику форму или прототип отчёта до полной готовности. Несовпадение ожиданий выявляется за час, а не после недели разработки.
2. Небольшие поставки. Мелкая доработка проверяется быстрее и проще, чем большая сборная. Если возможно, дробите задачу так, чтобы каждая часть приносила пользу сама по себе.
3. Тестовая база, близкая к боевой. Регулярно обновляйте копию данными рабочей базы. Часть ошибок исчезает только при условии, что тестируете на реальных объёмах.
4. Проверка перед передачей. Разработчик сам проходит основной сценарий и негативный, прежде чем отдать задачу на приёмку. Это занимает 15 минут и снимает до 30% возвратов.
5. Парная проверка. Второй человек читает код или прогоняет сценарий. Свежий взгляд находит то, что автор уже не замечает.
6. Контроль версий. Храните доработки в системе контроля версий (например, Git при работе через EDT или выгрузку в файлы). Откат неудачной правки занимает минуты, а не часы.
7. Автоматическая проверка конфигурации. Запускайте её при каждой сборке: синтаксические ошибки не должны доходить до тестировщика.

Что не работает

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

Частые вопросы