Использование персонажей и сценариев в тестировании Календаря



    Привет! Меня зовут Евгений Емельянов, я руководитель проекта Календарь 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:
    Персонажи — мощный инструмент проектировщика и дизайнера, который позволяет фокусироваться на наиболее востребованных в реальном использовании продукта сценариях. Было здорово увидеть, что он нашел применение и в процессе тестирования качества реализации, а не только применительно к юзабилити.

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

    До этого на персонажей опирались при экспертной оценке юзабилити и пользовательских тестированиях. Использовать их для проверки качества реализации — интересный и достаточно свежий подход. Давно и много читаю о современных методах работы над интерфейсами и про такой еще не доводилось слышать. Так что это отличнейшее дополнение в копилку продуктовой команды.
    Mail.ru Group
    1,156.32
    Building the Internet
    Share post

    Similar posts

    Comments 16

    • UFO just landed and posted this here
        0
        Помоему так таких личностей очень много. Видимо просто календарем не все пользуются. Уверен что в соц сетях таких большинство.
        +4
        Скажите, кто рисует такие красивые картинки? Очень сильно нравятся.
          +1
          Вам нравятся красные носы и опухшие глаза?
            +1
            PR-департамент. Спасибо )
              0
              Хорошо. А кто именно из PR-департамента? Есть у этого человека имя?
            –4
            То есть вы придумали ещё один способ выявить баги и определить среди них первоочередные. А так ли это важно и необходимо?
            У вас ведь есть целая социальная сеть, и в ней миллионы пользователей, причём не все из них сверхлояльные, как те, о которых вы говорите в своём посте, и будут замалчивать баги, если они мешают нормально пользоваться сайтом.
            Что может быть проще: создать сообщество, предложить в нём рассказать о проблемах, с которыми сталкиваются пользователи, и попытаться эти проблемы решить.
            Смотрите, вот о чём спрашивают люди только за последние дни:
            Не работает поиск по группе
            Не работает календарь сообщества
            На работает кнопка «нравится»
            Не приходят уведомления о комментариях
            Нет уведомлений из закрытых сообществ
            А здесь список глюков в два десятка пунктов: не работает курсив, невозможно выделить цитату, проблемы с добавлением видео, не работает слайдшоу, перестали работать часть тегов, которые работали раньше, не приходят уведомления о записях и комментариях из закрытых сообществ (а последние три дня и из открытых тоже).
            Но мы просто сообщество пользователей, мы можем заметить проблему, но не исправить её. А разработчики ищут новые способы выявления багов, тогда как часто достаточно просто спросить.
            • UFO just landed and posted this here
                +2
                Ирина, вы правы, обратная связь от пользователей — важная и полезная информация, никакой тестер не в силах предусмотреть все варианты и все сценарии использования продукта. Мы ежедневно получаем сотни писем от пользователей и своевременно реагируем на все замечания.

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

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

                Хочу так же заметить, что большую часть обновлений мы раскладываем сначала на корпоративных пользователей (сотрудников компании mail.ru), и собираем от них обратную связь. Этот шаг очень важен — пользователи (наши коллеги) лояльны к нам, с удовольствием делятся всеми замеченными ошибками как в работе проекта (баги) так и по части функционала и юзабилити. После того, как этот этап пройден, мы начинаем включать новый функционал на наших любимых пользователей, — постепенно. Сначала на 10%, потом на 20 и так далее. Если в этот момент негативной обратной связи от пользователей не поступает, то новый функционал включается на всех и мы приступаем к следующим задачам.

                P.S. Всё, что я описал выше относится только к проекту «Календарь»: calendar.mail.ru/. Те ссылки, которые привели вы относятся к проекту «Мой Мир» и тот календарь сообществ, который вы упомянули не имеет отношения к нашему проекту.
                P.P.S. Я тоже занимаюсь проектом Календарь Mail.ru, если что.
                  0
                  Начну с последнего пункта. К Календарю у меня вопросов нет. Может быть потому что последний раз я им пользовалась года два назад, когда вы проводили конкурс. Было весело, спасибо :)

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

                  Если предположить, что этот метод тестирования уже используется на проекте Мой Мир, то может статься что пользователи, которые комментируют посты и ждут, что на их комментарии ответят, используют цитаты, добавляют в посты и комментарии видео, используют теги при оформлении постов, пользуются опросами и т.д, не вошли ни в одну из основных групп пользователей и их проблемы остались разработчикам неизвестными или были признаны не приоритетными, такими, которые не требуют решения.
                    +1
                    Если предположить, что тестирование с использованием персонажей используется в проекте Мой Мир, то, на мой взгляд, ваши ожидания о включении описанной группы пользователей выглядят логичными.
                    Попробую уточнить этот вопрос.
                      0
                      Уточните, пожалуйста. А то без уведомлений как-то совсем печально стало на проекте. И другие глюки тоже не радуют. Может быть они смогут их исправить.
                0
                Я честно открыл на телефоне этот сайт. Ждал честные секунд 5, и разочаровался, увидев просто долго загружающийся календарь. Вывод: роль «интересующийся» не была проработана
                  0
                  Добавлю что на странице логина вообще нет ссылки «Помошь» или «Справка», в итоге я не могу узнать интересующую меня информацию как устроена синхронизация с мобильниками.
                    0
                    Хорошее замечание, спасибо!
                  0
                  По ходу возникла пара вопросов.
                  Производится тестирование всего блока функционала, затронутого изменениями.

                  Как вы это отслеживаете? Один кусок кода может затронуть многие места в других участках. неужели вы как-то документируете какие куски кода используете в других?

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

                  Я правильно понял, что по сути ваши тестировщики теперь должны войти в роль и тестировать приложение, играя роль определенной группы пользователей? Если да, то чем тогда это отличается от конкретных сценариев использования? Зачем делить на группы, если и так одна из задач тестировщика — предусмотреть возможные варианты использования сервиса (которые как раз и включают в себя варианты той или иной группы)?

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

                  Only users with full accounts can post comments. Log in, please.