Использование сценарного тестирования для поддержания качества продукта

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

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

Почему ручного регресса не хватает продуктам «1С:Предприятие»

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

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

В «1С:Горнодобывающая промышленность» тот же механизм выглядит так. Цепочка смены — это оборудование, участок, время работы и простои, табелирование, расчёт времени сотрудников. Настройки под конкретное предприятие добавляют сложностей комбинацией включенных настроек учета. Ошибки часто становятся заметны не в местах их возникновения, а уже на последующих этапах учета. Например, документ «Время работы оборудования» может быть оформлен идеально, но ошибка замаскируется в оборотах регистров времени и простоев. В итоге проблема «выплывет» только в документе «Расчет времени работы сотрудников», который объединяет данные табелирования, работы и простоев оборудования.

Поэтому качество продукта «1С:Предприятие» нельзя сводить к проверке нового функционала перед сдачей. Качество здесь — способность критических пользовательских сценариев стабильно проходить после каждого изменения конфигурации, настроек и окружения. Если этот контур держится только на памяти одного тестировщика, продукт начинает терять предсказуемость поведения.

Сценарное тестирование — способ зафиксировать ожидаемое поведение системы глазами пользователя и регулярно подтверждать, что это поведение не исчезло. Это не «ещё один вид автотестов» и не замена модульным проверкам. Это слой, который отвечает на простой вопрос: после доработки, обновления типовой или смены платформы пользователь по-прежнему может пройти ключевой процесс до результата?

Рабочая гипотеза: сценарный тест в «1С:Предприятие» удерживает качество во времени, потому что делает критическое поведение продукта явным, повторяемым и связанным с релизом.

Для «1С:Горнодобывающая промышленность» этот вопрос звучит конкретнее: диспетчер по-прежнему может внести факт времени по самосвалу за смену, а система получит те же обороты, что были согласованы с бизнесом на этапе проектирования системы?

Что такое сценарное тестирование в «1С:Предприятие»

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

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

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

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

Место сценарного тестирования в пирамиде тестирования

В общем виде пирамида тестирования в «1С:Предприятие» выглядит следующим образом:

1. Модульные проверки — расчёты, проведение, права и служебные процедуры на уровне кода. Быстрые, дешёвые, хорошо ловят ошибку в формуле и в запросе. В «1С:Горнодобывающая промышленность» это пересечение строк «Время работы» и «Простои», некорректный период, время вне смены, простой вне интервала работы, повторно проведённый документ за ту же смену.

2. Дымовые тесты Vanessa-ADD — открытие форм, запись и проведение минимальных объектов, базовые роли. Отвечают на вопрос: конфигурация вообще живая после обновления? В «1С:Горнодобывающая промышленность» — открытие форм документов, перезапись элементов справочника и документов и т.д.

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

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

Как сценарные тесты помогают удерживать качество «1С:Горнодобывающая промышленность »

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

Для поддержания качества этого продукта используется библиотека сценарных тестов на Vanessa-Automation. Сценарии описывают критические пользовательские пути оперативного учёта — горные работы, переработку, ГСМ, оборудование, склады и отгрузку, сотрудников, управление качеством — и регулярно подтверждают, что после доработок и обновлений типовой конфигураций эти пути всё ещё доходят до результата. Именно эту библиотеку имеем в виду, когда ниже разбираем конкретные feature-файлы.

Структура библиотеки наших сценариев выглядит так:

1. Группа сценариев по подсистемам «Горные работы», «Переработка», «ГСМ», «Оборудование», «Склады и транспортная логистика», «Сотрудники», «Управление качеством»;

2. В каждой группе содержатся подгруппы сценариев по подсистеме. Например, подгруппы по подсистеме «Оборудование» содержит: «Планирование работы оборудования», «Работа и простои», «Путевые листы», «Хозтранспорт и спецтехника», «Учет шин», «Обслуживание и ремонты»;

3. Каждая подгруппа содержит сценарии для тестирования отдельной функциональности. Например, подгруппы «Работа и простои» содержит сценарии: «_030201 Регламентированные простои оборудования.feature», «_030202 Возвраты оборудования из эксплуатации контрагентом.feature», «_030203 Допуск на оборудование.feature», «_030204 Передача оборудования в эксплуатацию контрагенту.feature», «_030205 Время работы оборудования.feature», «_030206 Показания счетчиков.feature», «_030207 Корректировки показаний счетчиков.feature».

Всего библиотека сценариев насчитывает порядка трехсот сценариев для поддержания качества продукта.

Сценарий как исполняемая спецификация

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

Польза появляется не от ключевых слов «Дано / Когда / Тогда», а от того, что команда договорилась: вот путь, вот предусловия, вот проверяемый результат. Пока текст исполняется, продукт подтверждает обещание бизнесу. Когда он падает, есть два честных объяснения: сломалось поведение или устарела спецификация. Оба случая — про качество, просто разное.

Какие задачи качества закрывает сценарное тестирование

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

Регресс после доработок

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

В «1С:Горнодобывающая промышленность» это выглядит так: изменили расчёт продолжительности или алгоритм заполнения регламентированных простоев. Сценарный путь «смена — оборудование — участок — интервал — простои — проведение» ловит поломку раньше, чем диспетчер и ОТиЗ начинают сверять табель вручную. Тот же класс риска в соседних контурах продукта — приёмка горных работ, заправка ГСМ, отгрузка вагонов.

Обновление типовой конфигурации

Для продуктов на базе типовой конфигурации это самая частая и тяжёлая регулярная нагрузка. Сравнение «было / стало» на одних и тех же пользовательских путях дешевле, чем каждый раз заново вспоминать, что проверять после объединения. Сценарий не заменяет анализ изменений вендора, но даёт измеримый ответ: критический контур после обновления ещё жив.

Обновление платформы «1С:Предприятие»

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

Расширения, роли и комбинации настроек

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

В «1С:Горнодобывающая промышленность» такие пересечения — участки горных работ, виды данных, оборудование другого подразделения, роли диспетчера, механика и сотрудника ОТиЗ. В соседних подсистемах — маркшейдерский замер и приёмка, заправка и слив топлива, погрузка вагонов с разрешением и без, паспорт качества и отбор проб.

Фиксация договорённости с бизнесом

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

Снижение зависимости от героя-тестировщика

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

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

Что сценарным тестированием закрывать не стоит

Сценарный тест — один из самых дорогих видов автоматизации в «1С:Предприятие». Он имитирует пользователя и зависит от форм, данных, прав и скорости стенда. Если закрывать им всё подряд, команда быстро получает пачку красных проверок, которым никто не верит.

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

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

Инструментальная карта

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

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

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

Как проектировать сценарии, которые держат качество

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

С чего начинать покрытие

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

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

2. Затем — пути, которые уже ломались в прошлых релизах. История дефектов — лучший каталог регресса.

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

4. После этого — сложные ветки с несколькими документами и пересчётами. 

Три-пять живых сценариев, которые падают по делу и чинятся по делу, дают продукту больше качества, чем сотня хрупких проверок «открыли справочник».

Границы одного сценария

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

В «1С:Горнодобывающая промышленность» граница такая: «провести факт работы оборудования _БЕЛАЗ_7555 на участке _Участок 1 за смену _Смену 1 и убедиться, что есть обороты по времени и простоям» — сценарий. «Закрыть всю подсистему «Оборудование» от плана доступности до списания шин» — уже нет.

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

В «1С:Горнодобывающая промышленность» явные предусловия — _Разрез ООО, _Подразделение, _Смена 1, вид данных «Факт», оборудование, участок, при необходимости заранее проведённые регламентированные простои.

Проверяйте следствие, а не только действие. «Кнопка нажалась, окно закрылось» — слабая проверка. «Документ проведён, есть движения, пользователю не показано сообщение об ошибке» — проверка качества продукта. Если следствие читается запросом к базе, это нормально: сценарий может завершаться серверной проверкой состояния.

Для «Времени работы оборудования» следствие — оборот в регистре по оборудованию и участку.

Данные и изоляция

Типовая боль «1С:Предприятие» — зависимость от конкретной информационной базы. Чужие остатки, закрытые периоды, неуникальные наименования, проведённый «чужой» документ с тем же номером, включённая функциональная опция, о которой сценарий не знает. На одной копии базы тест зелёный. На стенде сборки — красный. Или наоборот, что ещё опаснее.

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

В библиотеке сценарных тестов «1С:Горнодобывающая промышленность» уже есть рабочий приём: префикс _ у тестовых элементов — _Разрез ООО, _Подразделение, _Смена 1, _Участок 1, _БЕЛАЗ_7555. 

Устойчивость к изменениям форм

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

Практики устойчивости известны и скучны — именно поэтому их стоит соблюдать:

• искать элементы по стабильному имени, а не по порядку;

• ждать состояния формы, а не вставлять паузу «пять секунд»;

• выносить повторяющиеся действия в переиспользуемые шаги;

• отделять слой «открыть, заполнить, провести» от слоя «проверить результат»;

• не считать запись действий пользователя окончательным сценарием, это черновик, сценарий качества — отредактированный текст с явными проверками.

Роли, клиенты и экономический смысл матрицы

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

Матрица «все роли × все склады × все функциональные опции» выглядит солидно в презентации и разоряет команду на практике. Экономический смысл прост: покрытию подлежат сочетания, с которыми продаётся, внедряется и сопровождается продукт. Остальные сочетания проверяются с помощью дымовых тестов Vanessa-ADD, выборочного ручного прогона и исследовательских сессий.

Для пользователей «1С:Горнодобывающая промышленность» основной клиент — тонкий. Ключевые роли — диспетчер, механик, сотрудник ОТиЗ. Не нужно размножать «все роли × все участки × все марки».

Как встроить сценарии в жизненный цикл продукта

Сценарии поддерживают качество только если участвуют в решении «выпускаем / не выпускаем». Лежащий в папке feature-файл — документация с истёкшим сроком годности.

Практичный каркас такой: путь описан один раз как переиспользуемый сценарий; релизный контур вызывает его отдельно; сводная фича подсистемы задаёт порядок соседних документов, но не подменяет короткие проверки.

В библиотеке сценариев «1С:Горнодобывающая промышленность» это уже реализовано и описано выше. Экспортный сценарий не гоняется сам по себе при выпуске релиза. Его вызывает обёртка CI/CD. Сводная фича подсистемы собирает порядок документов.

Требование, разработка, регресс, сопровождение

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

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

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

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

CI/CD по мере зрелости

Не обязательно начинать с полноценного конвейера. Сначала сценарии должны стабильно проходить на выделенном стенде по кнопке. Затем — ночной прогон, отчёт, квоты времени, хранение истории падений. Отчёт Vanessa-Automation нужен не для красоты: он показывает, какой шаг и на каких данных сломался, и отделяет падение продукта от падения стенда.

Полноценный CI/CD в «1С:Предприятие» упирается в прозаические вещи: время поднятия базы, лицензии, порты клиента тестирования, блокировки, зависший сеанс. Это часть инженерии качества, а не мелочь администрирования. Пока стенд нельзя поднять предсказуемо, наращивать число сценариев бессмысленно.

Ручной контур не исчезает

Автосценарии снимают повторяемый регресс. Человек проверяет новизну, стыки подсистем, данные заказчика, «ощущение» процесса, исключения, которые слишком дороги для автоматизации. Роботам доверяют повтор, человеку — смысл.

Кто владеет сценарием

Рабочая модель — общий язык плюс технические шаги.

• Аналитик отвечает за смысл пути и проверяемый результат.

• Тестировщик — за воспроизводимость, данные и стабильность прогона.

• Разработчик — за тестопригодность форм, имена элементов, серверные проверки состояния и скорость подготовки данных.

Если владелец только один, сценарии либо отстают от постановки, либо отстают от кода. Если роли аналитика и тестировщика совмещаются, сценарии теряют своё качество.

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

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

Типичные ошибки, которые убивают пользу

Автоматизация всего подряд. Команда переносит в Vanessa-Automation чек-лист из двухсот пунктов. Через месяц половина красная, вторая половина зелёная без понятных проверок. Оптимальный подход — формировать релизный контур из критических путей, а остальные сценарии отбирать с учётом частоты повторения и стоимости пропуска дефекта.

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

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

Прогон только на машине одного сотрудника. Это не контур качества продукта, а личный ритуал. Делайте иначе: выделенный стенд, известная база, запуск без участия автора. Если без автора не запускается — сценария ещё нет.

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

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

Сценарий как необработанная запись действия пользователя. Запись действий через Vanessa-Automation полезна как черновик. Как продукт качества она хрупка: лишние клики, поиск по тексту заголовка, незаполненные «Как / я хочу / чтобы». Готовый сценарий требует редактирования пути, смысловых названий шагов и явных проверок.

Нет владельца при обновлении форм типовой. После объединения конфигурации сценарии красные три недели, потому что «потом поправим». Актуализация релизного контура должна быть обязательным этапом обновления — наравне с переносом доработок. Если контур нельзя починить в срок, это сигнал не выкинуть тесты, а сузить его до того, что команда реально удерживает.

Мини-кейс: документ «Время работы оборудования»

Подход можно рассмотреть на реальном объекте конфигурации «1С:Горнодобывающая промышленность» «Время работы оборудования». Это не инструкция по Vanessa-Automation, а иллюстрация, как общие правила статьи работают на конкретном продукте.

Риск

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

Пользовательский путь

Диспетчер открывает «Оборудование → Время работы оборудования», создаёт документ, выбирает организацию _Разрез ООО, дату смены, смену _Смену 1, подразделение _Подразделение, вид данных «Факт», ответственного. На закладке работ и простоев добавляет строку: оборудование _БЕЛАЗ_7555, участок _Участок 1, начало 08:01, окончание 09:02. Затем нажимает команду заполнения регламентированных простоев по всему оборудованию и проводит документ.

В тексте, понятном аналитику, тот же путь выглядит как спецификация:

Функционал: Учёт времени работы оборудования за смену

  Как диспетчер

  Я хочу провести факт работы самосвала на участке

  Чтобы в оперативном учёте появились время работы и простои за смену

Сценарий: Проведение факта по БелАЗу на участке

  Дано в системе есть организация "_Разрез ООО"

  И производственное подразделение "_Подразделение"

  И смена "_Смена 1"

  И оборудование "_БЕЛАЗ_7555"

  И участок работ "_Участок 1"

  И вид данных "Факт"

  Когда я создаю документ "Время работы оборудования"

  И указываю в строке работы оборудование, участок и интервал с 08:01 по 09:02

  И заполняю регламентированные простои по всему оборудованию

  И провожу документ

  Тогда документ проведён

  И в регистре "Время работы оборудования" есть оборот по "_БЕЛАЗ_7555" и "_Участок 1"

  И табличная часть "Простои" заполнена, если для марки задан регламент

Фактический экспортный сценарий _030205 уже воспроизводит клики этого пути: командный интерфейс, выбор элементов с префиксом _, ввод интервала, команда Время Работы Команда Заполнить Регламентированные Простои Всего Оборудования, ФормаПровестиИЗакрыть. Это хороший каркас, но для удержания качества его нужно дополнить следствием, а не считать закрытие окна достаточным условием.

Что проверяет сценарий качества — и что остается другим слоям

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

• время работы выходит за пределы смены — проведение отклонено;

• две строки по одному оборудованию и участку пересекаются — проведение отклонено;

• оборудование принадлежит другому подразделению — проведение отклонено;

• при включённой опции участков строка без участка не проводится.

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

Дымовым тестам Vanessa-ADD оставляем открытие журнала и формы документа под базовыми ролями. Человеку — новые виды функционала, спорные решения пользовательского интерфейса и базу конкретного разреза.

Когда гонять

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

Кто потребляет результат сценария

В продуктах «1С:Предприятие» документ редко живёт сам по себе. Потребитель данных — соседний процесс, и его не нужно автоматизировать внутри чужого сценария. Нужно понимать границу.

Например, в «1С:Горнодобывающая промышленность» сценарий «Расчет времени работы сотрудников» прямо говорит, зачем ОТиЗ нужен этот контур: объединить «Табелирование» и «Время работы оборудования», чтобы получить виды времени по работе и простоям сотрудников за период. Сценарий времени оборудования подтверждает, что факт смены попал в регистры. Сценарий расчёта времени сотрудников подтверждает, что ОТиЗ может опереться на этот факт.

Практический старт за две-четыре недели

Ниже — контур, который можно пройти для любой конфигурации «1С:Предприятие», не дожидаясь «идеальной стратегии тестирования». Цель периода не покрыть продукт, а получить первый честный сигнал качества. 

1. Неделя 1. Отобрать три-пять критических сценариев. Критерий простой: если путь сломан, выпуск стыдно отдавать пользователю.

2. Неделя 1. Описать их человеческим языком вместе с аналитиком: роли, предусловия, шаги, проверяемый результат, что не входит в сценарий.

3. Неделя 1–2. Поднять стенд менеджера и клиента тестирования на выделенной базе. Зафиксировать платформу, режим клиента и способ восстановления базы.

4. Неделя 2–3. Автоматизировать основной успешный путь с проверкой следствия, не только кликов. Один отказной путь — если он часть обещания продукта.

5. Неделя 3. Встроить прогон в релизный чек-лист: нет зелёного контура — нет выпуска. Пока без CI/CD это может быть регламентный запуск вручную.

6. Неделя 4. После первого обновления типовой или крупного релиза оценить стоимость актуализации. Сузить контур, если не удается удерживать его. Расширять только то, что уже доказало повторную пользу.

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

Заключение

Качество продукта на платформе «1С:Предприятие» удерживается не числом тестов и не героизмом последнего теста перед выпуском. Оно удерживается регулярным подтверждением критического поведения: пользователь по-прежнему может пройти путь до результата после доработки, обновления типовой и смены платформы.

Для «1С:Горнодобывающая промышленность» это звучит так: диспетчер по-прежнему может провести факт времени по технике за смену, а ОТиЗ — опереться на эти данные.

Сценарное тестирование делает это поведение явным, повторяемым и связанным с релизом. Оно не подменяет модульные расчёты, дымовые тесты Vanessa-ADD и ручное тестирование. Оно закрывает тот слой, где продукт встречается с пользователем: цепочка документов, права, настройки, форма, наблюдаемый итог.

На старте проекта важно сфокусироваться на ключевых сценариях.  Несколько сценариев, которым команда верит, полезнее широкого покрытия, которому команда научилась не верить. Для «1С:Горнодобывающая промышленность» мы разработана и используется библиотека сценариев, встроенная в pipeline CI/CD контур, а по результатам тестов формируются отчёты Allure. На начальном этапе на эту работу потребовалось около двух месяцев.

Короткий чек-лист для команды

• Есть список критических пользовательских путей продукта, а не только список объектов метаданных.

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

• Сценарии отделены от дымовых тестов Vanessa-ADD и модульных проверок.

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

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

• После обновления типовой заложено время на актуализацию сценариев.

• Ручной контур оставлен для новизны, стыков и данных заказчика.

Статья сознательно не включает пошаговую установку Vanessa, полный синтаксис Gherkin и настройку CI/CD с нуля. Эти темы имеют смысл как отдельные практические материалы — уже после того, как команда договорилась, какое поведение продукта она удерживает.