Автоматизация тестирования решений на 1С: Ожидания vs Реальность

Содержание

• Введение (обо мне и о докладе)
• Ожидания
  • Тестирование ПО в 1С строится по классическим канонам
  • В 1С можно использовать инструменты тестирования через GUI общего назначения
  • О классическом юнит-тестировании в мире 1С
  • Фирма 1С нам даст свои тесты и мы легко сможем проверять на регресс типовой функционал после наших доработок
  • Мы просто возьмем и запустим дымовые тесты (прямо из коробки)
  • Достаточно только начать писать тесты
  • Возьмем пустую базу и будем тесты запускать прямо в ней / возьмем копию прода и будем запускать тесты базы в копии
  • Мы просто покажем аналитику/консультанту/ручному тестировщику как пользоваться кнопконажималкой VA и он нам быстро напишет кучу тестов
• Заключение

Обо мне

Меня зовут Александр Кунташов, я работаю в ИТ-лаборатории компании Инфостарт, где мы с нашей дружной командой экспертов занимаемся вопросами автоматизации разработки на платформе 1С:Предприятие, внедрением DevOps-практик в командах 1С и, в том числе, автоматизацией тестирования.

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

Мой доклад будет посвящен высокоуровневым, но важным с точки зрения практики вопросам, с которыми сталкивается буквально каждая команда в процессе внедрения автоматизации тестирования для своих проектов.

По результатам общения с коллегами из нашей отрасли у меня накопился пул регулярно возникающих вопросов, корни которых – в недопонимании, мифологии и неправильных ожиданиях. Вокруг самых частых и острых из этих вопросов и будет построен мой доклад.

Я постарался выстроить эти вопросы в последовательности от более высокоуровневых к более конкретным и техническим. Эта же последовательность приблизительно соответствует хронологии возникновения этих вопросов, когда вы берётесь за внедрение автоматизации тестирования в своей команде.

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

Ожидание: Тестирование ПО в 1С строится по классическим канонам

Начнем с основ – во всех смыслах.

В тестировании широко применяется метафора «пирамида тестирования», которая наглядно демонстрирует рациональное или естественное соотношение между разными видами и уровнями тестов. В упрощенном виде классическая пирамида тестирования выглядит следующим образом:
 

В классических приложениях дешевле, проще и разумнее всего писать простые маленькие тесты для отдельных компонентов, из которых строится наша система. Преобладающее количество таких тестов символизирует широкое основание пирамиды.

Взаимодействие компонентов покрывается меньшим количеством интеграционных тестов. Это средняя часть пирамиды.

А проверка работоспособности всей системы на прикладном уровне проверяется с помощью end-to-end тестов, включая тестирование через пользовательский интерфейс (UI). Этому виду тестов на инфографике отведена вершина пирамиды.

Однако в мире 1С ситуация выглядит совсем по-другому, и пирамида тестирования у нас перевернутая:
 

Это не попытка пошутить. Давайте разберемся, почему так.

Юнит-тестов в проектах на 1С мало. Это связано и с особенностями подходов к 1С-разработке, и с техническими особенностями платформы и типовых решений.

Что касается подходов к 1С-разработке, то не секрет, что решения на платформе 1С:Предприятие 8 выросли из парадигмы, которая напоминает то, что сейчас называется low-code. Только во времена, когда это все начиналось, идея звучала в виде слогана «доступно и всерьез», но цель и там и там общая: дать возможность донастроить (кастомизировать) продукт под специфику бизнеса без сложной разработки.

Мы сейчас не будем оценивать, хорошо это или плохо с точки зрения решения задач – просто примем как данность. Но данность такова, что в решениях на платформе 1С мы сталкиваемся с рядом специфических факторов:

• высокая степень связности между «юнитами» системы – объектами метаданных, элементами интерфейса и модулями;

• тесное переплетение бизнес-логики, данных, системного кода;

• технические ограничения, затрудняющие изоляцию компонентов – что критично для классического юнит-тестирования;

• относительно медленный запуск среды при тестировании, тогда как юнит-тесты предполагают высокую скорость выполнения.

По этим причинам внедрить полноценное юнит-тестирование в системах на 1С объективно сложно. Инструментов, заточенных под этот вид тестирования, мало, и в целом термин «юнит-тестирование» в контексте 1С вызывает вопросы. Поэтому мы у себя в команде предпочитаем использовать более конкретное и нейтральное определение – «тестирование кодом».

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

Но еще более распространенным в мире 1С является тестирование «через интерфейс» (UI-тесты), потому что:

• есть инструменты на уровне платформы, а именно механизм автотестирования и механизм записи действий пользователя;

• такой подход практически не зависит от внутреннего устройства решения и того, готова ли его архитектура к автоматизированному тестированию: нет необходимости ради тестирования изолировать низкоуровневые компоненты системы. Вдвойне это актуально, когда речь идет об автоматизации тестирования систем с заметной долей унаследованного кода (легаси);

• можно получать результаты прогона автотестов в терминах бизнес-логики, т.е. на тесты можно смотреть как приемочные, и в целом возникает соблазнительная перспектива и даже возможность связать процессы анализа, моделирования, тестирования и начать применять подходы Behavior Driven Development (BDD, разработка через поведение) и test-first во весь рост. Этот подход в определенной степени может быть воплощен при использовании такого инструмента, как 1С:СППР, в котором «бэкэндом» используется Vanessa Automation.

Но за это, естественно, приходится платить: скоростью тестов, хрупкостью, повышенными требованиями к инфраструктуре тестирования. Тем не менее, указанные проблемы можно нивелировать, и далее я об этом расскажу.

Что делать?

Итого. В чистом виде классические промышленные подходы к тестированию для решений на платформе 1С не применимы и требуют адаптации, исходя из перечисленных выше особенностей.

Если говорить предметно, то для 1С в большинстве случаев более оправданна автоматизация тестирования через интерфейс: она лучше соответствует практическим целям внедрения автотестов, не требует глубокой переработки кода решения и может применяться даже в случае легаси-систем с высокой связностью.

Однако в случае разработки решений на платформе 1С:Предприятие 8 с нуля, при наличии в команде соответствующих компетенций и достаточно высокой культуры разработки, внедрить практики юнит-тестирования можно. Хотя, честно говоря, пока это звучит немного фантастически, и такие случаи можно пересчитать буквально «по пальцам».

Но появление, развитие и широкое обсуждение таких продуктов, как YAxUnit, показывает, что сообщество стремится или, по крайней мере, «лежит» в эту сторону.

Ожидание: В 1С можно использовать инструменты тестирования через GUI общего назначения

Итак, мы определились, что наиболее разумно начинать автоматизацию тестирования в 1С, применяя тестирование через пользовательский интерфейс. Возникает логичный вопрос: почему бы тогда не использовать популярные инструменты для автоматизации тестирования десктопных и веб приложений вроде TestComplete или Selenium для веб-клиента?

Увы, в случае с 1С такой подход в полной мере не сработает. Теоретически, конечно, можно попробовать, но на практике это будет долгий путь через боль и разочарование – и, скорее всего, без хэппиэнда.

Основная причина этого в том, что 1С:Предприятие 8 разработан как инструмент быстрой разработки кроссплатформенных приложений, который реализует свою собственную библиотеку для отрисовки пользовательского интерфейса. Например, в Windows платформа для отрисовки интерфейса использует не стандартные элементы управления, предоставляемые операционной системой, а средства чистого WinAPI (см., например «Платформа “1С: Предприятие” — что под капотом?», раздел «Пользовательский интерфейс»).

К тому же, на текущий момент у пользовательского интерфейса 1С:Предприятия четыре инкарнации:

• Обычный интерфейс

• Интерфейс управляемого приложения 8.2

• Интерфейс управляемого приложения «Такси»

• Интерфейс 8.5, который неофициально называют бездушным «воздушным»
   

Обычный интерфейс поддерживает классическую концепцию MDI-приложений, т.е. многодокументный интерфейс, характерный для традиционных десктопных приложений. Однако, чтобы обеспечить кроссплатформенность и поддержать некоторые нестандартные интерфейсные решения, разработчики платформы реализовали собственную библиотеку для построения форм и элементов управления. Как следствие, компоненты, из которых строится интерфейс, оказываются труднодоступными для универсальных инструментов тестирования, предназначенных для работы с типичными Windows- или Linux- интерфейсами.

Управляемый интерфейс — это новая концепция построения интерфейсов, которая сменила «обычное» приложение и продолжила развитие кроссплатформенности, благодаря чему единожды разработанное в конфигураторе приложение автоматически работает в тонком, толстом и веб-клиенте, под Windows, Linux и MacOS и выглядит одинаково.

Однако с точки зрения тестирования инструментами общего назначения ситуация не изменилась: оригинальная концепция UI по-прежнему реализована с нуля и сложнодоступна для тестирования средствами извне.

Зато в самой платформе появились встроенные инструменты, а именно: программное API механизмов тестирования платформы и механизм записи действий пользователя.
 

Поверх этих механизмов было реализовано несколько продвинутых фреймворков, среди них

• 1C:Сценарное тестирование (+ 1С:Тестировщик)

• Vanessa Automation и Vanessa-ADD

• Тестер

• Тестирование 3.0

Я не буду сейчас сравнивать эти фреймворки, это уже сделал однажды Виталий Онянов в своей публикации «100+ тестов на Vanessa Automation. Личный опыт без маркетинга» в разделе «Фреймворки тестирования в 1С».

Из всех указанных инструментов с большим отрывом по популярности лидирует Vanessa Automation (VA). Этот проект реализует возможность писать сценарии проверки поведения на языке Gherkin. А точнее, на его расширенном диалекте, названном TurboGherkin. Имеет открытый исходный код (open source) и предоставляется под свободной лицензией (BSD 3-Clause License).
 

В опросе сообщества Инфостарт, который проводился в 2022 году, среди всех названных инструментов VA была на третьем месте по популярности. Далее в докладе, кроме нескольких отдельных моментов, мы будем преимущественно говорить о тестировании в контексте использования VA как флагманского решения по тестированию.
 

Что делать?

Итак, как быть – какой инструмент или фреймворк тестирования выбрать?
 

Поскольку в интерфейсе 1С, который называется «обычным», встроенные в платформу механизмы тестирования не поддерживаются, то решения 1С на «обычных формах» мы тестируем либо «кодом», либо с помощью внешних инструментов, таких как SikuliX, которые идентифицируют область по совпадению картинки. Ну или тестируем вручную –на фоне технических сложностей это вполне может оказаться разумной альтернативой.

Управляемое приложение тестируем при помощи готовых фреймворков. В версии 8.2 работа механизма тестирования для некоторых кейсов имеет нюансы, но они не мешают полноценной автоматизации. В версии 8.3 — на сегодняшний день самой массовой – практически все хорошо. А что касается платформы 8.5, то из-за очередных изменений интерфейсных механизмов API тестирования под нее еще не адаптировано (на апрель 2025 года), ждем релиза.

С точки зрения популярности, доступности специалистов и богатства возможностей флагманом среди инструментов для тестирования интерфейса является Vanessa Automation. Если вы только планируете начать автоматизировать тестирование в 1С — в первую очередь имеет смысл обратить внимание именно на этот фреймворк. Инструмент активно развивается, у него большое сообщество, по нему есть и бесплатные, и платные курсы, например, у нас в Инфостарте. Сценарии Vanessa Automation совместимы с классическим Gherkin. А большая встроенная библиотека шагов значительно упрощает внедрение элементов BDD в процесс разработки – достаточно умения и желания.

Классическое юнит-тестирование

Прежде чем двигаться дальше, не могу не затронуть немного глубже тему юнит-тестов, которой я уже коснулся, но она требует еще немного внимания.
 

Несмотря на все особенности и ограничения, из-за которых юнит-тестирование в 1С-сообществе пока не получило широкого распространения, существует целый класс задач, которые логично и эффективно тестировать именно «кодом», а не через пользовательский интерфейс. Сюда относится, например, тестирование веб- и http-сервисов, регламентных заданий, алгоритмов, а также публичных интерфейсов общих модулей. Эти объекты можно и нужно тестировать именно кодом.

Да, время запуска (в том числе, холодного старта) у 1С-систем далеко от идеала — это не миллисекунды. Да, в легаси-проектах могут быть сложности из-за высокой связности кода и в принципе не подготовленной к такому виду тестов архитектуры. Но если речь идет о разработке с нуля или на базе БСП, при создании новых механизмов и подсистем в легаси-системах вполне реально использовать юнит-тесты в их почти классическом понимании.

В мире 1С существует два фреймворка, которые решают эту задачу. Первый — древний xUnitFor1С, который появился более 10 лет назад и был одним из первых проектов с кодом на 1С на гитхабе и молодой, современный YAxUnit.

xUnitFor1C однажды вошел в состав проекта Vanessa-ADD и активно уже не развивается (или, как мы шутим, он уже готов).

YAxUnit — это продукт наших коллег из команды BIA Technologies и сообщества. Он как и xUnitFor1С и VA открыт (open source, свободная лицензия), его развитие происходит в классической парадигме опенсорс-проектов. Имеет активное сообщество.
 

Концепция работы YAxUnit построена на использовании современных архитектурных паттернов типа «текучего» интерфейса. Поддерживается мокирование объектов и многое другое. Фреймворк изначально создавался с поддержкой 1C:EDT – для него предусмотрен специальный плагин, позволяющий запускать тесты прямо из среды разработки.

Что делать?

Совет короткий и безапелляционный: если у вас сегодня стоит выбор, какой инструмент использовать для юнит-тестирования (или по-нашему, «тестирования кодом»), то без раздумий и анализа можно брать YAxUnit.

Ожидание: фирма 1С нам даст свои тесты, и мы сможем легко проверять на регресс типовой функционал после наших доработок

В подавляющем большинстве случаев, когда говорят о разработке на платформе 1С, подразумевают не создание решения с нуля, а кастомизацию уже существующего прикладного продукта – разработанного либо самой фирмой «1С», либо сторонними разработчиками. Такие решения принято называть «типовыми».

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

Однако на практике для подавляющего большинства типовых конфигураций готовые тесты, которыми можно было бы воспользоваться, не публикуются.

В чем причины такого положения вещей довольно подробно и доходчиво рассказал Леонид Паутов, автор и главный разработчик проекта Vanessa Automation, и по совместительству тимлид группы качества 1С:ERP в фирме «1С» в своем совместном с Анастасией Андрияновой докладе «Промышленное тестирование конфигураций в 1С» (настоятельно рекомендую к прочтению или просмотру всем, кто связан с тестированием и разработкой решений на платформе 1С:Предприятие 8).
 

Я не буду тут вдаваться сильно в подробности, но если кратко: пакет автотестов — это большой сложный ИТ-продукт, требующий полноценной поддержки со стороны вендора. Его «нельзя просто так взять и» опубликовать: нужно научить им пользоваться, обрабатывать обращения по возникающим проблемам. Плюс для запуска тестов в той же 1C:ERP нужна сложная инфраструктура.

Тем не менее, для некоторых типовых конфигураций тесты все же публикуются.

Кратко расскажу о тех случаях, что известны мне, и с какими примерами было бы полезно ознакомиться, чтобы использовать их в качетсве ориентира для построения собственных решений. Если вы знаете еще варианты, буду признателен, если сообщите в комментариях. Может быть, кто-то из разработчиков отраслевых делится тестами для своих решений. Мне было бы очень интересно узнать.

Я лично знаю только четыре продукта, для которых когда-либо официально публиковались пакеты готовых сценариев для проверки типового функционала.

Первым решением фирмы «1С», для которого можно было скачать пакет тестов для «1С:Сценарного тестирования», была конфигурация «1С:Бухгалтерия предприятия». Тесты публиковались на странице релизов относительно небольшой промежуток времени и последний раз это случилось 6 лет назад, на тот момент это был релиз 3.0.67. Вот ссылка на этот релиз (нужен доступ к releases.1c.ru).
 

Вторым решением, для которого на странице релизов можно было скачать тесты в формате фиче-файлов для Vanessa Automation — это «1С:Управление холдингом 3.1». На сегодня публикация этого пакета тестов тоже прекращена, последний раз тесты были опубликованы для релиза 3.1.16.28. Вот ссылка (нужен доступ к releases.1c.ru).

Далее, с флагманским продуктом 1С:ERP публикуется набор обработок для дымового тестирования ERP и отдельно большой end-to-end сценарий «Производство с планированием по материальным производственным ресурсам». А еще в состав самой конфигурации 1С:ERP встроен тест закрытия месяца, а вызов реализации этого теста осуществляется обработкой CheckMonthClose.epf, которая входит в набор поставляемых с 1С:ERP дымовых тестов. Вот ссылка на страницу релиза 1C:ERP, указанные обработки и сценарии нужно искать в разделе «Дополнительные материалы» (нужен доступ к releases.1c.ru).
 

И, наконец, еще одним решением является «1С:Управление нашей фирмой». Команда 1С:УНФ уже продолжительное время не просто публикуют автотесты, а комплектуют ими дистрибутив конфигурации, т.е. при установке шаблона конфигурации в каталоге шаблона в папке QA вы найдете автотесты в формате 1С:СППР и каталог с фиче-файлами для Vanessa Automation. Инструкция по самостоятельному запуску – там же в каталоге. Вот ссылка на страницу релиза конфигурации (нужен доступ к releases.1c.ru).
 

Насколько мне известно, 1С:УНФ – единственный типовой продукт, который по сей день поставляется с актуальным набором автоматизированных тестов и инструкцией по их запуску. Всем, кто занимается автоматизацией тестирования в 1С, рекомендую обязательно изучить исходный код этих тестов, это хороший пример.

Из неофициальных пакетов тестов стоит упомянуть репозитории с дымовыми тестами под различные конфигурации Виталия Онянова. Плюс в Маркетплейсе Инфостарта есть несколько коммерческих (платных) пакетов тестов для 1C:ERP и 1С:БП (в том числе КОРП), но первые – только дымовые и давно не обновлялись, а качество коммерческих тестов не могу оценить, не приходилось использовать, и отзывов не встречал.
 

Что делать?

Какой же стратегии придерживаться в случае недоступности/отсутствия тестов на типовой функционал от вендора?

Мы предлагаем смотреть на это так:

• Вендор тестирует свои продукты, равно как и платформу. Решения на 1С — это продукт с достаточно высоким и повышающимся из года в год уровнем качества, согласно оценкам партнёров, собираемым к ежегодному партнерскому семинару.

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

• Но! Покрываем тестами критически важные для бизнеса пользовательские сценарии, включая типовые.

• Если мы не делаем тиражный продукт, то мы тестируем в приоритетном порядке только тот функционал и только с теми настройками, которые используем в работе «здесь и сейчас».

• Активно применяем «метод бойскаута»: при разработке нового функционала покрываем тестами этот функционал и связанный или смежный типовой в основных сценариях. Аналогично поступаем и с унаследованной кодовой базой.

• Внедряем дымовое тестирование, чтобы застраховаться от очевидных ошибок вида «пытаемся открыть форму документа, а она падает с исключением».

Ожидание: Мы просто возьмем и запустим дымовые тесты (прямо из коробки)

Теперь давайте поговорим про только что упомянутые дымовые тесты.

Цель дымового тестирования — выявить простейшие очевидные ошибки как можно раньше. Типичные ситуации:

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

• Или разработчик допустил ошибку в коде при создании на сервере, при открытии формы или при записи.
   

Рутинные проверки, которые могли бы обнаружить такие проблемы, могут и должны выполняться автоматически. И для этих целей действительно есть готовые инструменты.

В некоторых командах такие инструменты создают самостоятельно — как ранее я рассказывал, в команде разработки 1C:ERP есть набор дымовых тестов, реализованных в виде внешних обработок.

В каждом из фреймворков — Vanessa Automation (VA), Vanessa-ADD, YAxUnit есть функционал дымового тестирования.

В VA он реализован как генератор тестов по предопределенным шаблонам. Вы задаете для каких объектов метаданных какие виды тестов надо сгенерировать и в результате получаете пачку фиче-файлов со сценариями на языке TurboGherkin, которые можно запускать средствами VA.

В Vanessa-ADD на каждый вид дымовых проверок есть отдельный набор тестов-обработок в формате xUnitFor1С. То, какие объекты тестировать и другие настройки, относящиеся к тому или иному виду дымовых тестов хранятся в файле настроек.

В YAxUnit реализован подход как в ADD — это тоже набор готовых тестов кодом, но уже в формате YAxUnit, с возможностью настройки через конфигурационные файлы.
 

К сожалению, не все так просто – просто взять и запустить эти тесты «из коробки» не достаточно. С дымовым тестированием есть две основные технические проблемы:

1. В конфигурациях есть объекты, у которых при открытии вместо основной формы открываются служебные формы, реализованные в отдельных обработках

2. Одна из целей дымового тестирования — максимально быстро получить обратную связь, чтобы понять, стоит ли вообще продолжать запуск приемочных тестов. Но поскольку в типовых конфигурациях большое количество объектов метаданных, прогон дымовых тестов занимает катастрофически много времени.
    

Что делать?

Обе проблемы решаются настройкой исключений. Кандидатами на исключение являются

1. объекты, в которых реализован какой-то нестандартный подход при работе с формами (на них надо писать отдельные тесты);

2. объекты, которые редко используются, не используются вообще или ошибки в них не являются критичными для бизнеса.

Как я уже сказал, в Vanessa-ADD и YAxUnit’е это делается в файлах настроек, в Vanessa Automation вы фильтруете по метаданным на этапе генерации тестов.

Вот ссылки на официальную документацию по дымовым тестам для этих фреймворков:

• Документация по дымовым тестам Vanessa-ADD

• Документация по дымовым тестам в YAxUnit

• Документация по дымовым тестам в Vanessa Automation

Кстати, налицо гибкость подхода VA: в сгененированном тесте вы можете дополнительно уточнить шаги проверки для отдельных объектов с учетом специфики реализации, в то время как при использовании, например, Vanessa-ADD вы ограничены перечнем поддерживаемых настроек (хотя при острой необходимости всегда можно скопировать существующий «типовой» дымовой тест и доработать его под себя).

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

Поэтому также нужно сделать отдельный набор тестов/настройку с сокращенным набором проверок по заданному диапазону метаданных, которые для вашего проекта являются критически важными. Например, формы номенклатуры, контрагентов, часто используемых документов.

Перед тем, как запустить дымовые тесты в основной сборочной линии, вам нужно будет их отладить. Процесс отладки, к сожалению, максимально рутинный: вы запускаете набор тестов, он в какой-то момент падает из-за нестандартной формы, которую пропустили на этапе добавления исключений или по другой причине. Добавляете эту форму в исключения или разбираетесь с причиной падения и устраняете ее, запускаете снова. Это надо проделать первый раз до конца, далее уже этим нужно будет заниматься только после крупных обновлений типового релиза или при внедрении ваших собственных доработок.

Ожидание: Достаточно только начать писать тесты

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

И тут оказывается, что написать мало. Эти тесты нужно еще и запускать. Причем не просто запускать, а делать это регулярно – как минимум, для каждого релиза.
 

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

Если не организовать такой цикл, то, как показывает практика, команда приходит к ситуации, когда написали какую-то кучку тестов и забросили. Это приводит к демотивации участников команды, которые потратили на это усилия. Делать вторую попытку и с этими же людьми будет сложнее («мы уже такое пробовали, не поехало»).

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

Что делать?

Во-первых, не нужно откладывать автоматизацию запуска тестов. Идеально развернуть хотя бы простейшую сборочную линию. Для этого не обязательно внедрять классические инструменты CI/CD для всей разработки сразу. Пусть CI используется для запуска автотестов и формирования отчета.

Вопросы запуска автотестов отлично проработаны сообществом и есть огромное количество публикаций о том, как развернуть GitLab CI или Jenkins и настроить сборочную линию.
 

Для дженкинса есть прекрасный JenkinsLib, который из коробки поддерживает множество задач по запуску различных видов тестов. Для GitLab CI есть примеры yaml-файлов с конфигурацией сборочной линии, есть статьи и пошаговые руководства, как это сделать как в более простом варианте для персонального использования, так и соответствующие «промышленным стандартам» разработки.

Если по каким-то причинам вы не готовы поднимать полноценный CI только для запуска автотестов, то их регулярный прогон можно настроить обычным планировщиком задач на выделенной машине.

Но независимо от выбранного способа запуска автотестов обязательно нужно реализовать публикацию отчета о тестировании и этот отчет должен быть доступен всем участникам команды: и разработчикам и тестировщикам и о результате работы сборочной линии должны уведомляться все ответственные участники команды.

Наиболее распространенным форматом таких отчетов на сегодня являются отчеты в формате Allure Reports.

Ожидание: возьмем пустую базу и будем тесты запускать прямо в ней / возьмем копию прода и будем запускать тесты базы в копии

Эти два противоположных ожидания распространены приблизительно одинаково. К первому варианту более склонна команда разработки, ко второму — консультанты/аналитики и ручные тестировщики.

Но оба этих варианта имеют свои плюсы и минусы и требуют решения ряда проблем.

Вариант с пустой базой в случае с легаси-системой в инхаус-командах, например, часто «радует» неожиданным: пустую базу оказывается невозможно даже просто запустить, потому что на этапе разработки не стали заморачиваться с реализацией миграций данных, то есть обработчиков обновления и первичного заполнения.
 

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

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

Вторая проблема — примеры данных. При использовании пустой базы вам придется потратить немалые усилия на то, чтобы подготовить релевантные, корректные наборы тестовых данных, выбрать вариант их хранения, версионирования. И потом поддерживать эти структуры данных, обновлять параллельно с обновлением структуры информационной базы. Это не всегда просто.

Альтернативой в таком случае бывает подход генерации данных в самих сценариях. В целом, это идеальный вариант. Код, генерирующий данные, поддерживать и обновлять проще, чем сериализованные структуры данных. Но на генерацию данных требуется время и это увеличивает время прогона. В случае комплексных тестов, типа расчетов себестоимости и закрытия месяца, сложность задачи автоматической подготовки данных кажется для многих неподъемной.

В случае использования продуктовой базы как основной базы для тестирования проблемы другие:
 

В чистом виде мы эти данные чаще всего использовать не можем: данных больше, чем нужно, по крайней мере часть данных конфиденциальна. Не все данные могут быть корректны: где-то наверняка сделаны ручные правки в обход прикладной логики, введены корректировки записей регистров, и опираться на такие данные в тестах опасно.
 

Что делать?

В реальной практике нужно стремиться к идеалу, когда каждый сценарий сам готовит необходимые ему данные и благодаря этому будет максимально изолирован и независим от других сценариев.

Другими словами, если для сценария легко подготовить тестовые данные программно шагами или кодом, то это нужно сделать именно так.

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

К таким задачам относятся проверки проведения документов, тестирование процедур закрытия месяца и подобные механизмы, опирающиеся на сложные в плане количества атрибутов и связей данные.

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

База с такими предсозданными данными может быть подготовлена вручную заранее и храниться как самостоятельный артефакт, а может собираться на лету отдельным подготовительным этапом сборочной линии из исходников и затем наполняться из файлов с сериализованными данными.
 

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

• Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию, Дмитрий Решитко (транскрипт доклада с INFOSTART EVENT 2019)

• «Подготовка данных», Антон Степанов (раздел проекта «Материалы по тестированию в 1С»)

• Раздел «Базы данных» документации инструмента «Тестер» Дмитрия Решитко

• Раздел «Тестовые данные» документации YAxUnit

Ожидание: Мы просто покажем аналитику/консультанту/ручному тестировщику как пользоваться кнопконажималкой VA и он нам быстро напишет кучу тестов

Ну и, наконец, перейдем к финальному для нашего доклада, и очень популярному вопросу: кто же этим всем будет заниматься в команде? Часто первая реакция — нагрузить этой работой аналитика или консультанта.

С одной стороны, это здравая идея и в целом потенциал у нее большой, но на практике при ее реализации «в лоб» она или в самом начале разбивается о реальность, или больно дает о себе знать спустя какое-то время, когда тестов накапливается больше некоторого порога и наступает пора говорить об их поддержке. Об этом довольно подробно писал Евгений Павлюк в своей статье «Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории».
 

Vanessa Automation — прекрасный инструмент, позволяющий создавать и выполнять сценарии на Gherkin, воплощая тем самым идею Ubiquitous Language в реальности: есть и встроенная развесистая низкоуровневая библиотека готовых шагов, помогающая описывать действия пользователей в терминах работы с интерфейсом, и есть инструменты, позволяющие поверх этих низкоуровневых шагов реализовывать свой DSL в терминах бизнес-задач, но в отличие от других фреймворков — без привлечения разработчиков.

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

• функционал работает, а тесты почему-то красные;
• упал один тест, и свалил за собой все остальное;
• и наоборот, сборочная линия вся зеленая, и мы радовались, пока нам пользователь не сообщил о баг в функционале, на который сценарий был написан.
   

Что делать?

О наиболее частых технических граблях, по которым проходит каждая команда, внедряющая у себя автоматизацию тестирования при помощи Vanessa Automation, я довольно подробно рассказывал на февральской конференции INFOSTART TEAMLEAD&CIO EVENT 2025 в докладе «Лучшие практики разработки на Vanessa Automation, которые должен знать каждый тимлид QA» (VK Видео).

В организационном плане в команде должен быть разработчик, знающий специфику VA или познающий ее в процессе внедрения автоматизации тестирования вместе с не-технарями, которым вменили заниматься автоматизацией. В мире за пределами экосистемы 1С для таких разработчиков есть отдельное название — Software Developer Engineer in Test или SDET. У нас же, ожидаемо, эта роль — на разработчиках, тем более, исторически так сложилось, что вся инициатива в автоматизации тестирования в мире 1С исходит обычно именно из команд разработки.

Крайне желательно также, чтобы в команде был организован процесс рецензирования сценариев по той же схеме, как разработчики рецензируют (проводят код-ревью) кода.

Мы рекомендуем для этого применять не классическое построение процесса код-ревью, когда более опытные члены команды, тимлиды выполняют проверку, а внедрить в команде практику кросс-ревью, когда назначение рецензента выполняется без учета его опыта и тогда этот процесс начинает работать эффективнее и на перспективу: мы снимаем нагрузку с более опытных специалистов, такая организация рецензирования способствует распространению знаний и разделению ответственности за кодовую базу, подтягивает новичков по уровню знаний. В свою очередь младшие специалисты, задавая на ревью вопросы вида «почему это сделано так?», подсвечивают сложные и непонятные моменты.

В здоровом в плане отношений коллективе это один из самых эффективных способов делать рецензирование кода и сценариев. Я это с уверенностью и убежденностью говорю, потому что мы в Инфостарт Лаборатории уже более 5 лет практикуем на всех своих проектах.

Заключение

В завершение доклада хочу подчеркнуть, что ключ к успеху при внедрении автоматизации тестирования решений на платформе 1С:Предприятие 8 лежит в отказе от слепого копирования «классических» подходов.

Экосистема 1С диктует свои правила:

• Нашей реальностью является перевернутая пирамида тестирования, где UI-тесты играют ведущую роль, и это не недостаток, а прагматичный ответ на особенности платформы.

• Для работы нам нужны специализированные фреймворки, такие как Vanessa Automation для UI-сценариев и YAxUnit для «тестирования кодом», поскольку инструменты общего назначения здесь бессильны.

• Не стоит ждать готовых тестов от вендора. Наша задача — покрывать тестами критически важные для нашего бизнеса сценарии, а не весь типовой функционал.

• Даже «простые» дымовые тесты требуют вдумчивой настройки и отладки, чтобы стать по-настоящему быстрым и эффективным инструментом.

И самое главное: автоматизация тестирования — это не разовый проект, а постоянный процесс, требующий именно инженерной культуры. Написанные тесты бесполезны без регулярного запуска в CI/CD-пайплайне, а их качество напрямую зависит от командной работы, включающей техническую экспертизу и рецензирование кода сценариев.

Путь внедрения автоматизации тестирования не только кажется сложным, он таковым и является.

Поэтому начинайте с малого, фокусируйтесь на критически важных сценариях, с самого начала организуйте цикл обратной связи, настроив автоматический запуск тестов, и в целом выстраивайте культуру качества в команде. Именно такой осознанный подход превращает ожидания в реальные, измеримые результаты и делает ваши продукты надежнее.

Happy testing!