Тесты в формате симуляции

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

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

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

Что это за система

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

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

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

Как убедиться, что пользователь не допустит ошибок?

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

Раньше мы использовали онлайн-демонстрации работы в системах, а потом проверяли решение тестовых задач.

И всё в целом было неплохо, кроме пары сложностей.

• При обучении большого числа пользователей это вызывало большие затраты. 

• Без практики всё равно никуда. Одно дело — посмотреть что-то онлайн, другое — сделать самому вот этими руками. А потом ещё и повторять без ошибок.

Как внедрить практику в обучение?

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

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

1. Нельзя отследить путь пользователя: вы не знаете точно, сделал он всё, как надо по процессу, или просто рандомно натыкал что-то и случайно пришёл к нужному результату. Такое тоже бывает.

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

3. Снова высокие затраты — теперь на наполнение, поддержку и обновление данных в такой системе.

Что делать?

Выход есть: симуляторы

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

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

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

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

Мы используем три ключевых формата симуляторов. 

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

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

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

Сегодня мы расскажем именно про формат тестов-симуляторов. 

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

Преимущества теста-симулятора:

• позволяет точно оценить практические навыки работы в системе;

• снижает затраты, поскольку не требуется участие тренера — результат фиксируется автоматически;

• не требует отдельной среды или копии системы;

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

Для примера разберём один из наших кейсов.

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

А для проверки качества усвоения материала использовались стандартные тесты-опросники с вариантами ответа. По мнению заказчика, они не позволяли оценить уровень усвоения материала.

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

После совместного обсуждения мы пришли к следующему решению. 

1. Мы оставили презентации как вводный теоретический материал для изучения основ системы. 

2. Мы заменили тесты-опросники на тесты-симуляторы, чтобы новый формат позволил проверять практическую готовность пользователя к работе в системе. 

Реализация

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

Например, пользователю нужно нажать на кнопку в самом конце страницы. Соответственно, ему нужно запомнить, что надо сначала проскроллить страницу, потом найти эту кнопку, а затем нажать на нее. 

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

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

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

Что было сложного

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

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

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

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

• Пользователь взаимодействует с первой частью задания на одном слайде.

• Затем видит подсказку о необходимости прокрутки и переходит к следующему слайду с новой порцией информации.

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

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

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

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

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

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

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

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

Нестандартные сочетания клавиш и кнопок мыши. Мы уже упоминали, что столкнулись с проблемой того, что конструктор курсов не поддерживает некоторое нестандартное сочетание клавиш и кнопок мыши, например, Shift + Левая кнопка мыши. Чтобы решить эту проблему, мы использовали комбинацию триггера, переменной и JavaScript. Скрипт отслеживает нажатие необходимого сочетания клавиш и кнопок, и, если они нажаты правильно, переменная меняет свое значение на true. И в то же время настроен триггер, чтобы пользователь переходил на следующий слайд, если переменная поменяла свое значение.

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

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

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

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

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

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

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

Как мы оптимизировали процесс с помощью шаблонов и чек-листов

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

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

Все наши материалы проходят несколько этапов. 

1. Первый этап — это проверка самим исполнителем. Разработчик выполняет тестирование настроек до публикации в LMS, поскольку именно в этот момент проще всего внести правки. 

2. Далее идет тестирование сотрудником нашей команды. Проверяется понятность и работоспособность симулятора после публикации в LMS. 

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

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

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

То есть фактически формируется некий сценарий тестирования.

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

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

Объясним, почему на конкретном примере. В системе пользователь работает с выпадающими списками. Таких списков на странице может быть одновременно несколько, например, 4, 5 или даже больше. На каждый шаг у нас предусмотрено 4 попытки. И при каждом клике, а также при нажатии на кнопку «Рестарт» эти попытки должны обновляться. 

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

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

Похожая ситуация с тестированием полей для ввода данных.

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

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

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

Что в итоге

Симулятор — это не просто «интерактив», а полноценный инструмент оценки практических навыков. Он безопасен, реалистичен и позволяет проверить пользователя в деле без риска для бизнеса.

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

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

1. чёткое согласование объёма на старте — без этого правки и доработки бесконечны;

2. шаблоны и чек-листы для тестирования — не убивают индивидуальность модуля, но не дают рассыпаться мелочам;

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

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

Есть вопросы или хотите поделиться опытом? Пишите в комментариях.