В этой статье я расскажу, как мы перестраивали процесс тестирования релизов в крупном проекте 1С:ЗУП: с чего начали, какие проблемы выявили, почему не стали сразу автоматизировать все подряд и к какому результату в итоге пришли.
Масштаб проекта и статистика
Наша команда занимается внедрением, тиражированием и развитием программного продукта 1С:ЗУП. На поддержке находится порядка 90 клиентов. Решение реализовано в четырех базах, работающих в модели сервиса. Средний объем одной базы составляет около 250 ГБ. В качестве СУБД используется Postgres PRO. Совокупно системой пользуются порядка 2,5 тысяч уникальных пользователей.
Команда проекта насчитывает около 100 человек: разработчики, аналитики, консультанты, сервис-менеджеры, функциональные и технические архитекторы, специалисты по тестированию. Команда большая и распределенная, представлена в 12 регионах, крупнейшие из которых – Москва, Санкт-Петербург, Омск и Екатеринбург.
В среднем мы выпускаем около 13 релизов в год. В это число входят релизы, синхронизированные с вендором, а также обязательное обновление редакции. На текущий момент в проекте реализовано более 1600 доработок, каждая из которых полностью документирована.
Как мы выпускаем релиз
Выпуск релиза устроен по типовой схеме, но с одним важным нюансом.
Релиз начинается со сборки фича-ветки с доработками. Параллельно готовится описание релиза и инструкции по настройкам, если они требуются. Далее ветка проходит обязательную техническую проверку, после чего релиз разворачивается на тестовых базах. После стабилизации – установка на продуктив.
Ничего экзотического. Но дальше начинается самое интересное.
Ветвление релиза
Мы работаем через EDT и Git, поэтому релизная модель построена вокруг веток. Сначала создается фича-ветка от основной. После первичной проверки от нее ответвляется ветка Bugfix – именно в ней происходит стабилизация релиза.
Ключевой момент: если в Bugfix находим дефект, исправление сразу через pull request уходит в Develop. В итоге все найденные на этапе релиза ошибки автоматически попадают в основную линию разработки. Это избавляет от дублирования багов и ситуации, когда новая функциональность строится поверх уже известных проблем. Новая разработка стартует на «чистой» ветке, без повторного наступания на те же грабли. Это является существенным плюсом.
Проблемы и постановка вопросов для оптимизации тестирования
Процесс тестирования релизов в компании был выделен и формализован давно. Команда осознанно подходила к проверке изменений: существовали регламенты, роли и базовые практики тестирования. Этот подход долгое время позволял поддерживать стабильность релизов.
Однако по мере роста системы и увеличения количества доработок начали проявляться ограничения существующего процесса. Объем функциональности увеличивался, релизы становились сложнее, и часть дефектов обнаруживалась уже после установки на продуктив.
Это были не единичные ошибки, а сигнал о том, что процесс тестирования требует пересмотра и систематизации. Команда начала последовательно разбирать слабые места: уточнять объем тестирования, формализовывать сценарии и устранять обнаруженные организационные огрехи.
Для решения проблем мы приступили к систематизации процесса тестирования. В начале пути были сформулированы следующие вопросы:
-
Что тестировать?
-
Как тестирование?
-
Кто тестирует?
-
Как управлять процессом?
-
Можно ли автоматизировать рутинные операции в этом процессе?
Если вы только начинаете свой путь в тестировании, рекомендую задать себе и команде эти вопросы. Это позволит сформировать планы действий и развития, а также упорядочить процессы. Разберем наши ответы на каждый вопрос и выводы, к которым мы пришли.
Что тестировать?
Раньше перед релизом регулярно возникал вопрос: что именно тестировать. С ростом системы стало очевидно, что проверять «все подряд» невозможно – и организационно, и экономически.
Поэтому первым шагом стало определение объема тестирования. Мы зафиксировали перечень объектов конфигурации, вошедших в релиз: доработки, изменения и сервисные обращения. По каждому объекту указывается статус тестирования и комментарий.
Но ключевым моментом стало другое – приоритизация функционала.
В системе 1С:ЗУП большое количество бизнес-критичных процессов: кадровые операции, расчет заработной платы, учет рабочего времени, отчетность. Именно эти процессы имеют наибольшие риски для бизнеса при ошибках.
Поэтому команда приняла практическое решение: покрывать тестированием в первую очередь критичные для бизнеса функции, а не стремиться проверять всю систему целиком.
Это позволило сосредоточить усилия на наиболее значимых сценариях и избежать ситуации, когда тестирование превращается в дорогостоящий и трудноуправляемый процесс.
Файл с перечнем объектов тестирования хранится в облаке и доступен всей команде. Специалисты в режиме онлайн отмечают статус проверки и оставляют комментарии. Это позволило видеть картину тестирования релиза целиком и управлять загрузкой команды.
Как тестировать?
Следующий вопрос – как именно тестировать объект. Для этого мы подготовили чек-листы по каждому ключевому элементу конфигурации.
В чек-лист входят: объект тестирования, необходимые предварительные настройки, профиль пользователя, пошаговый сценарий и ожидаемый результат. Это позволило уйти от импровизации и сделать тестирование воспроизводимым.
Позже эти чек-листы легли в основу сценариев автотестирования.
Баг-репорты
Важной частью тестирования является качественный баг-репорт. В процессе тестирования релизов сформировали оптимальный шаблон для нашей команды.
Баг-репорт содержит ссылку на конкретный объект в базе, профиль пользователя, под которым воспроизводится ошибка, и указание контура, так как баз используется несколько. Обязательно фиксируются шаги воспроизведения и прикладываются скриншоты.
Баг-репорт в таком формате можно передать любому разработчику или аналитику без дополнительных пояснений. Он составлен максимально подробно, и чем больше информации в нем содержится, тем меньше времени специалист тратит на устранение ошибки.
Как управлять?
Чтобы разграничить роли и снизить хаос на финише, мы зафиксировали график релизов и заранее определяем релизную команду под каждый выпуск. Состав утверждается перед стартом релиза.
Ключевая роль в этом процессе – менеджер релиза. Он координирует команду и отвечает за итоговый выпуск. Менеджер видит процесс целиком и принимает решения в спорных и нестандартных ситуациях.
Например, если в конце тестирования обнаруживается критическая ошибка, а хотфикс технически невозможен и изменения могут попасть в систему только через релиз, именно менеджер релиза организует включение доработки в текущий выпуск: согласует корректировки описания, контролирует внесение изменений и повторное тестирование.
Так ответственность не размывается, а релиз остается управляемым даже в сложных сценариях.
Переход к автоматизации и автотестированию
Процесс тестирования был выстроен и работал стабильно, однако сохранялось ощущение, что его можно сделать намного быстрее и надежнее. Возникла идея внедрить автоматизацию.
После оценки возможности команды и методов других команд приняли решение запустить проект автотестирования с использованием Vanessa Automation.
Перед стартом вновь ответили на основные вопросы: что именно автоматизировать, какие инструменты выбрать, как организовать инфраструктуру, можно ли использовать существующие чек-листы и какую архитектуру тестов заложить.
Перед проектом поставили следующие цели: улучшить качество выпускаемых релизов, сократить сроки тестирования и трудозатраты, уменьшить число критических инцидентов и сервисных обращений, а также повысить NPS.
QA-Команда
Наиболее сложной задачей стал начальный этап: требовалось не только подобрать инструмент, но и определить процесс и распределить роли. В итоге пришли к простой модели:
-
QA-инженер в роли менеджера тестирования – он отвечает за весь процесс и управляет работой команды,
-
разработчик – техническая составляющая,
-
аналитик – функциональная логика.
Тесты пишут не «отдельные тестировщики», а вся команда. Это исключает ограничение процесса одной ролью. Часто возникает вопрос: кто лучше пишет сценарии – аналитик или разработчик? Рассмотрим два примера.
Разработчик сталкивается с отсутствием понимания, что именно проверять. Аналитик объясняет логику работы объекта.
Аналитик понимает, что нужно протестировать, но не знает, как это сделать технически. Разработчик помогает с реализацией сценария: выбором шагов, организацией циклов и обработкой ошибок.
Роли дополняют друг друга, ускоряя процесс тестирования.
Инструменты
Перед стартом проекта мы рассматривали несколько вариантов и подходов для автоматизации. Основными критериями выбора были: минимальное количество внешних зависимостей, удобство написания и отладки тестов, скорость выполнения и возможность интеграции в ALM-контур.
В результате выбрали подход, сочетающий дымовые и сценарные тесты.
Первой попыткой внедрения автоматизации стал запуск дымовых тестов с помощью Vanessa-ADD. Технически запуск состоялся, однако в процессе эксплуатации выявились существенные сложности:
-
большое количество внешних обработок;
-
усложненная схема подключения;
-
трудоемкость написания тестов;
-
сложности с отладкой и сопровождением.
В итоге поддержка такого решения требовала избыточных усилий, а скорость развития набора тестов оказалась ниже ожидаемой. Мы приняли решение отказаться от Vanessa-ADD в качестве основного инструмента.
После перешли на тест работы YaxUnit. Инструмент показал себя простым и удобным в использовании: все находится в одном расширении, высокая скорость работы, наличие документации и простота поддержки.
Vanessa Automation и СППР были заимствованы у коллег с соседнего проекта, где уже внедрялось автотестирование. Решили использовать их, но с измененным подходом, о котором речь пойдет ниже.
В условиях промышленной разработки без CI/CD уже невозможно выстраивать процесс. Во время миграции разработки на Git и EDT команда перешла в ALM-систему, решив использовать уже имеющиеся инструменты. Это решение обусловлено их стабильностью и способностью удовлетворять текущие потребности.
Дымовое тестирование
В дымовые тесты в YaxUnit вошли базовые проверки: открытие форм, запись справочников и документов, проверка макетов СКД, регламентные задания, роли и права. На текущий момент в системе выполняется порядка 26 тысяч таких тестов. Они запускаются ежедневно в ночное время через конвейер в ALM-системе и позволяют выявлять поверхностные ошибки еще до этапа сборки релиза.
Процесс запуска и анализа дымовых тестов выстроен следующим образом. В ALM-системе создан конвейер, который собирает расширение YaxUnit из репозитория, собирает ветку Develop основного проекта, разворачивает все на тестовой базе и запускает тестирование.
Запуск тестов выполняется ежедневно в ночное время и занимает 3 часа. Такой подход обеспечивает контроль и исправление поверхностных ошибок до начала этапа сборки релиза.
Сценарное тестирование
В рамках сценарного и функционального тестирования были определены ключевые задачи: выбор покрываемого функционала, базы для запуска тестов, организация тестовых данных и выстраивание инфраструктуры разработки и хранения тестов.
Полный охват системы автоматическими тестами для 1С:ЗУП практически нереализуем. Система содержит большое количество бизнес-процессов и сценариев использования, и попытка автоматизировать все проверки привела бы к резкому росту трудозатрат на разработку и поддержку тестов.
Поэтому мы использовали тот же принцип, который применяли на этапе ручного тестирования: в автотесты попадает прежде всего бизнес-критичный функционал.
Для объектов автотестирования использовались подготовленные чек-листы, которые были адаптированы для сценарного тестирования.
На текущий момент разработано около 300 сценариев. Чек-листы фактически стали техническим заданием для написания автотестов в Vanessa Automation: разработчик получает готовый сценарий и ожидаемый результат. Чек-лист можно передать разработчику и быть уверенным в результате.
Для работы с данными используем эталонную базу вендора с минимально необходимыми дополнениями. После выполнения тестов база просто разворачивается заново, очистка данных не требуется. Процесс занимает около трех минут.
Подход позволил сделать тесты простыми и атомарными, снизить риск фантомных ошибок практически до нуля и упростить разработку и отладку сценариев.
Monkey-testing
Чек-листы и сценарные тесты хорошо покрывают регламентированные бизнес-процессы, но пользователи часто отклоняются от них. Для проверки таких ситуаций мы внедрили monkey-тестирование.
Monkey-тест не преследует цель пройти конкретный сценарий. Он открывает форму, нажимает доступные кнопки, заполняет поля, вводит некорректные данные и проверяет реакцию системы.
Чтобы облегчить доступ к этому виду тестирования, решили использовать Vanessa Automation. В одном monkey-тесте на объект около 600 строк кода.
Такой подход позволил выявить ошибки, связанные с ролями, элементами форм и поведением системы после обновлений вендора – проблемы, которые сложно обнаружить при ручном тестировании.
СППР
Для хранения и разработки тестов была выбрана Система проектирования прикладных решений (СППР). Вокруг этой системы много обсуждений, поэтому остановимся на ней подробнее.
СППР включает в себя:
-
подсистему тестирования,
-
функционал заведения бизнес-процессов,
-
функциональную модель приложения.
Эта архитектура позволяет связывать тесты напрямую с бизнес-логикой и функциональными сценариями. Рассмотрим процесс разработки сценария.
Разработка сценария в СППР организована следующим образом:
-
Создание процесса. Процесс привязывается к бизнес-модели. Он структурирует тестирование на уровне процессов, соответствующих реальной бизнес-логике.
-
Этапы процесса (шаги). Каждый шаг – это конкретный сценарий, содержащий:
-
текст фичи;
-
профиль запуска;
-
базу данных для тестирования.
-
-
Интеграция с Vanessa. Через окно шага осуществляется запуск Vanessa. Здесь же:
-
задаются параметры теста;
-
подключаются макеты для сравнений;
-
хранятся движения и вложенные файлы сценариев.
-
Параметры фич, макеты и тестовые данные хранятся в рамках шагов процесса, что обеспечивает их централизованный доступ.
Для удобства интеграции с ALM-системой реализована функция выгрузки веток СППР в отдельный репозиторий. Это обеспечивает корректный запуск тестов и позволяет:
-
упорядочить тесты в соответствии с функциональной моделью,
-
избежать изолированного хранения в папках,
-
прослеживать структуру сценариев и подсценариев.
При изменении общего шага (например, создание элемента справочника «Сотрудники») правки вносятся один раз. Все связанные тесты автоматически обновляются.
СППР и визуализация: схема функции
Перед вами схема функции «Учет рабочего времени», созданная на основе стандартного скриншота из системы без дополнительных доработок. На схеме показаны все связанные функции: процесс начинается с работы с НСИ и завершается формированием печатных форм. Также отмечены исполнители функции – роли табельщика и специалиста по работе с персоналом.
Схема полностью интерактивна: при клике на элементы отображаются связи с другими функциями и бизнес-процессами. При выборе конкретного элемента открываются сценарии, из которых состоит процесс, а также видна структура сценариев и состав фич. Для аналитика это наглядное представление функциональной модели, формируемое автоматически системой при условии корректного описания бизнес-процессов.
Запуск тестов
В СППР создается ветка, которая затем выгружается в ALM-систему. Можно запускать несколько параллельных потоков – по умолчанию их четыре, при необходимости добавляются новые, которые выстраиваются в очередь. Тесты автоматически группируются по потокам, а параметры и макеты выгружаются вместе с веткой без дополнительной настройки – достаточно нажать кнопку выгрузки.
После этого в ALM запускается конвейер, который собирает ветку проекта, обновляет эталонную базу и формирует DT-файл для разработки и отладки. Затем обновляется база для тестирования, и запускаются тесты. Такой подход позволяет всегда работать с актуальной эталонной базой, а часть ошибок выявляется заранее, на еженедельных запусках, еще до сборки релиза. Это дает время актуализировать тесты, если, например, форма была изменена и сценарий перестал работать корректно.
Ошибки такого рода неизбежны, но важно обнаруживать их заранее, а не на этапе релизного тестирования. Запуск тестов в ALM может выполнить любой специалист по инструкции, процесс занимает минимальное время и не требует специальных действий.
Чуть подробнее про ALM-систему у нас
ALM-система активно используется вместе с инструментами автотестирования, создавая заметный синергетический эффект. Она управляет жизненным циклом приложения, автоматизируя процессы разработки от планирования до развертывания и тестирования. В системе применяются конвейеры на YAML и Python, поддерживаются триггеры запуска и хранение артефактов в форматах DT, CF, CFE и MXL, что охватывает все основные форматы 1С.
После миграции проекта в EDT и Git использование веток стало обязательным. Для каждого инструмента развернут отдельный репозиторий с исходным кодом, а все инструменты используются централизованно. Такой подход упрощает работу: есть единая точка доступа к актуальным версиям, возможность откатиться на рабочую версию и использовать ее для тестирования.
Дашборды в ALM-системе
Одним из ключевых преимуществ ALM-системы является возможность консолидации информации. По мере роста проекта увеличивалось количество тестов, конвейеров и запусков, и управлять всем этим через отдельные окна становилось неудобно. В результате были внедрены дашборды мониторинга.
В начале рабочего дня специалист открывает дашборд и видит:
-
Собрана ли ветка разработки,
-
Обновлена ли тестовая база,
-
Статус сценарных и дымовых тестов,
-
Ход анализа и исправления ошибок.
Результаты внедрения автоматизации
Автоматизация дала не ощущение «стало лучше», а вполне измеримый результат:
-
Ручное тестирование одного объекта занимало ~2 часа. Сейчас автотестами за час покрывается около 180 объектов.
-
Отказались от некоторых этапов ручного тестирования при выпуске релизов.
-
Сократили количество сервисных обращений.
-
Жизненный цикл (от сборки до установки на прод) релиза сократился с четырех до двух недель.
-
Автоматизированы проверки отчетов, которые раньше требовали значительного ручного времени. Сейчас в системе 150 отчетов проверяется за 30 минут.
-
Существенно снизилось количество post-deploy дефектов.
Дополнительным эффектом стала вовлеченность команды: специалисты, ранее не задействованные в тестировании, начали активно участвовать в развитии автотестов и процессов качества. Как и любая автоматизация, это позволило исключить человеческий фактор и позволяет обнаруживать дефекты на более ранних стадиях разработки, что в целом повышает качество продукта.
Процесс тестирования релизов нельзя рассматривать как проект с конечной точкой. Нет цели полностью отказаться от ручного тестирования или привязаться к конкретному набору инструментов. Важно выстраивать сбалансированный процесс, который учитывает масштаб проекта, риски и возможности команды.
В этом смысле тестирование действительно похоже на путь: без финальной цели, но с постоянным движением вперед.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт