пятница, 24 января 2020 г.

Как нарисовать карту приложения (mind map)


Мы (тестировщики) рисуем карты для того, чтобы показать их коллегам. Чтобы новичков по ним знакомить с проектом. Или чтобы показать аналитику для уточняющих вопросов «а я правильно понял, что...»?

Давайте разберемся, как нарисовать Mind Map по проекту. И как сделать карту простой и понятной. А, главное — нужной!







1. Изучите ваше приложение


Прочитайте ТЗ. Задайте вопросы аналитику. Да просто потыкайте систему и посмотрите, что она умеет. 

Статьи в помощь:

2. Выделите основные функции 


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




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

А второстепенные сценарии — регистрация, публикация фоточек, обмен мнениями и всякое такое. Их оформляем после основных.


3. Запишите цели через глаголы


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

Стремитесь использовать глаголы, а не существительные — то есть названия функций, а не разделов. Не "настройки" (описание кнопки), а "настраиваем приложение под себя" (цель пользователя).


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

И еще раз акцент на то, что мы пишем цели через глаголы. Есть очень важное правило:


Не надо рисовать интерфейс!


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

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

Это очень частая ошибка у студентов. Нужно нарисовать карту приложения? Просто перепишем все кнопочки! А нужно анализировать продукт, без этого никак.


4. Расставьте приоритеты


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

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



См также:
Зачем вообще нужны программы — отталкивайтесь от истинных нужд пользователя!

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


Я специально делаю акцент на авторизации, потому что она есть почти в любом приложении. И часть студентов отстаивает право на приоритетность этой функции:

— Но ведь функция есть! И она очень важна! Я не могу сделать покупку без нее. Значит, она главная.

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

В ряде интернет-магазинов вообще отказались от авторизации, можно сделать заказ и без нее. Что правильно. А то ради одного заказа раз в десять лет нужно зарегистрироваться и спам еще потом от них терпеть... В общем, чем меньше действий — тем лучше!

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


Пример: онлайн-игра


Пример любезно предоставлен некогда тестировщиком игр Ольгой Алифановой:

Я прихожу в онлайн-игру прокачивать своего персонажа. Общаться. Вступать в противостояние с другими персонажами. Исследовать мир. Настраивать игру под себя. Это верно для 90% больших онлайн-игр, могут быть еще дополнительные стремления "Украшать мир под себя" (довольно юное поколение игроков этим занимается, в Perfect World были любители домиков и платьюшек, которым драить монстров было неинтересно, а вот платьюшки собирать таки да), от игры зависит. 



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

Обратите внимание, я нигде в этом примере интерфейс не отрисовываю. Я не пишу "Профиль. Главный экран. Экран параметров персонажа. Чат". Потому что я анализирую именно суть продукта, а не подробности его визуальной реализации. 



Хорошие примеры карт








Еще больше примеров хороших карт вы можете найти в конфлюенсе в разделе «Работы студентов: Майнд-карты». 

Этот раздел я периодически обновляю и пополняю, так что ищите хорошие примеры там!


Итого


Не надо скрупулезно записывать интерфейс. Карта вида "Каталог: для женщин - джинсы, брюки, юбки, ..., для мужчин - ..., для детей - ..." — это зарисовка интерфейса. Карта вида "Просмотр товаров: по полу, по категории, по материалу" — это анализ продукта.

Для чего приходит пользователь? Для, скажем, просмотра ассортимента. Как он сможет его просмотреть? Например, вот так. Как это будет реализовано или уже реализовано — разделами каталога ли, фильтрами ли, еще каким-нибудь удивительным способом — нам не важно.

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

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

Такая карта позволит:
  • понять, зачем именно нужно приложение, даже если я его никогда не видела;
  • составлять тест-кейсы и чек-листы. Можно просто брать название ветки — и вот он, тест-кейс!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков

9 комментариев:

  1. Ольга, спасибо за статью. Вы мне открыли новый способ использования и составления карт) Такой способ мне понятен, но вот допустим ситуация: у меня есть система с неким базовым функционалом. Мне нужно добавить в систему новую функцию, чтобы пользователи могли решить свою задачу. Проектируя новый функционал, я добавляю новые фичи, элементы интерфейса, а так же изменяю существующую логику и интерфейс. Исходя из прочитанного я бы выбрала функциональную MM, но как в ней отобразить изменения интерфейса и базового функционала? Пока воспринимаю карту именно как статичное перечисление возможностей системы. Но вот не понимаю, как в ней увидеть, какие изменения я вношу - в функциональность и внешний вид, какие кнопки добавляю. Может я не до конца понимаю суть инструмента? Вообще по каким принципам, основаниям еще можно строить карты? Бывают ли смешанные карты?

    ОтветитьУдалить
    Ответы
    1. Если вы рисуете именно функциональную карту, то изменения интерфейса там отобразятся "никак" )) Потому что интерфейса там в принципе нет.

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

      Удалить
    2. Этот комментарий был удален автором.

      Удалить
    3. я поняла, спасибо за пояснение, не ожидала, что вы так быстро ответите =)

      Удалить
  2. Ольга, спасибо за статью. Но все примеры на интуитивно понятных приложениях. А как поступать с enterprise приложениями? Вот проект, у него 5 скрам команд и 10 лет работы например. А это еще что-нибудь с медициной связано и отдела тестирования не было=/

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

      Удалить
  3. Опечатка: "... вы можете найти в кофнлюенсе ...". Нужно исправить на "... конфлюенсе ...".

    ОтветитьУдалить