Сценарий тестирования прототипа пример

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

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

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
• Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

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

• Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
• Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
• Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
• Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
• Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

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

1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
6. Проверить Забыли пароль работает как положено
7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска

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

Зачем тестировать прототипы?

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

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

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

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

Какой инструмент для подготовки интерактивного прототипа лучше?

Мы, как и большинство наших клиентов, используем два инструмента: Invision и Figma, у каждого есть свои преимущества и недостатки.

Figma — наверное, самый часто используемый инструмент. Его любят за удобство использования, богатую функциональность и возможность коллаборации. Но интерактивные прототипы, созданные в Figma, могут медленно загружаться (30-50 секунд), особенно на старых смартфонах. Это сильно раздражает респондентов, а если вы проводите немодерируемое тестирование, респондент может просто не дождаться загрузки и уйти.

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

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

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

Как готовить прототип для юзабилити-тестирования?

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

Правильная последовательность действий такая:

Как формулировать задания при тестировании прототипов?

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

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

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

Чем тестирование прототипов принципиально отличается от тестирования «живой» системы?

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

Действительно принципиальные отличия — это количество респондентов и фиксация юзабилити-метрик.

При тестировании прототипов важно быстро найти критичные проблемы и быстро их исправить. Поэтому к этому типу исследования хорошо подходит методология RITE (Rapid Iterative Testing and Evaluation): вы проводите тестирование на 2-3 респондентах, исправляете обнаруженные проблемы, затем проводите следующую итерацию и так далее, пока несколько пользователей подряд не смогут пройти сценарий без существенных затруднений.

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

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

Можно ли проводить немодерируемые тестирования прототипов?

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

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

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

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

Вместо заключения: как внедрить тестирование прототипов в процесс разработки

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

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

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

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

Рецепт есть: тестировать продукт перед выходом на рынок.

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

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

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

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

Но так не работает.

В реальности лучше потратить 30 минут на тестирование прототипа на пользователях, чем сделать дизайн, сверстать, запрограммировать, а потом обнаружить, что нужно все [censored] переделывать!

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

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

Бумажный прототип

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

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

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

Из опыта

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

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

• один «робот»,
• один модератор,
• один наблюдатель.

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

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

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

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

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

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

Интерактивные прототипы в мелкой детализации

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

Для чего плохо подходят такие прототипы:

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

Контент в таких прототипах должен быть максимально приближен к реальному.

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

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

Так делать не стоит. Да и зачем, если очень просто найти «рыбу» по теме:

• взять текст на fishtext.ru;
• скачать картинки с Яндекс.Картинки;
• поставить стандартные иконки Bootstrap;
• разместить фотографии пользователей из поиска по людям ВКонтакте;
• написать максимально реальные заголовки, чтобы потом не оказалось, что они не входят в ширину экрана.

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

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

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

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

Тестирование цветного прототипа в программах типа Axure

Тут всё достаточно просто. Дизайнер делает красивый интерфейс, в котором вы размечаете области, при взаимодействии с которыми должно что-то происходить. Обычно это просто «on click» или «on move». Можно, конечно, поколдовать с резаком и вырезать различные элементы, но это слишком долго. Хотя есть и такие перфекционисты.

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

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

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

Такое тестирование помогает оценить:

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

Если пользователь не замечает нужные элемент или кликает почём зря — значит, нужно править.

Учтите, что во время тестирования UI- или графический дизайнер, который это всё делал, должен молчать, а лучше вообще быть далеко от респондентов. Если рядом, то только с выражением «poker face». Ему будет сложно, он периодически будет хвататься то за топор, то за верёвку с мылом, так что лучше всего его держать чуть в стороне от самого процесса тестирования дизайна на пользователе.

Тестирование со скриптами, или MVP-тестирование на alfa-версии продукта

Всё работает как нужно, но пока вместо 1 млрд пользователей у вас 5 человек — друзей проекта, вместо базы в 5 млн SKU у вас пока 1 база на 100 товаров, а вместо выделенных серверов на Амазоне, виртуальный хостинг на 1gb.ru. Но всё работает как нужно.

Всё работает как нужно. Это главное условие!

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

Ещё раз для тех, кто хитрый. Тестировать надо на ЦА! Не тестируйте свой продукт на работниках столовой у вас в офисе, если ЦА — это девушки с «Барвиха Лухари Вилаж».

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

Главное, чтобы всё работало так же, как и в вашем будущем суперкалькуляторе плотности пыли 1 грамма песка Сахары. Можно также заменить готовыми решениями, которые есть на рынке.

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

Решение:

• делаете за 500 $ мобильную версию сайта с той же функциональностью;
• проверяете, чтобы работало так, как нужно;
• тестируете на ЦА;
• выкладываете в дорогую разработку. Или не выкладываете — зависит от результата.

Тестирование на Big Data

Это путь Яндекса и больших компаний: придумать быстрое решение, выпустить бета-версию, сделать пререлиз, пустить миллионный суточный трафик и смотреть, как всё работает.

Здесь я не буду останавливаться, потому как это вариант вам вряд ли подойдёт. Разве только вы из компании с большим трафиком и командой из: UI-дизайнера + быстро-верстальщика + быстро-программиста + быстро-BigData-спеца + быстро-продюсера + быстро-сис. админа + быстро-арт-дира.

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

Тестирование имеющегося продукта

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

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

Для этого требуется:

• сайт или приложение,
• целевая аудитория;
• юзабилити-исследователь;
• личное присутствие в месте обитания ЦА или Skype.

Берём, что есть, приглашаем ЦА на тестирование (или на Skype-сессию), смотрим на экране, что делает респондент. Он в этом время проговаривает действия и мысли, мы записываем косяки, составляем статистику по ошибкам.

Метод особенно рекомендуется тем, кто думает что у них плохо работает функциональность, потому что так думает сын директора (который уже через 20 лет станет великим дизайнером). Тестируем то, что есть, и видим косяки. Реальные косяки. Всем, например, безразлично, что у вас сайт бирюзовый, и что кнопочки на нем не в Material Design, а с градиентом 90-х годов. А вот баги всем заметны. Кстати, это очень хороший способ отсеивать визуальных перфекционистов, которым не нравится цвет менюшки, а также компании, которые проводят «usability-аудиты» силами аккаунт-менеджера, который вышел на работу неделю назад.

Есть еще один метод…

Называется «Прототип из разной дешевой фигни», но подходит больше для промышленного дизайна. Используется, например, IDEO. Но в рамках этой дискуссии не буду об этом говорить, так как не про дизайн-мышление мы тут.

Вывод

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

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

Однако если вы не предложите протестировать продукт на прототипах, вряд ли руководство об этом узнает. Вряд ли вообще кто-то знает, что можно пойти путем такого тестирования: проверить на пользователях ранние решения и исправить основные косяки, которые будут совершать 9 из 10 пользователей. Или 7 из 10. Или всего лишь 1 из 10 — всего-то каких-то 10% рынка.

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

Так что всё зависит от вас.

Нетология проводит набор на курсы:

• Проектирование интерфейсов: UI-UX дизайн от стратегии до тестирования;
• UX-аналитика: исследования пользователей и здравый смысл;
• Дизайн мобильных приложений: интерфейсы, архитектура, визуальная концепция;
• Adobe XD: основы для дизайнера интерфейсов (бесплатная программа);
• Курс Python: программирование на каждый день и сверхбыстрое прототипирование.

← Назад

(Перед вами бесплатный курс от InVision Studio «Дизайн-мышление». В курсе 6 глав. Если вы здесь впервые, то лучше начните сначала)

Вы читаете перевод руководства “Design Thinking”. Над переводом работали: Федор Фоминых и Ринат Шайхутдинов.

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

Обычно, на среднестатистическом велотренинге всё довольно однообразно-темная комната, ритмичная музыка и истошные вопли инструктора — «переключай на восьмёрку и дави дальше!» Компания SoulCycle предложила кое-что совсем другое.

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

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

«Каждый понедельник в полдень SoulCycle обновляет расписание на следующую неделю. Вы сидите у компа и долбите по клавиатуре как охотник за фарфоровыми статуэтками на eBay. Не успел нажать — твои проблемы».

— Из статьи Vanity Fair о SoulCycle

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

За разработкой обратились к агентству Prolific Interactive. Агентство использовало принципы дизайн-мышления на всех этапах пути от исследования пользователей на принципах эмпатии до тестирования и получения отзывов от заинтересованных сторон. Для работы дизайнеры Prolific Interactive активно использовали InVision.

Люди из команды Prolific два раза в неделю приходили в SoulCycle. Они стояли на ресепшене, брали интервью у основателей, сотрудников, постоянных посетителей, делали всё для того, чтобы изнутри понять как работает компания. Когда необходимая информация была собрана они начали работу над первоначальной версией.

Техника: Мышление новичка

Технику «мышление новичка» можно применять на любом этапе проектирования. Чтобы быстро протестировать первые версии и не теряться в догадках, в команде Prolific решили посмотреть на проблему свежим взглядом. Учитель дзен Сюнрю Судзуки пишет следующее:  «у новичка в голове таится много возможностей, в голове эксперта — намного меньше».

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

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

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

Тестируйте раньше, тестируйте чаще

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

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

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

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

Кристин Ли, Prolific Interactive

Ребята из Prolific делали прототипы и сразу же выкладывали их для тестирования на сайте. Слава богу под рукой было достаточное количество пользователей. SoulCycle призвали всех гонщиков как можно активнее тестировать прототипы (но, конечно не в ущерб личному времени). Преимуществом было то, что тестирование проходило в контексте максимально похожем на реальное бронирование.

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

И вот, мы начали тестировать прототипы для гонщиков из SoulCycle. Мы тогда быстро поняли что им реально мешает: отвлечённость, плохой интернет, нехватка времени. После тестирования на живых людях нам пришлось изменить многие наши предположения. А чтобы увидеть как наш дизайн вписывается в условия реального мира (культуру) нам пришлось отключить внутри себя все мысли связанные с дизайном.

Кристин Ли, Prolific Interactive

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

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

Совет: Сохраняйте мышление новичка

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

Даниэль Бурка, Google Ventures

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

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

Результаты превзошли все ожидания! Участник проекта Горен Гордон потом вспоминал: Спустя какое-то время они начали его обнимать, хватать, повторять его движения и всё это без какого-либо постороннего вмешательства. Tega смог очаровать малышей тем, что он действительно вёл себя как живой, когда видел что-то интересное он наклонялся или издавал радостные звуки.

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

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

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

Собственно это и сделала команда Google Ventures, чтобы помочь робототехнической компании Savioke.

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

Этапы тестирования прототипов

1. Определение цели

Что именно мы тестируем и что именно мы хотим узнать? Это определит все дальнейшие шаги: вопросы которые мы задаём, людей которых мы привлекаем, и то как мы измеряем полученный результат.

2. Подбор пользователей

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

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

В книге Эрики Холл Just Enough Research вы найдёте сразу несколько классных советов на тему привлечения пользователей. Чтобы привлечь действительно ценных пользователей она советует задавать совершенно чёткие параметры для поиска. Например: «разделяет проблемы и потребности целевой аудитории» или «способен четко излагать их мысли». Кроме того, она учит как поставить на входе своего рода фильтр который мог бы отсеивать особо упоротых маньяков и непонятных индивидов с путанными мыслями.

Она подкидывает отличные идеи насчёт того, где можно разместить ссылку для скринирующих опросов. Ближайшее окружение может также послужить отличным ресурсом для пополнения рядов привлечённых пользователей. (при условии что они попадают в целевую аудиторию и что вы умеете пользоваться соцсетями и Craigslist)

Если вам предстоит проводить дистанционное тестирование то можно воспользоваться сервисами по типу ethn.io и UserTesting — они умеют достаточно точно подбирать пользователей.

3. Методы исследований: юзабилити-тестирование

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

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

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

На следующем этапе наблюдая как пользователи контактируют с прототипом постарайтесь использовать аудио и видеозапись. Слишком сильно не изголяйтесь — используйте смартфон или запись экрана на компе.

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

4. Упаковка результатов исследований

После тестирования обязательно найдите время чтобы проанализировать и упорядочить полученные результаты. Для этого хорошо подойдёт ресурс Just Enough Research. Эрика Холл в разделе про анализ данных пользовательских исследований описывает как правильно построить сеанс (структурировать цели, цитаты пользователей и наблюдения). Как приготовить среду для тестирования и необходимые материалы (стикеры, маркеры). И наконец, как определить какой тип данных вас интересует (цели пользователей и приоритеты).

Ещё один полезный ресурс в помощь для анализа и упорядочивания данных от Брендана Маллигана из Cluster. Он делится советами и способами как провести собрание по сбору информации от команды и как правильно разложить по полочкам собранную информацию.

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

Сопереживание и сострадание — это основа дизайна

Мышление новичка основано на человеческом сопереживания. Когда наше мышление умеет сопереживать оно поистине безгранично.

Сюнрю Сузуки, Наука Дзен. Ум новичка

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

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

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

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

← Назад | Спасибо за внимание.

Введение в тестовый сценарий

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

Зачем создавать тестовые сценарии?

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

Причина их создания заключается в следующем:

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

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

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

Как тестовые сценарии могут быть написаны?

Следующие шаги могут быть выполнены тестером для создания тестовых сценариев:

• Шаг 1: Документ о требованиях, таких как Спецификация бизнес-требований (BRS), Спецификация функциональных требований (FRS) и Спецификация системных требований (SRS) приложения, подлежащего тестированию, следует внимательно и тщательно прочитать. Руководства, книги, варианты использования и т. Д. Тестируемого приложения могут быть отнесены к тому же.
• Шаг 2: Все возможные цели и действия пользователя должны быть правильно определены для каждого требования. Все технические характеристики каждого требования также должны быть определены.
• Шаг 3: Все возможные причины взлома системы и оценки пользователя должны выполняться с точки зрения хакера. Оценка пользователя может быть выполнена путем нахождения всех возможностей пользовательского управления приложениями.
• Шаг 4: Полный список всех возможных тестовых случаев для проверки всех функциональных возможностей приложения должен быть составлен после полного прочтения документа с требованиями и завершения анализа.
• Шаг 5: После привлечения всех из них для проверки соответствия требования и его сценария тестирования должна быть создана матрица отслеживания.
• Шаг 6: Все созданные тестовые сценарии проверяются и оцениваются супервизором. Это также дополнительно проверяется всеми заинтересованными сторонами.

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

Примеры

Ниже приведены несколько примеров сценария тестирования.

Тестовый сценарий для интернет-магазина приложений Buykart

Сценарии тестирования, которые можно принять во внимание при проверке приложения для онлайн-покупок Buykart, следующие:

Тестовый сценарий 1: проверка работоспособности входа

Тестовые случаи, которые можно рассмотреть для создания:

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

Тестовый сценарий 2. Проверка функциональности поиска

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при поиске действующего товара.
• Поведение приложения при поиске недействительного продукта.

Тестовый сценарий 3: проверка деталей продукта

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе продукта.
• Поведение приложения продукта в списке пожеланий.
• Поведение приложения при добавлении товара в корзину.
• Поведение приложения при выборе опции «Купить сейчас».
• Поведение приложения при вводе неверного адреса.
• Поведение приложения при вводе действительного адреса.
• Поведение приложения при проверке нескольких вариантов оплаты.

Тестовый сценарий 4: проверка функциональности платежа

Тестовые случаи, которые можно рассмотреть для создания:

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

Тестовый сценарий 5: проверка функциональности деталей заказа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе каждого заказа.
• Поведение приложения при выборе опции «Возврат товара».
• Поведение приложения при выборе опции отслеживания товара.
• Поведение приложения при выборе опции «Обзор продукта».

Вывод

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

Рекомендуемые статьи

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

1. Стресс нестабильности работы
2. Мотивированный и посвященный
3. Что такое Agile Testing?
4. Как написать контрольный пример?

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

Отличный сценарий тестирования юзабилити прост и поучителен

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

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

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

1. Справочная информация

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

2. Введение

Пример вводного раздела из скрипта тестирования юзабилити.

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

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

Также важно запросить согласие на запись сеанса. Убедитесь, что получили явное устное согласие на это.

СОВЕТ. Во время личного модерируемого теста вы должны дать участникам возможность задать любые вопросы перед началом.

3. Предварительная проверка анкеты

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

В сценарий теста юзабилити вы включите вопросы об основной информации, такой как имя, возраст, род занятий и любые другие демографические данные, относящиеся к вашему тесту. Во время модерируемых тестов достаточно запросить подтверждение (например, «Пожалуйста, подтвердите, что вас зовут [ИМЯ].») Уже имеющейся у вас информации.

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

4. Задачи и сценарии

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

• Цель теста: просмотреть гостиничные номера и забронировать один.
• Пример плохой задачи: забронировать номер в отеле.
• Пример лучшего задания (со сценарием): вы планируете отпуск в Бангкок с 3 по 14 сентября. Вам нужно забронировать отель для вашего пребывания. Зайдите в приложение, просмотрите информацию и забронируйте номер, который вы считаете лучшим.

СОВЕТ: всегда позволяйте пользователям возвращаться и читать задание столько раз, сколько им нужно.

Советы по написанию лучших заданий

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

1. Сделайте задачу реалистичной, чтобы помочь участникам взаимодействовать с интерфейсом. Создавайте сценарии, максимально имитирующие реальный мир. Не заставляйте их делать то, чего они обычно не делают. Например:
   • Цель теста: просмотреть продаваемые товары на site.com .
   • Пример плохой задачи: купите пару белых высоких джинс Levi’s которые в продаже.
   • Пример лучшей задачи: купите пару джинсов Levi’s менее чем за 20 долларов .
   • В реальных условиях пользователи, вероятно, будут просматривать, прежде чем выбрать то, что они хотят купить. В первом примере мы не предоставляем пользователю возможность выбирать то, что он обычно выбирает. Вместо этого мы говорим им, что делать. Они сосредоточатся на поиске джинсов, которые мы им сказали найти, и могут не взаимодействовать с интерфейсом так, как обычно.

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

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

4. Не облегчайте задачу участникам, используя тот же язык, который они могут легко найти в тестируемом интерфейсе. Например, если интерфейс демонстрирует кнопку с надписью «Пользуйтесь месяц бесплатно», вам не следует использовать эту же формулировку в задании:
   • Цель теста: попробуйте сервис бесплатно.
   • Пример плохого задания: зайдите на сайт и пользуйтесь бесплатно в течение месяца .
   • Лучший пример задачи: вы хотите попробовать этот сервис в первый раз. Зайдите на сайт и зарегистрируйтесь.

5. Будьте максимально прямыми в том, как вы формулируете задачи. Посмотрите на эти два примера задачи:
   • Цель теста: записаться на прием.
   • Пример плохой задачи: теперь, посмотрите, можете ли вы попытаться найти способ записаться на прием к диетологу.
   • Пример лучшего задания: теперь, записаться на прием к диетологу.
   • Первая из них с дополнительной фразой «посмотрим, сможете ли вы попытаться найти способ», создает впечатление, что задача будет трудной для выполнения, или даже подсказка, которая может ожидать определенного ответа, поскольку интерфейс имеет плохой опыт или дизайн.

СОВЕТ: При необходимости вы можете задавать вопросы между заданиями. Лучше подождать, пока участник выполнит задание, чтобы не отвлекать их.

5. Пост-тестовая анкета

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

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

6. Подведение итогов

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

Any capability that may be tested is defined as a TEST SCENARIO. It’s also known as Test Possibility or Test Condition. As a tester, you should put yourself in the shoes of the end user and determine the Application Under Test’s real-world scenarios and use cases.

In liner statements, a test scenario is a complete list containing test cases that cover end-to-end functionality of a software program. A scenario is defined as a liner statement. The test scenario is a classification of testable requirements at a high level. These criteria are categorized according to a module’s functionality and derived from use cases.

Because there are so many test cases in the scenario, there is a thorough testing process. The tester must evaluate the test cases for each scenario before completing the test scenario. Testers must put themselves in the shoes of the user in the test scenario because they are testing the software application from the user’s perspective. The most important aspect of the process is scenario preparation, which necessitates seeking advice or assistance from customers, stakeholders, or developers.

Important − Because the text scenario process does not include navigation steps or input, the test execution process cannot be done.

These are high-level documents that describe all of the conceivable permutations or various ways or combinations of utilizing the application, with the primary goal of understanding the application’s general flow.

Method of Writing Test Scenario

To build Test Scenarios as a tester, follow these steps —

• Examine the software’s requirement documents, such as SRS (System Requirement Specification), the BRS (Business Requirement Specification), and FRS (Functional Requirement Specification). You could also consult the application’s use cases, books, manuals, and other resources.

• For each requirement, determine all technical aspects and objectives.

• Find every feasible way for the user to interact with the software.

• Determine all possible scenarios in which the system could be exploited, as well as users who could be hackers.

• Make a list of various test cases to check each function of the software after reading the requirement document and completing the scheduled analysis.

• Create a traceability matrix after you’ve identified all of the possible test scenarios to see if each requirement has a matching test scenario or not.

• All possibilities are reviewed by the project supervisor. They are then evaluated by the project’s other stakeholders.

When writing test cases, we had to observe a few rules —

• Always keep a list of the most frequently utilized features and modules.

• We usually begin the scenarios by selecting modules one by one, in order to maintain a good sequence and avoid missing any module levels.

• Scenarios are usually defined at the module level.

• Delete scenario should always be the final resort; else, we will waste a lot of time re-creating data.

• It should be written in plain English.

• Every scenario should be written in a single or two-line format, try not to write in paragraphs.

• Do’s and checks should be included in every scenario.

Reason for creating Test Scenario

One test scenario can cover several test cases. As a result, Test Scenarios and Test Cases have a one-to-many relationship. However, the tester must consider each scenario when developing it. It was created by testers to test the application from the perspective of an end-user. Testers look for crucial information from all developers, stakeholders, and customers.

The following are the reasons for their creation −

• The design of excellent Test Scenarios ensures complete and proper Test Coverage.

• It is necessary to create them in order to investigate a program’s end-to-end functionality.

• They can be used to determine the most significant and critical end-to-end transactions or real-time application usage.

• They can be used as a tool for quickly determining testing workforce, which can then be utilized to assist clients or organizations with proposal creation and testing workforce organization efficiently and effectively.

• Approval of applications is done at multiple levels, including customers, business analysts, developers, and so on, to ensure thorough and proper testing.

When Test Scenario should not be created

There are some conditions in which its production should be prevented —

• It is unlikely to be developed in projects that use Agile Methodologies like Scrum.

• It may be avoided when the applications to be tested are unstable or excessively complicated, or when the project is in a critical-time state.

• Its creation may be prevented for regression testing or a new defect because substantial documentation of them would happen in previous test cycles in maintenance projects.

Features of Test Scenario

• The test scenario is a one-liner that directs testers through the testing process.

• The product’s complexity and repetition are reduced by using a test scenario.

• A test scenario is when you talk and think about tests in great detail yet write them down in liner statements.

• It’s a series of procedures threaded together.

• When the tester does not have enough time to write test cases and the team agrees on a comprehensive liner scenario, the test scenario becomes more significant.

• The test scenario is a useful activity for saving time.

• It is simple to maintain because adding and modifying test scenarios is simple and self-contained.

Test Scenario Examples

We’re using the Gmail application to create test cases for the most often used modules, such as Login, Compose, and inbox

Test Scenarios for the Login module

• Check that the home page is displayed after entering the correct login information (username and password).

• Check for the home page after entering the invalid Username and password.

• Check for an error message if you leave the username and password fields blank.

• Enter a valid Login, click Cancel, and look for the fields to be reset.

• Check that the account has been blocked by entering invalid Login more than three times.

• Check sure the Username is displayed on the home screen after entering a valid Login.

Test Scenario for compose module

• Checks if all users have access to the To, Cc, and Bcc email addresses.

• Check that the entire user has access to the To, Cc, and Bcc fields.

• Prepare a message, send it, and wait for a confirmation message.

• Compose an email, send it, and check the sender’s sent item as well as the inbox.

• Create a message, send it, and check for invalid and legitimate email addresses (valid format) in the sender’s inbox

• Check for conformation messages and check-in draft messages after composing main and then discarding it.

• After you’ve finished writing your email, save it as a draft and look for the confirmation message.

• Compose an email, shut it, and check for confirmation before saving it as a draft.

On the Inbox module, Test scenario.

• Check that all received mail is shown and highlighted in the inbox by clicking on it.

• Check that the sender email id for the most recent received email has been accurately displayed.

• Select the email, reply, and forward it; check the sender’s sent item and the receiver’s inbox.

• Examine any attached attachments to the email to see if they have been downloaded or not.

• Before downloading, be sure the attachment has been properly inspected for malware.

• Select the email, reply, and forward it, then save it as a draft. Check the Draft section for the confirmation message and checks.

• Check that all of the emails that have been marked as read have not been highlighted.

• Verify that all Cc recipients are visible to all users.

• Checks that all Bcc email recipients are hidden from the users.

• Select the message, delete it, and then check the Trash folder.