Привет! Меня зовут Евгений Емельянов, я руководитель проекта Календарь Mail.Ru. Сегодня я расскажу вам о том, как мы прокачали тестирование мобильных приложений Календаря с помощью персонажей и сценариев. Такое тестирование широко применяется в юзабилити-исследованиях и при изучении взаимодействия пользователей с интерфейсом. Мы решили применить похожие методики для классического ручного тестирования мобильных приложений. Поначалу, команда была настроена скептически, но результаты оказались весьма положительными, поэтому мы хотели бы поделиться с вами своим опытом.

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

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

Проблема назрела

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

1. Разработчик собирает билд.
2. Производится дымовое тестирование.
3. Проверяются выполненные в этом билде задачи.
4. Производится тестирование всего блока функционала, затронутого изменениями.
5. Если билд может стать бета-версией, то производится полное тестирование всех юзкейсов.

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

Вымышленные друзья

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

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

Мобильный: использует календарь только на смартфоне — iOS или Android. Очень редко заходит в веб-интерфейс. События, в основном, личные, как однократные, так и периодические.

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

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

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

У этих пяти групп пользователей пересекаются юзкейсы, но довольно сильно отличаются сценарии (набор юзкейсов и порядок их выполнения). К примеру, быстрая и стабильная синхронизация данных между клиентами критична для «Активного» и «Технократа» и не особо важна для «Мобильного», так как он пользуется только мобильным клиентом. Исходя из этих соображений мы составили сценарии использования для каждого персонажа на основе уже существующих юзкейсов.

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

Процесс пошел

Теперь процесс тестирования приложений выглядит так:

1. Разработчик собирает билд.
2. Производится дымовое тестирование.
3. Проверяются конкретные задачи в этом билде.
4. Производится тестирование сценариев персонажей, использующих затрагиваемые блоки функционала.
5. Если билд может стать бетой, то производится тестирование всех сценариев всех персонажей в порядке приоритетов.

Для примера приведу один из наших сценариев тестирования для персонажа «Активный». Сценарий рассчитан на выполнение в течение часа:

• просматриваю в мобильном клиенте уведомления о событиях в начале рабочего дня (у некоторых просматриваю подробное описание);
• переношу 1-2 события на другое время;
• добавляю участников в одно из событий в веб-клиенте;
• создаю 1-2 события на текущий день и 2-3 события на текущую неделю;
• создаю в мобильном клиенте 2-3 задачи на произвольную дату;
• ставлю статус «выполнено» на произвольные задачи из текущего списка в веб-клиенте;
• в режиме «оффлайн» в мобильном клиенте просматриваю события, создаю пару новых задач, перемещаю одно из событий, выхожу в онлайн, проверяю синхронизацию (это мы называем имитацией поездок в лифте);
• помечаю в веб-клиенте несколько задач выполненными, переношу 1-2 задачи на другой день, создаю 2-3 события на произвольную дату, шарю событие из календаря «День в истории» в социальную сеть.

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

Ложка нюансов

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

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

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

Профит

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

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

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

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

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

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

Юрий Ветров (jvetrau), руководитель группы проектирования интерфейсов Mail.Ru Group:

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

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

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

Автор: johnny_palec

Источник