Опыт применения Vanessa-Automation и других инструментов для обучения, ролевой модели и тестирования

Наверное, этот доклад нужно было назвать «Как мы убили трех зайцев одним выстрелом» – я расскажу о результатах, которые мы получили, используя сценарии тестирования на основе Vanessa Automation.

Я давно занимаюсь 1С, уже лет 20. Последние 11 лет работаю в КРОК – в основном руковожу проектами, и еще у меня есть своя группа разработки 1С.

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

Почему нам пришла идея использовать автотесты

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

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

Тут ко мне пришел один из моих разработчиков, говорит: «На Vanessa Automation можно записать видео». Мы посмотрели, как Vanessa Automation записывает сценарии тестирования по кликам, и убедились, что эта же Vanessa Automation на основе сформированных сценариев при помощи дополнительных инструментов может записывать видеоинструкции о том, как пользователь работает в 1С.

С этого все и началось.

В результате:

• Мы сократили время на подготовку видеоинструкций – задача сделать видеоинструкции у меня тогда была чуть ли не первейшей.

• Эти же сценарии мы потом стали использовать для комплексного тестирования конфигурации.

• Эти же сценарии мы потом использовали для нагрузочного тестирования.

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

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

Расскажу, как мы это делали.

Организация подготовки тестов и записи видеороликов

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

Особенность записи сценария тестирования в том, что в единой базе «Общий тест» аналитики вводят предварительные данные, а сам тест записывают на ее копии. Это существенно важно, потому что мы берем копию базы, записываем на ней сценарий, а впоследствии передаем Заказчику копию базы “Общий тест” для обучения. Мы уверены на 100%, что пользователь справится с этим заданием, потому что нужно повторить ровно то же самое, что делал аналитик при записи теста.

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

При подготовке тестов и записи видеороликов у нас на входе всегда список бизнес-процессов.

Первое, что мы делаем в проекте – это каталог бизнес-процессов, на этом построена вся методология ведения проектов 1С подход в КРОК.

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

На каждый бизнес-процесс аналитик создает сценарий:

1. Заполняет в базе «Общий тест» предварительные данные.

2. Создает копию базы общего теста – для этого у нас есть собственный сервис, чтобы не выгружать и загружать, а нажать кнопку и создать копию, не выгоняя из базы «Общий тест» других людей.

3. И средствами Vanessa Automation записывает последовательность действий.

Все. Работа аналитика закончилась.

Затем мы отдаем сценарий тестировщику:

1. Он копирует базу «Общего теста» в свою тестовую.

2. Исправляет в сценарии технические ошибки,

3. И записывает по нему видеоинструкцию.

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

А сейчас мы отдаем заказчику видео – и это просто, единообразно и близко к системе.

Организация обучения и поддержки

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

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

• Каждой группе в нашей системе обучения LMS (Learning Management System) выделили свой состав видеороликов

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

Тут есть еще одна хитрость. Мы понимаем, что прописывать базы каждому из 300 пользователей – неудачная идея. Но мы же автоматизаторы – мы сделали еще одну базу, которая сама распределяет пользователей по свободным базам. Это простейший инструмент, который очень просто администрируется и, главное, дает нам ответ, кто вообще заходил в базу.

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

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

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

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

• кто обращался;

• по каким вопросам;

• с какой интенсивностью;

• по каким блокам;

• хватает ли там людей на поддержке или не хватает.

Мы ответили себе на эти вопросы уже в процессе обучения – при том, что у нас в этот момент нет большого SLA по скорости ответа пользователям, мы могли бы и завтра на них ответить.

Так как мы используем LMS для обучения – мы знаем, какие видео посмотрел пользователь, досмотрел ли он их до конца;

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

Мы приходим к руководителям каждой из групп пользователей, и говорим: «А вы знаете, ваши пользователи ни разу не зашли и не посмотрели видео, ни разу не зашли в базу, будьте добры, попинайте их».

Поскольку на обучение было отведено две недели, в конце первой сделали срез статистики, пришли и сказали: «Уважаемые руководители, ваши сотрудники не учатся». Руководители пошли, попинали сотрудников, те начали учиться, и мы таким образом проконтролировали процесс. Таким образом мы не просто опубликовали видеоролики, а реально контролировали процесс и смотрели – делают что-то пользователи или нет.

Преимущества такого онлайн-обучения:

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

• Не было никаких проблем с тем, где находится пользователь: на месте или не на месте. Мы отдельно не собирали их массово.

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

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

Организация нагрузочного тестирования

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

Но мы решили: раз у нас уже есть сценарии, почему бы не воспользоваться для нагрузочного тестирования Vanessa Automation и не «прокликать» планируемую нагрузку?

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

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

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

Таким образом с помощью этих же сценариев мы смогли провести нагрузочное тестирование.

Настройка ролевой модели

Дальше – больше. Поскольку каждому сценарию соответствуют конкретные роли пользователей, мы можем ответить себе на вопрос: «К чему нужен доступ этим пользователям?» Мы берем сценарий и вытаскиваем из него те объекты, которые в нем используются.

Но здесь есть еще одна хитрость. Например, когда мы тестируем создание договора, в сценарии будет история про то, что пользователь заходит в список, нажимает кнопку, создает договор, записывает и так далее. Но мы же понимаем, что у пользователя при этом должен быть доступ не только к договору, но и к его полям – «Контрагент», «Группа финансового учета» или т.д.

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

• либо на запись, если пользователь использует эти объекты в сценарии;

• либо на чтение, если доступ нужен по ссылке.

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

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

Чтобы упростить работу с ролями, у нас была выделена единая база настройки и хранения прав:

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

• В тестовой базе аналитик тестирует роль.

• Если все работает, он идет в боевую базу, нажимает кнопку и загружает структуру прав доступа одним действием.

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

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

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

Организация ежедневного автоматизированного тестирования, где посмотреть результаты

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

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

Но факт в том, что мы воспользовались теми же самыми сценариями и получили возможность постоянно тестировать конфигурацию:

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

• Когда мы выпускаем релиз для обновления для боевой базы, мы выделяем отдельное время – для тестирования сборки - около двух часов. Этим мы отвечаем себе на вопрос: «А готова ли конфигурация работать по критичным процессам, и нет ли в ней каких-то проблем?» Когда архитектор смотрит на отчет с ошибками, он отвечает себе на вопрос – можем мы обновлять бой или нет.

Раньше мы брали 3-4 аналитиков, которые в течение полудня тестировали критичные процессы руками – это было очень трудозатратно.

Сейчас мы, заранее подготовив эти тесты для другой задачи(обучения), бесплатно получили инструмент для ежедневной проверки состояния разрабатываемого релиза.

На слайде – стандартный отчет Allure, который показывает список выполненных или невыполненных тестов.

Если кликнуть на конкретный тест, он показывает список шагов из сценария тестирования.

Для невыполненных шагов выводится текст, который выдает программа при возникновении этой ошибки. Если там была какая-то программная ошибка, он сюда еще и программный код напишет.

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

Заключение

Резюмирую:

• На входе у нас есть бизнес-процессы, которые мы автоматизируем.

• По каждому бизнес-процессу мы сделали сценарии.

• На основе этих сценариев мы записали видеоинструкции.

• На основе этих же сценариев мы сделали профили доступа.

• И на основе этих же сценариев мы сделали автотестирование.

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

Более того, созданные в начале проекта видеоинструкции мы использовали не только до запуска, но и используем их до сих пор:

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

• Эти видеоинструкции до сих пор актуальны, потому что у нас есть автотесты, которые нам точно говорят о том, какая инструкция неактуальна.

• Понимая, какой автотест упал, тестировщик разбирает и смотрит: «Ага, какая-то кнопка перестала нажиматься». Он идет к аналитику и говорит: «Слушай, а что с этой кнопкой?» Ему отвечают: «Да потому что мы ее сменили». Тестировщик меняет эту кнопку в сценарии тестирования, перезаписывает видеоинструкцию и выкладывает ее в LMS.

Благодаря этому у нас в системе обучения всегда актуальные видеоинструкции.

Вопросы и ответы

К этим тестам имеет доступ разработчик? Например, если ему надо доработать заказ покупателя и проверить свои наработки, он может сразу тест запустить? Или этой практики пока нет?

У разработчиков такая возможность есть, но они обычно сами тестами не пользуются.

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

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

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

Не планируете ли вы поделиться инструментом, который помогает настроить профили доступа для пользователей?

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

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

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

Мы на видео показываем, как это сделать, а в базе человек должен самостоятельно это сделать.

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

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

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

Мы об этом знаем на 100%, у нас это каждую ночь проверяется. Такая логика.

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

Этот вопрос из разряда – нужно ли вообще покрывать тестами всю функциональность.

Я считаю, что не нужно. Мы живем в мире 1С и в течение дня можем исправить почти любую ошибку, которая есть в боевой базе.

Мы не пытаемся покрыть все нюансы – это невозможно и, главное, не нужно. Нам важно, чтобы отрабатывали критичные бизнес-процессы.

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

Поэтому критичность – это наше все.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.