Когда проект небольшой, а релизы выходят редко, тестирование чаще всего строится интуитивно. Что-то проверили, что-то упустили — в худшем случае исправили по факту. Такой подход может работать годами, пока система не начинает расти.
Привет! Меня зовут Иван, я руководитель направления технической архитектуры. Наша команда занимается занимается внедрением и развитием программного продукта 1С:ЗУП. В нашем случае рост проекта привел к устойчивой проблеме: релизы проходили тестирование, но уже после установки на продуктив появлялись ошибки, критические для бизнес-процессов. Частота post-deploy инцидентов росла, что снижала доверие пользователей, а команда все чаще работала в режиме реагирования, вместо плановой разработки.
Этот материал вырос из нашего доклада на Infostart Tech Event в прошлом году. Здесь я подробно разберу, как мы перестраивали процесс тестирования релизов в крупном проекте 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 объектов
Отказались от некоторых этапов ручного тестирования при выпуске релизов
Сократили количество сервисных обращений
Жизненный цикл, от сборки до установки на прод, релиза сократился с 4-х недель до 2-х
Автоматизированы проверки отчетов, которые раньше требовали значительного ручного времени, а сейчас в системе 150 отчетов проверяется за 30 минут
Существенно снизилось количество post-deploy дефектов
Дополнительным эффектом стала вовлеченность команды: специалисты, ранее не задействованные в тестировании, начали активно участвовать в развитии автотестов и процессов качества. Также, как и любая автоматизация, это позволило исключить человеческий фактор и позволяет обнаруживать дефекты на более ранних стадиях разработки, что в целом повышает качество продукта.
Процесс тестирования релизов нельзя рассматривать как проект с конечной точкой. Нет цели полностью отказаться от ручного тестирования или привязаться к конкретному набору инструментов. Важно выстраивать сбалансированный процесс, который учитывает масштаб проекта, риски и возможности команды.
В этом смысле тестирование действительно похоже на путь: без финальной цели, но с постоянным движением вперед.
