Каждый разработчик и руководитель проектов в сфере 1С рано или поздно сталкивается с классической «болью»: задача выполнена, первичное программирование завершено, код передан пользователям на тестирование — и процесс зависает на недели, а то и месяцы. Пользователи ссылаются на занятость, «забивают» на проверку, а в это время в хранилище конфигурации висят заблокированные объекты, показатели KPI программиста падают, а бизнес выражает недовольство тем, что задачи долго не выходят в промышленную эксплуатацию.
В этой статье мы подробно разберем, как выйти из этого замкнутого круга. Мы проанализируем ситуацию с разных сторон: внедрим организационные регламенты, рассмотрим технические способы изоляции кода, чтобы «зависшие» задачи не мешали дальнейшей разработке, и разберем инструменты автоматизации тестирования в среде 1С.
---
Как показывает практика, большинство подобных проблем лежит вовсе не в технической плоскости, а в организационной. Если у пользователей нет четко обозначенной ответственности и жестких дедлайнов, тестирование всегда будет откладываться по остаточному принципу. Разберем по шагам, какие правила необходимо зафиксировать на уровне руководства компании:
Рассмотрим пример правильного шаблона уведомления, которое программист должен отправлять пользователю при сдаче задачи:
Шаблон уведомления:
«Добрый день! Задача №12345 "Доработка печатной формы ТОРГ-12" подготовлена и выгружена на тестовую базу. Просьба протестировать функционал в соответствии со сценарием. Срок тестирования — до 18:00 (дата через 3 дня). Если до указанного времени замечания не будут предоставлены, задача будет автоматически закрыта и перенесена в рабочую базу в ближайшем релизе. Обращаем внимание, что отсутствие обратной связи расценивается как подтверждение корректности работы алгоритма».
---
Очень часто затягивание тестирования пользователями парализует работу отдела разработки. Например, программист изменил общий модуль или документ, объект «захвачен» в Хранилище 1С, и пока пользователь не проверит задачу, этот объект невозможно использовать для других доработок. Выясним, как современные технологии разработки позволяют решить эту проблему.
Переход на Git и EDT (Enterprise Development Tools)
Если вы до сих пор используете классическое Хранилище 1С, то любая зависшая задача действительно блокирует разработку. Мы рекомендуем рассмотреть переход на современные распределенные системы контроля версий (Git). При работе в Git каждый разработчик трудится в изолированной ветке (feature-branch). Даже если одна задача «зависла» у пользователя на три месяца, код этой ветки никак не мешает другим программистам изменять те же самые объекты метаданных в своих ветках. Слияние (merge) произойдет только тогда, когда задача будет полностью принята.
Использование расширений конфигурации (Extensions)
Для изоляции нового функционала активно используйте механизм расширений. Создавайте новую доработку в отдельном расширении конфигурации. Это позволит тестировать новый код, не внося изменения в основную конфигурацию и не блокируя общие объекты для других разработчиков.
Применение функциональных опций (Feature Toggles)
Если задачу необходимо перенести в рабочую базу, но пользователь еще не закончил полноценное тестирование под нагрузкой, используйте механизм констант или функциональных опций. Рассмотрим пример реализации:
// Внедряем проверку функциональной опции перед выполнением нового алгоритма
Если ПолучитьФункциональнуюОпцию("ИспользоватьНовыйРасчетСебестоимости") Тогда
// Новый алгоритм, который находится на стадии опытной эксплуатации
ВыполнитьНовыйРасчетСебестоимости();
Иначе
// Старый проверенный алгоритм
ВыполнитьСтарыйРасчетСебестоимости();
КонецЕсли;
Таким образом, мы можем спокойно перенести код в рабочую базу (релиз не задерживается), включить константу только для конкретного пользователя-тестировщика и позволить ему проводить проверку на реальных данных, не мешая остальным сотрудникам компании.
---
Часто пользователи затягивают процесс просто потому, что ручное тестирование — это монотонный и скучный процесс. Чтобы облегчить им жизнь и повысить качество кода, внедрим автоматическое тестирование на стороне разработки.
Проанализируем основные инструменты для автоматизации тестирования в среде 1С:
Перед передачей задачи пользователю обязательно выполняйте простейшее дымовое тестирование (Smoke testing) — автоматическое открытие всех форм документов и отчетов на предмет синтаксических ошибок. Пользователь не должен тратить время на то, чтобы сообщать вам о банальной опечатке, из-за которой форма просто не открывается при нажатии на кнопку.
---
Посмотрим на ситуацию глазами пользователя: ему присылают сухой текст задачи и ссылку на базу, где он должен сам вспомнить, какую цепочку документов создать, какие реквизиты заполнить и куда нажать. Неудивительно, что он откладывает это на потом. Сделайте процесс приемки максимально простым.
---
Для успешного решения проблемы затягивания тестирования мы должны действовать комплексно. Административный регламент со сроком 3-5 дней и правилом автоматического закрытия задач — это фундамент, который дисциплинирует бизнес-заказчиков. Переход на Git, расширения и функциональные опции избавит разработчиков от проблемы заблокированных объектов в хранилище. А подготовка тест-кейсов, запись видео и автотесты сделают процесс взаимодействия легким и приятным для обеих сторон.