Как убить трех зайцев одним сценарием: опыт использования Vanessa-Automation
Эта статья посвящена опыту использования Vanessa-Automation — инструмента для тестирования прикладных решений на платформе »1С: Предприятие» и других инструментов для обучения пользователей, создания ролевых моделей и автоматизированного тестирования на проектах. В статье я расскажу, как наш подход вписывается в работу над крупными ERP-системами и не только.
Почему нам пришла идея использовать автотесты
Меня зовут Андрей Хашкин. Я руководитель группы разработки в КРОК, технический менеджер и руководитель проектов по внедрению 1С ERP. С каждым проектом мы стараемся привнести что-то новое в наши технологии и автоматизировать рутинные процессы. Несколько лет назад один из разработчиков рассказал и показал мне технологию записи тестов на 1С. Сперва идея показалась интересной, но не очень насущной, возможность записи видеоинструкций на основе сценариев оказалась очень полезной. В итоге она стала локомотивом внедрения автотестов в наши проекты.
По опыту знаю, что внедрение и поддержание автотестов требуют больших усилий, однако мы решили двигаться в этом направлении. Для этого у нас были веские причины:
Раньше мы всегда писали инструкции в Word, но простые и понятные обучающие видео казались эффективнее.
Требовалось сократить время на комплексное тестирование релиза перед выпуском в продакшн, а не отвлекать на это целую команду на день, а то и два.
На основе автотестов можно провести нагрузочное тестирование базы.
Наконец, с помощью сценариев тестирования мы могли определить объекты, доступ к которым нужен пользователям, и на основе этого сформировать профили доступа.
Мы решили, что при правильном подходе решение этих задач окупит наши усилия по созданию и внедрению автотестов.
Подготовка тестов и запись видеороликов
На каждом проекте консультанты готовят демонстрационную базу в общем тестовом окружении. Там они тестируют бизнес-процессы, необходимые для внедрения. Мы решили использовать эту базу как основу для записи сценариев, однако сама запись происходила не в общей базе, а в ее копии.
В нашем проектном подходе мы используем каталог бизнес-процессов, а каждый бизнес-процесс содержит последовательность действий пользователя в системе.
Процесс создания сценария и записи видеоролика состоит из следующих шагов:
Консультант вносит предварительные данные для сценария тестирования в базу общего теста (например, контрагента, договор, номенклатуру, необходимые для проверки проведения документа Поступление товаров и услуг).
Консультант самостоятельно через свой личный кабинет запускает копирование базы в свою тестовую базу, чтобы не мешать коллегам работать.
И уже на копии базы консультант записывает сценарий тестирования и передает записанный текст сценария тестировщику.
Тестировщик снова копирует общую базу в свою тестовую и запускает сценарий, записывая видеоролик.
Такой подход имеет важное преимущество: во время обучения пользователи не просто могут посмотреть видеоролик, но и сразу отработать полученные знания. У них под рукой своя копия базы общего теста, где можно пошагово повторить все действия, показанные в видеоролике.
Этот простой метод оказался очень эффективным. Мы можем быть уверены, что если пользователь повторит действия ровно так, как в видеоролике, если он будет выбирать те же элементы справочников, — у него точно все получится. Ведь в момент записи видеоролика мы уже провели эти действия на такой же копии.
Важно: чтобы эта схема работала без сбоев, каждый сценарий должен быть независимым друг от друга по данным, и под него должны быть заведены предварительные данные в общем тесте.
Таким образом, на составление сценария уходит от одного до трех часов, и еще один-два часа требуется на запись видеоролика у тестировщика. Этот пайплайн позволяет без особых проблем записывать от 100–200 видеороликов на проект с меньшими трудозатратами, чем написание »бумажных» инструкций.
Организация обучения пользователей
Обучение пользователей мы решили сделать полностью самостоятельным с использованием видеороликов. Процесс подготовки и обучения состоит из нескольких этапов:
Загрузка материалов: все видеозаписи выгружаются на наш внутренний LMS-портал.
Распределение контента: пользователи разделяются на группы, и каждой группе выдается доступ к той части записей, которая соответствует их будущей роли в системе.
Процесс обучения: пользователь открывает свою индивидуальную базу (копию общего теста) и повторяет действия, показанные в видеоролике. Если он будет точно следовать инструкциям, то у него точно все получится, так как сценарий записан именно на этой базе.
Организация доступа: при большом количестве пользователей, например, более 500, как в одном из наших кейсов, возникает проблема с выдачей индивидуальных копий базы и настройкой доступа. Для решения этой задачи мы создали промежуточную базу, которая автоматически выдает пользователю свободную копию базы при входе.
Такой подход дает возможность пользователям проходить обучение удаленно в удобное для него время, а нам значительно упрощает администрирование.
Организация сбора статистики и контроль за учебным процессом
При самостоятельном обучении нет четкого расписания занятий. Поэтому есть риск, что пользователь либо вовсе не пройдет курс, либо только посмотрит видео, не закрепив материал на практике в информационной базе.
Для контроля процесса обучения мы использовали два основных инструмента:
Ограничили время на прохождение обучения двумя рабочими неделями.
По итогам первой недели собрали подробную статистику по просмотрам видеороликов: количество просмотренных видео, их названия и процент просмотра каждого. Также мы отслеживали, как часто пользователи заходили в базу данных для повторения материала.
Во время обучения мы запустили работу технической поддержки. Это не только способ поддержать обучающихся пользователей, но и стресс-тест для самой службы поддержки. Так можно оценить характер поступающих вопросов, скорость реакции поддержки и достаточность персонала для обработки запросов при будущем запуске.
Собранная статистика по обучению позволяет оценить охват групп пользователей и их активность по просмотрам материалов. На основе этих данных мы проинформировали руководителей подразделений о степени вовлеченности сотрудников. Например, если в определенной группе просмотрено лишь 30% видеороликов и только треть сотрудников участвует в обучении, то стоит провести разъяснительную работу с сотрудникам.
Анализ статистики после первой недели обучения позволил изменить в лучшую сторону ситуацию с вовлеченностью пользователей в самостоятельное обучение. Это сделало процесс обучения управляемым и контролируемым.
По окончании двухнедельного курса мы подвели итоги обучения, проанализировали статистику обращений в техподдержку и внесли улучшения на основе пользовательских запросов.
Мы сохранили доступ к видеоматериалам и копии тестовой базы для всех участников. Это позволило им освежать знания и практиковаться даже после запуска основной системы. Такой же подход мы применяем при обучении новых сотрудников: они получают доступ к видеокурсу и тестовой базе для самостоятельного изучения.
Наш подход, по сравнению с традиционными классными занятиями и подготовкой тестовых сценариев для больших групп, получился более современным и гибким. Он существенно снижает трудозатраты на обучение, проще в организации и хорошо подходит для удаленных сотрудников и может использоваться на протяжении всего жизненного цикла системы.
Настройка ролевой модели
В нашей проектной методологии каждый бизнес-процесс связан с определенными бизнес-ролями и группами пользователей. Это означает, что пользователю нужен доступ только к тем объектам системы, которые задействованы в его бизнес-процессах. Бизнес-роль пользователя можно сопоставить с профилем доступа в системе 1С. Такой профиль должен обеспечивать доступ к объектам, участвующим в бизнес-процессах, соответствующих роли пользователя.
Так как все сценарии тестирования выполнены по бизнес-процессам, мы можем автоматически определить основные объекты системы, необходимые для каждой бизнес-роли. На основе этих данных мы формируем профили доступа в 1С.
Мы разработали специальный инструмент для автоматического подбора системных ролей доступа. Он состоит из расширения и обработки-рабочего места. Инструмент анализирует список объектов системы и подбирает необходимые системные роли. Кроме того, он определяет и предоставляет доступ к связанным объектам.
Например, если пользователю нужен доступ к справочнику договоров, наш анализатор автоматически добавит доступ к статьям, банковским счетам и другим связанным объектам. Это обеспечивает комплексный подход к настройке прав доступа и повышает эффективность работы пользователя в системе.
Благодаря этому методу мы смогли создать комплексные профили доступа для каждой роли, учитывая не только основные, но и сопутствующие объекты, выявленные на основе анализа сценариев.
Но мало собрать профили доступа, ими необходимо эффективно управлять. Традиционно перенос профилей с тестовой базы на боевую вызывает сложности, так как требует повторной настройки, что неэффективно и затратно по времени.
Наше решение этой проблемы — создание отдельной базы для хранения прав и профилей пользователей. Этот подход позволяет сначала проверять профили на тестовой базе, а затем автоматически загружать их в боевую. Такой метод значительно сократил время на обновление прав доступа в системе и упростил процесс управления профилями в целом.
Кроме того, вы разработали специальное рабочее место, для настройки прав доступа. С его помощью консультанты могут добавлять доступы к объектам, не учтенным в исходных сценариях.
Этот инструмент автоматически подбирает тип доступа (на чтение или изменение) и соответствующую роль при добавлении объекта. Таким образом, нужную роль больше не нужно искать вручную среди множества существующих в 1С. Выбранную системой роль аналитик загружает в профиль и проверяет на тестовой базе. Если все хорошо, то одной кнопкой обновляет профиль в боевой базе.
Этот подход существенно ускоряет процесс настройки прав доступа и снижает вероятность ошибок, связанных с ручным выбором ролей. Интерфейс особенно эффективен в крупных ERP-системах с множеством ролей и объектов.
Организация нагрузочного тестирования
При внедрении высоконагруженных информационных систем критически важно тестировать их производительность в условиях, максимально приближенных к реальным. Раньше для подготовки такого тестирования приходилось проводить отдельное исследование по ключевым операциям, а затем разрабатывать средства для их эмуляции в системе.
Так как наши сценарии тестирования сделаны в соответствии с бизнес-процессами, мы совместно с заказчиком выбираем наиболее комплексные бизнес-процессы с максимальным количеством операций и определяем их наиболее вероятную последовательность в реальных условиях. На основе этих данных и уже созданных сценариев тестирования мы разрабатываем сквозной сценарий для нагрузочного тестирования.
В зависимости от целевого значения пользователей в системе мы задействуем нужное количество ботов для непрерывного выполнения этого сценария, и это позволяет эмулировать реальную работу пользователей — этого вполне достаточно, чтобы оценить поведение системы в реалистичных условиях.
Показатели работы системы собираются на основе данных 1C ЦКК, который показывает загрузку процессора, памяти, процессов кластера, балансировку серверов и APDEX по ключевым операциям.
Примечательно, что на основе существующих сценариев тестирования и с помощью Vanessa подготовиться к нагрузочному тестированию можно буквально за пару дней одним человеком, это на порядки сокращает сроки и затраты для выполнения такого важного этапа работ в проекте.
Организация ежедневного автоматизированного тестирования
Обучение, настройка ролей, нагрузочное тестирование — все эти этапы про подготовку к запуску системы, однако после выхода на прод развитие системы не заканчивается. И мы при каждом обновлении мы должны быть уверены, что конфигурация стабильна и не содержит критических ошибок. Поэтому мы взяли те же самые сценарии, с помощью которых подготавливали видеоролики, и применили для регулярных автотестов перед обновлением конфигураций.
Как и обучение, процесс тестирования происходит на копии тестовой базы, что позволяет сохранять целостность исходных данных.
По завершении автотестов формируется подробный отчет о результатах и выводится в веб-интерфейс. Он показывает, сколько тестов пройдено, а какие нет, на каких шагах возникли ошибки. В результате можно принимать решение о выводе (или не выводе) в прод. Автоматизация этого процесса позволяет проводить такое тестирование ежедневно и делать вывод о наличии критических ошибок в хранилище конфигурации в данный момент.
Общий пайплайн наших процессов
Подводя итоги можно крупными мазками определить места и подходы к применению сценариев тестирования:
Мы начинаем с анализа бизнес-процессов и создания сценариев для каждого из них.
На основе этих сценариев мы разрабатываем видеоинструкции для обучения.
Готовим профили доступа пользователей по основным объектам в сценариях тестирования.
На основе сценариев проводим нагрузочное тестирование.
Мониторим стабильность системы с использованием автоматического тестирования.
Мы внедрили эту методику 2 года назад, и она продолжает приносить пользу. Новые пользователи до сих пор обращаются созданным к ранее созданным видеороликам. При обновлении сценариев мы своевременно корректируем все связанные материалы и процессы.
Автоматизированное тестирование, основанное на наших сценариях, существенно ускорило процесс выпуска обновлений. Теперь мы можем проверить работоспособность конфигурации всего за два часа, тогда как раньше на это уходил целый рабочий день трех-четырех аналитиков.
Таким образом, готовя один сценарий, мы убиваем сразу трех зайцев. Это значительно повышает эффективность проектов и, в итоге, удовлетворенность пользователей.
Впрочем, описанные методики лишь часть наших наработок и одна из тем бесплатного курса «Проектная технология внедрения 1С». В курсе мы рассказываем, как структурировать работу с помощью авторской методологии и сэкономить ресурсы проектной команды. Присоединяйтесь!
