8 мая 2019

Юзабилити в руках QA, или Создай пользователя сам

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

Noveo Usability meet-up

Что любят QA-инженеры Noveo? Качественные фичи, чистый код, дружелюбные команды и, конечно, непрекращающиеся возможности для развития! Не секрет, что образовательные мероприятия — одна из важнейших частей профессиональной жизни компании: совместные походы на конференции и их трансляции, внутренние тренинги, стажировки и митапы — то, что позволяет заряжаться новыми силами и вносить в работу приятные нововведения.

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

Как тестировщик может внести вклад в удобство использования продукта

Тестировщики — одни из самых универсальных людей в проектной команде. Это и центр компетенций и знаний по проекту, и блюстители качества, и, что не менее важно, те, кто имеет доступ к приложению раньше всех, а значит, может (и должен!) найти ошибки раньше реальных пользователей.

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

  • низкий уровень: классы эквивалентности, анализ граничных значений;
  • средний уровень: комбинаторные техники, доменный анализ, pairwise;
  • высокий уровень: диаграмма переходов состояний, error-guessing, деревья принятия решений и сценарии использования.

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

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

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

  • кем является его пользователь;
  • какова цель пользователя (зачем он использует наше приложение?);
  • какие задачи стоят перед пользователем (что ему нужно сделать, чтобы достичь цели);
  • очень хорошо уметь приоритизировать сценарии в зависимости от цели и особенностей пользователя.

Noveo Usability QA meet-up

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

Что тестировщику надо помнить при создании пользовательского сценария?

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

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

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

4. Купер описывает 3 фазы: исследование, интервью и непосредственное наблюдение.
В случае для тестировщиков их аналогами могут стать изучение спецификации, разговор с заказчиком и исследовательское тестирование. Главное — собрать как можно больше информации о продукте — см. пункт 1.

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

Алан Купер выделяет 3 вида сценариев:

Noveo usability QA meet-up

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

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

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

  • заказать такси в любую точку города;
  • выбрать время подачи машины;
  • выбрать характеристики машины (класс, с багажом/без, молчаливый водитель…);
  • видеть стоимость поездки;

и многое другое, на что хватит нашей «пользовательской»” фантазии.

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

Персонажи и их мотивация

Noveo Usability QA meet-up

Но, если подумать, описанный выше пользователь слишком абстрактен для того, чтобы успешно создать сценарии с его участием. Например, люди 20 и 40 лет могут по-разному смотреть на одни и те же технологии, и что будет очевидно одним, вызовет у других затруднение и вопросы. Кроме того, одним людям важна представительность и возможность заказать машину высокого класса (например, для деловой поездки), другим — скорость моментальной подачи, третьим, наоборот, возможность заказать машину сильно заранее… Как же поступить, чтобы тестирование пользовательских сценариев принесло максимум пользы и помогло как можно лучше понять своих будущих юзеров?

Здесь на помощь приходит портрет пользователя, или так называемый персонаж.

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

О чем стоит подумать при создании персонажа:

  • возраст;
  • род занятий;
  • социальная роль (в контексте использования продукта);
  • интересы;
  • факторы, которые могут повлиять на его взаимодействие с системой;
  • зачем он использует наше приложение (цель!).

Таким образом, вместо абстрактного «человек 20-40 лет, без машины…» у нас появляется более частный пример одного из возможных пользователей:

  • Виктория, 28 лет;
  • тренер в фитнес-клубе;
  • использует приложение, чтобы добираться до работы (т.к. опаздывать нельзя!) и чтобы забрать ребенка из школы в конце дня;
  • иногда не имеет возможности забрать ребенка из школы вовремя и просит это сделать мужа;
  • муж Виктории работает вахтовым методом, поэтому бывают моменты, когда он уезжает в другой город и не может забирать детей из школы;
  • Виктория использует наше приложение, чтобы вовремя добираться до работы/до школы + чтобы иногда заказывать машину детям и видеть, где они едут.

Какие же сценарии будут актуальны для Виктории в роли пользовательницы приложения по заказу такси?

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

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

  • функции быстрого заказа такси (и быстрой подачи);
  • безналичная оплата поездки;
  • поездка с несколькими пунктами назначения;
  • возможность вызвать такси для другого пассажира;
  • геопозиционирование машины на карте, точность локации;
  • возможность выбрать детали поездки (водитель-женщина, детское кресло в машине, наличие/отсутствие багажа…).

А вот на эти части от лица Виктории мы будем смотреть менее внимательно:

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

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

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

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

Noveo Usability QA meet-up

Подведем итог

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

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

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

Noveo Usability QA meet-up

P.S. Практическое задание

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

Предположим, у вас есть следующие проекты:

  1. Веб-сервис для заказа продуктов с доставкой из ближайшего магазина.
  2. Мобильное приложение для поиска кратковременной подработки для студентов.

Задания:

  1. Выбрать один из проектов выше (если есть желание и силы, можно выполнить упражнение для обоих!);
  2. Создать портрет персонажа-пользователя выбранного сервиса;
  3. Описать повседневные и обязательные сценарии (по 2 сценария каждого вида);
  4. Привести пример нескольких исключительных сценариев;
  5. В рамках созданных на шагах 2-4 персонажа и сценариев описать, какие функции следует тестировать особенно внимательно.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: