Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.
Сценарии описывают пользовательские истории и взаимосвязи между ними. Они помогают определить, зачем и почему пользователи приходят на сайт и как достигают своих целей: совершают покупки, заказывают по телефону, сравнивают товары, общаются с консультантами.
Прежде чем разработать сценарий, нужно ответить на три вопроса:
1. Кто те люди, что заходят на ваш сайт?
Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.
2. Почему они заходят к вам?
На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.
3. Какие цели при этом преследуют и как их достигают?
Вариантов не так много, особенно если мы говорим о коммерческих сайтах. Обычные цели — изучить предложение с целью сравнить его с другими, непосредственно купить или сделать заказ, но возможны и другие варианты.
Пошагово достижение целей обычно расписывается в профилях задач. Здесь такая детализация не нужна, просто нужно понимать, какие шаги делает пользователь для достижения цели.
Сценарии помогают лучше понимать предпочтения посетителей сайта и анализировать пользовательский опыт. Это нужно, чтобы в дальнейшем проектировать сайт или интерфейс так, чтобы он вписывался в привычные для клиентов паттерны и приводил к цели посещения за наименьшее количество шагов и с минимальными затратами сил, времени и внимания.
Также сценарии используют для анализа пользовательского опыта при проведении юзабилити-тестов и других маркетинговых исследований.
Сценарий — наглядное схематическое представление того, как пользователь решает свою задачу с помощью сайта, что ему помогает и что мешает в достижении цели.
Пользовательские сценарии по степени детализации и технической проработки делятся на четыре группы.
Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.
Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.
Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».
Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:
Создаются с помощью объединения похожих пользовательских историй и отсечения лишнего и несущественного. Такой подход обобщает множество пользовательских историй в несколько сценариев. Например, таких: «Пользователь готовит деньги заранее, ищет через форму поиска, имеет ограниченный бюджет — сразу использует фильтры, принимает решение долго, несколько раз заходит в корзину и сравнивает товары».
А вот, например, шаги сценария, подготовленные при изучении сайта по аренде автокранов. Пользователи выделили вопросы, которые для них важны, теперь можно расписывать разные сценарии поведения.
Составляются уже с позиции персонажа (персоны покупателя). Еще меньше абстракции и больше конкретики. Каждой группе ЦА сопоставляется персонаж, далее прописывается его путь достижения цели.
Могут добавляться ограничения: например, проработка только варианта заказа с планшета или со смартфона.
Опишите пользовательский опыт по шагам: кто, каким образом и в какой последовательности делает. Это должен быть наиболее детализированный и технически проработанный вариант.
Пользовательские истории и концептуальные сценарии нужны для понимания основных мотивов пользователей и погружения в мир клиента. Конкретные сценарии и варианты использования уже могут использоваться для проектирования информационной архитектуры и интерфейсов, а также при проведении тестов и исследований юзабилити.
Единой формы для разработки пользовательских сценариев не существует. Поэтому итоговый результат может сильно отличаться.
«Общение» пользователя и терминала по приему платежей:
Еще сценарий от uxforthemasses.com:
Ручное
тестирование
пользовательского интерфейса
проводится тестировщиком-оператором,
который руководствуется в своей работе
описанием тестовых примеров в виде
набора сценариев.
Каждый сценарий
включает в себя перечисление
последовательности действий, которые
должен выполнить оператор и описание
важных для анализа результатов
тестирования ответных реакций системы,
отражаемых в пользовательском интерфейсе.
Типичная форма записи сценария
для проведения ручного
тестирования
– таблица, в которой в одной колонке
описаны действия (шаги сценария),
в другой – ожидаемая реакция системы,
а третья предназначена для записи того,
совпала ли ожидаемая реакция системы
с реальной и перечисления несовпадений.
В
табл. 19.1 приведен пример сценария
для ручного
тестирования пользовательского
интерфейса
[7].
|
Таблица |
|||
|
№ п/п |
Действие |
Реакция |
Результат |
|
1 |
Щелкните |
Появится |
Верно |
|
2 |
Введите |
Появится |
Неверно |
Ручное
тестирование пользовательского
интерфейса
удобно тем, что контроль корректности
интерфейса проводится человеком, т.е.
основным «потребителем» данной
части программной системы. К тому же
при чисто косметических изменениях в
интерфейсах системы, не отраженных в
требованиях (например, при перемещении
кнопок управления на 10 пикселей влево)
анализ успешности прохождения теста
будет выполняться не по формальным
признакам, а согласно человеческому
восприятию.
При
этом ручное
тестирование
имеет и существенный недостаток – для
его проведения требуются значительные
человеческие и временные ресурсы.
Особенно сильно этот недостаток
проявляется при проведении регрессионного
тестирования и вообще любого повторного
тестирования – на каждой итерации
повторного тестирования
пользовательского интерфейса
требуется участие тестировщика-оператора.
В связи с этим в последнее десятилетие
получили распространение средства
автоматизации тестирования
пользовательского интерфейса,
снижающие нагрузку на тестировщика-оператора.
19.1.3.2. Сценарии на формальных языках
Естественный
способ автоматизации тестирования
пользовательского интерфейса
– использование программных инструментов,
эмулирующих поведение тестировщика-оператора
при ручном
тестировании пользовательского
интерфейса.
Такие
инструменты используют в качестве
входной информации сценарии
тестовых примеров,
записанные на некотором формальном
языке, операторы которого соответствуют
действиям пользователя – вводу команд,
перемещению курсора, активизации пунктов
меню и других интерфейсных элементов.
При
выполнении автоматизированного теста
инструмент тестирования имитирует
действия пользователя, описанные в
сценарии,
и анализирует интерфейсную реакцию
системы. При этом для определения
ожидаемого состояния пользовательского
интерфейса могут использоваться
различные методы – либо анализ снимков
экрана и сравнение их с эталонными, либо
доступ к данным интерфейсных элементов
средствами операционной системы
(например, доступ ко всем кнопкам окна
по их дескрипторам и получение значений
текста).
И
при передаче информации в тестируемый
интерфейс и при получении информации
для анализа могут использоваться два
способа доступа к элементам интерфейса
[7]:
-
позиционный,
при котором доступ к элементу
осуществляется при помощи задания его
абсолютных (относительно экрана) или
относительных (относительно окна)
координат и размеров; -
по
идентификатору, при котором доступ к
элементу осуществляется при помощи
получения интерфейсного элемента при
помощи его уникального идентификатора
в пределах окна.
При
внесении изменений в пользовательский
интерфейс при использовании первого
метода в результате проведения
регрессионного тестирования будет
выявлено большое количество не прошедших
тестов – достаточно изменения
местоположения одного ключевого
интерфейсного элемента, как все сценарии
начнут работать неверно. Соответственно
при таком методе автоматизации
тестирования
необходимо менять значительную часть
сценариев
в системе тестов при каждом изменении
интерфейса системы. Такой метод
автоматизации
тестирования
подходит для систем с устоявшимся и
редко изменяемым интерфейсом.
Второй
метод автоматизации
тестирования
более устойчив к изменению расположения
интерфейсных элементов, но изменения
тестовых примеров могут потребоваться
и здесь в случае изменения логики работы
интерфейсных элементов. Например, пусть
в первой версии системы при нажатии на
кнопку «Передать данные» передача
данных начиналась сразу, и выводилось
окно с индикатором прогресса. Сценарий
тестового примера в этом случае включает
в себя имитацию нажатия на кнопку и
обращение к индикатору прогресса для
получения значения прогресса в процентах.
Соседние файлы в папке ++часть 2 Совр веб-техн
- #
- #
- #
- #
- #
- #
- #
- #
- #
Работа над User flow, пользовательским сценарием — важный этап создания интерфейса. User flow принимает различные формы в зависимости от этапа развития продукта. Расскажу, как тестировать сценарии в разных ситуациях и как это можно делать бесплатно. Пригодится людям, задействованным в создании интерфейсов: UI дизайнерам, менеджерам продуктов, UX исследователям.
Что такое User flow и почему сценарий важнее всего
User Flow — пользовательский сценарий иллюстрирует порядок действий, который пользователь выполняет для решения задачи. Сценарий — это скелет интерфейса, состоит из шагов — отдельных экранов. Удобный для пользователя интерфейс начинается именно с проработки user flow, структуры.
В оригинале пользовательский сценарий представляет собой блок-схему с логическими связями и пересечениями. Но тестировать сценарий в таком виде затруднительно и бессмысленно.
Интерфейс — это подход к решению задачи. Для проверки логики смотрим, насколько интерфейс выполняет свою функцию.
Для теста User Flow достаточно последовательных экранов или даже нарисованных от руки черновиков. Большинство дизайнеров, продактов и исследователей имеют дело уже с работающим цифровым продуктом, поэтому начнем именно с этой ситуации.
Задаем вопросы: общая оценка user flow готового продукта
Тестировании User Flow продукта — это гигиеническая норма. Для оценки общего уровня удобства важны количественные метрики. Подход к сбору данных зависит от исследовательской культуры и возможностей.
Для проверки сценариев достаточно провести онлайн опрос. Даем респондентам ссылку на продукт и задание. По итогу прохождения задаем вопросы из стандартной анкеты по оценке юзабилити (SUS). Полезно наравне с собственным продуктом тестировать прямых и косвенных конкурентов. В разнице оценок и содержится наиболее полезная информация.
Пример: летом 2019 года провели сравнительное исследование трех онлайн супермаркетов. За несколько часов получили общие метрики по удобству интерфейса, а из открытых ответов почерпнули информацию о разрывах в пользовательском сценарии.
Fastuna Task Flow Click (UX Benchmark) Ссылка на отчет
Я не смогла добавить все товары в корзину. При добавлении только 1 товара мне сразу предлагают оформить доставку, а я хотела добавить другие товары.
Женщина, 42
Опрос дает количественные оценки и прямую речь. Фиксируем показатели, которые отклоняются от нормы или результатов конкурентов. Изучаем упомянутые в открытых ответах проблемы. Полученных данных бывает достаточно для принятия бизнес решения. Если вопросы остались, то обращаемся к более глубоким методам исследований.
Наблюдаем за действиями: поиск проблемы в User Flow готового продукта
Предположим ситуацию: продукт функционирует без багов, но люди не доходят до выполнения целевого действия. Точного понимания причин нет. Поиск проблемы — это качественная, а не количественная задача, предполагает погружение в опыт отдельных людей. Здесь подходят два метода: модерируемые и немодерируемые юзабилити тесты. Первый метод быстр, доступен почти всем. Модерируемый тест способен дать более глубокие данные, но требует времени и специальных навыков.
Удаленное немодерируемое юзабилити тестирование
Немодерируемые тестирования занимают от одного до нескольких дней. Люди под запись экрана делают попытку выполнения задания, а потом дают обратную связь. Изучаем видеозаписи и пониманием, в чем заключена проблема: в логике user flow, в функциональных элементах или в оформлении интерфейса.
Решения Fastuna Problem Discovery (UX test). Фрагмент отчета по тесту пользовательского сценрария по поиску квартиры.
Модерируемое юзабилити тестирование
Применимо, когда есть потребность в большей детализации и погружении. Респондент получает задание, а интервьюер очно или онлайн наблюдает за человеком в режиме реального времени, задает уточняющие вопросы. Личные интервью с людьми — более трудоемкий и времязатратный метод, требует особых компетенций, но при правильном проведении дает ценную информацию. Модерируемые юзабилити интервью рекомендуем по возможности проводить с привлечением штатных сотрудников, погруженных в продукт.
При тестировании User Flow путем модерируемых и немодерируемых юзабилити тестирований важно помнить, что эти методы относятся к качественной методологии, служат для формулировки предположений, а не для проверки гипотез. На нескольких интервью вы найдете проблему, но не ее распространенность.
Фиксируем клики: тест User Flow на этапе разработки
Предположим, мы нашли проблему в пользовательском сценарии и работаем над улучшением User Flow. Новый пользовательский сценарий обретает плоть. Сначала в виде последовательных макетов. Мы не палим ресурсы разработки впустую, поэтому удостоверяемся, что новый вариант работает, люди понимают, куда нажимать на каждом шаге для выполнения задания, дойдут до конца маршрута.
Для количественной проверки гипотез, при оценке сценария на интуитивность подходит тест первого клика
Как это работает: даем 100-400 людям задание и последовательно показываем экраны интерфейса. На каждом экране человек делает только один клик, который приблизит к выполнению задания. По итогу получаем тепловую карту кликов на каждом шаге. Видим, на каком этапе пользовательского сценария возникает больше всего затруднений.
Пример: я тестировал пользовательский сценарий по поиску дверной ручки на сайте строительного гипермаркета. На втором шаге сценария, при попадании в каталог 71% ищут дверные ручки в разделе двери и окна. И лишь 6% в скобяных изделиях, где они и находятся. Вывод: интерфейс не решает задачу для сценария по поиску этого товара.
Выводы
Если задача — общая оценка то из исследований наиболее релевантен опрос с применением классической шкалы SUS или ее разновидностей.
Если на этапе готового продукта ищем проблему в User Flow, то в зависимости от требуемой детализации и ресурсов используем немодерируемое или модерируемое юзабилити тестирование.
На этапе разработки, когда user flow представлен в виде последовательных экранов рекомендую тест первого клика — он покажет, на каком шаге люди теряются, поможет при размещении кнопок.
Обещанный лайфхак: перечисленные решения доступны бесплатно. Fastuna специализируется на готовых решениях на базе онлайн панели. Но при использовании собственной базы все решения можно использовать бесплатно. Каждой компании доступно 500 интервью в месяц. Да, это касается даже немодерируемых юзабилити тестирований с записью экрана.
Что такое тестовый сценарий?
Тестовый сценарий определяется как любой функции , которые могут быть проверены. Это также называется условием проверки или возможностью проверки . Как тестер, вы должны поставить себя на место конечного пользователя и выяснить реальные сценарии и варианты использования тестируемого приложения.
Что такое тестирование сценария?
Тестирование сценариев — это вариант тестирования программного обеспечения, в котором для тестирования используются сценарии. Сценарии помогают в более простом способе тестирования более сложных систем
Давайте изучим это с помощью видео ниже —
Зачем создавать тестовые сценарии?
Тестовые сценарии создаются по следующим причинам:
- Создание тестовых сценариев обеспечивает полное покрытие тестами
- Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
- Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
- Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
- Для изучения сквозного функционирования программы, тестовый сценарий имеет решающее значение.
Когда не создать тестовый сценарий?
Тестовые сценарии не могут быть созданы, когда
- Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
- Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
- Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.
Как написать тестовые сценарии
Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев:
- Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
- Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
- Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
- Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
- Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.
Советы по созданию тестовых сценариев
- Каждый тестовый сценарий должен быть привязан как минимум к одному требованию или пользовательской истории в соответствии с методологией проекта.
- Перед созданием тестового сценария, который проверяет несколько требований одновременно, убедитесь, что у вас есть тестовый сценарий, который проверяет это требование изолированно.
- Избегайте создания слишком сложных тестовых сценариев, охватывающих несколько требований.
- Количество сценариев может быть большим, и запускать их все дорого. Исходя из приоритетов клиента, запускайте только выбранные тестовые сценарии
Пример 1. Сценарий тестирования для приложения электронной коммерции
Для приложения электронной коммерции несколько тестовых сценариев
Тестовый сценарий 1: проверка функциональности входа
Чтобы помочь вам понять разницу между сценарием тестирования и тестовыми сценариями, для этого сценария тестирования будут использоваться конкретные тестовые сценарии.
- Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
- Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
- Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
- Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
- Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
- Проверить Забыли пароль работает как положено
- Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
- Проверять поведение системы, когда установлен флажок «Держать меня в подписи»
Как видно, тестовые случаи являются более конкретными.
Тестовый сценарий 2. Проверка функциональности поиска
Тестовый сценарий 3: проверьте страницу описания продукта
Сценарий тестирования 4: Проверьте функциональность платежей
Тестовый сценарий 5: проверка истории заказов
Помимо этих 5 сценариев, здесь приведен список всех других сценариев.
- Проверьте поведение домашней страницы для постоянных клиентов
- Проверьте категорию / страницы продукта
- Проверьте службу поддержки / контактные страницы
- Проверьте страницы ежедневных предложений
Пример 2: Тестовые сценарии для банковского сайта
Тестовый сценарий 1 : Проверьте функциональность входа и аутентификации
Тестовый сценарий 2 : Проверить перевод денег можно
Тестовый сценарий 3. Проверьте выписку со счета.
Тестовый сценарий 4 : Проверка фиксированного депозита / периодического депозита может быть создана
И так далее…
Шаблон сценария тестирования
Скачать шаблон тестового сценария Excel (.xlsx)
Получение отзывов пользователей всегда было центральным в том, как мы создаем привлекательные приложения, которые приносят бизнес-ценность для клиентов и передают восхитительный пользовательский опыт. Мы делаем это, чаще всего, путем тестирования пользователями приложения. Электронная книга, «Практическое руководство по тестированию пользователей приложений», предлагает пошаговое руководство для дизайнеров и групп разработчиков, как проводить пользовательское тестирование в модерируемых и немодерируемых (онлайн) тестах. В этом посте мы рассмотрим один из ключевых компонентов: как написать эффективный сценарий тестирования юзабилити.
Отличный сценарий тестирования юзабилити прост и поучителен
Почему важно, чтобы у модераторов был сценарий, который нужно соблюдать в пользовательских тестах? Во-первых, вы хотите, чтобы ваши тесты были как можно более стандартными. Это гарантирует, что вы не будете смещать ответы отдельных участников. А уверенность в том, что каждый пользователь отвечает на одни и те же вопросы, гарантирует, что вы сможете увидеть сходства и различия в ваших пользовательских ответах, что поможет вам сделать более убедительные выводы из своего исследования.
В конечном счете, сценарий должен быть простым, но содержать достаточно инструкций, чтобы помочь фасилитатору направлять участников во время модерируемой сессии — или предоставлять всю информацию, которую участники должны знать на немодерируемых (онлайн) сессиях. Вот разделы, которые должен включать документ сценария, с рекомендациями о том, что включать в каждый из них:
СОВЕТ: чтобы сделать сценарий более легким для чтения во время модерируемого теста, используйте другой стиль текста или цвет, чтобы отделить инструкции от реального сценария, который будет прочитан участнику.
1. Справочная информация
Этот раздел предназначен для фасилитаторов и всех, кто читает сценарий теста юзабилити, но не делится с участниками теста. Обычно мы включаем справочную информацию о датах тестирования, клиенте, количестве и типе участников, истории версий и методологии тестирования. Мы также опишем, что вы тестируете, цели теста и сколько времени это должно занять для каждого участника. Также полезно включить информацию о поощрениях участников и компенсации.
2. Введение
Пример вводного раздела из скрипта тестирования юзабилити.
В этом разделе представлен скрипт для модератора, который приветствует участников и дает им общее представление о том, чего ожидать в тесте. Если тестирование проходит проверку модератором, мы также представляем координатора и все участвующие компании.
На этом этапе полезно сообщить участникам, что нет правильных или неправильных ответов. Это поможет им чувствовать себя более комфортно. Кроме того, поощряйте пользователей говорить вслух во время выполнения заданий. Вы захотите понять их мыслительный процесс, их действия и их чувства.
Также важно запросить согласие на запись сеанса. Убедитесь, что получили явное устное согласие на это.
СОВЕТ. Во время личного модерируемого теста вы должны дать участникам возможность задать любые вопросы перед началом.
3. Предварительная проверка анкеты
В этом разделе пользовательского теста ваша основная цель — сделать так, чтобы ваши участники чувствовали себя комфортно.
В сценарий теста юзабилити вы включите вопросы об основной информации, такой как имя, возраст, род занятий и любые другие демографические данные, относящиеся к вашему тесту. Во время модерируемых тестов достаточно запросить подтверждение (например, «Пожалуйста, подтвердите, что вас зовут [ИМЯ].») Уже имеющейся у вас информации.
Затем задайте любые общие вопросы, связанные с вашим проектом. Например, если вы тестируете приложение для путешествий, вы можете спросить, как часто участники летают и используют ли они какие-либо приложения для бронирования и планирования поездок.
4. Задачи и сценарии
Задачи — это действия, которые вы просите участников выполнить на устройстве или другом интерфейсе тестирования. Каждое задание должно иметь цель.
Создание сценариев помогает участникам взаимодействовать с интерфейсом и представлять, как они будут использовать приложение в реальной жизни. Цель и задача пользователя могут выглядеть так:
- Цель теста: просмотреть гостиничные номера и забронировать один.
- Пример плохой задачи: забронировать номер в отеле.
- Пример лучшего задания (со сценарием): вы планируете отпуск в Бангкок с 3 по 14 сентября. Вам нужно забронировать отель для вашего пребывания. Зайдите в приложение, просмотрите информацию и забронируйте номер, который вы считаете лучшим.
СОВЕТ: всегда позволяйте пользователям возвращаться и читать задание столько раз, сколько им нужно.
Советы по написанию лучших заданий
Попытка не искажать поведение пользователя является сложной задачей, но она важна, если вы хотите получить полезные результаты. Вот пять советов, чтобы написать более эффективные, нейтральные задачи:
- Сделайте задачу реалистичной, чтобы помочь участникам взаимодействовать с интерфейсом. Создавайте сценарии, максимально имитирующие реальный мир. Не заставляйте их делать то, чего они обычно не делают. Например:
- Цель теста: просмотреть продаваемые товары на site.com .
- Пример плохой задачи: купите пару белых высоких джинс Levi’s которые в продаже.
- Пример лучшей задачи: купите пару джинсов Levi’s менее чем за 20 долларов .
- В реальных условиях пользователи, вероятно, будут просматривать, прежде чем выбрать то, что они хотят купить. В первом примере мы не предоставляем пользователю возможность выбирать то, что он обычно выбирает. Вместо этого мы говорим им, что делать. Они сосредоточатся на поиске джинсов, которые мы им сказали найти, и могут не взаимодействовать с интерфейсом так, как обычно.
- Не заставляйте участников взаимодействовать с определенной функцией. Вместо этого попытайтесь выяснить, как они решили использовать интерфейс. Таким образом, вы узнаете, могут ли они найти функции и использовать их, как вы ожидаете.
- Цель теста: найти рецепт.
- Пример плохой задачи: используйте панель поиска, чтобы найти индийский рецепт.
- Лучший пример задачи: вы хотите приготовить индийскую еду сегодня. Используйте приложение, чтобы найти рецепт.
- Избегайте добавления подсказок или описания шагов. Лучше предложить контекст для сценария, чем предоставить четкие шаги для достижения цели. Идея состоит в том, чтобы позволить участникам самостоятельно перемещаться по интерфейсу.
- Цель теста: следить за прогрессом в книге.
- Пример плохой задачи: вы хотите обновить прогресс в книге, которую вы читаете. Перейдите в приложение, найдите книгу, добавьте ее в свой список и обновите достигнутый прогресс.
- Лучший пример задачи: вы начали читать новую книгу и не хотите терять место на котором закончили в прошлый раз. Используйте приложение, чтобы обновить ваш прогресс.
- Не облегчайте задачу участникам, используя тот же язык, который они могут легко найти в тестируемом интерфейсе. Например, если интерфейс демонстрирует кнопку с надписью «Пользуйтесь месяц бесплатно», вам не следует использовать эту же формулировку в задании:
- Цель теста: попробуйте сервис бесплатно.
- Пример плохого задания: зайдите на сайт и пользуйтесь бесплатно в течение месяца .
- Лучший пример задачи: вы хотите попробовать этот сервис в первый раз. Зайдите на сайт и зарегистрируйтесь.
- Будьте максимально прямыми в том, как вы формулируете задачи. Посмотрите на эти два примера задачи:
- Цель теста: записаться на прием.
- Пример плохой задачи: теперь, посмотрите, можете ли вы попытаться найти способ записаться на прием к диетологу.
- Пример лучшего задания: теперь, записаться на прием к диетологу.
- Первая из них с дополнительной фразой «посмотрим, сможете ли вы попытаться найти способ», создает впечатление, что задача будет трудной для выполнения, или даже подсказка, которая может ожидать определенного ответа, поскольку интерфейс имеет плохой опыт или дизайн.
СОВЕТ: При необходимости вы можете задавать вопросы между заданиями. Лучше подождать, пока участник выполнит задание, чтобы не отвлекать их.
5. Пост-тестовая анкета
После завершения основного теста, часть вопросника сценария теста юзабилити направляет модератора задавать дополнительные вопросы. В этом разделе модератор захочет исследовать области, где ответы были неясными или неоднозначными.
Вы можете задать участникам вопросы высокого уровня о продукте или конкретной функции, или если они ожидают, что что-то будет отличаться. Вы также можете задавать открытые вопросы о новых функциях, которые они хотели бы использовать.
6. Подведение итогов
В этом разделе скрипта юзабилити-теста вы поблагодарите участников за их время. И вы можете спросить пользователей, если у них есть какие-либо вопросы для вас. Наконец, вы должны обсудить с вашими пользователями детали их компенсации.
Пользовательские сценарии (сценарии использования)
К отдельному подвиду последовательных наборов тест-кейсов можно отнести пользовательские сценарии, представляющие собой цепочки действий, выполняемых пользователем в определённой ситуации для достижения определённой цели.
Допустим, пользователь хочет распечатать табличку на дверь кабинета с текстом «Идёт работа, не стучать!»
Для этого ему нужно:
- Запустить текстовый редактор.
- Создать новый документ (если редактор не делает это самостоятельно).
- Набрать в документе текст.
- Отформатировать текст должным образом.
- Отправить документ на печать.
- Сохранить документ (спорно, но допустим
- Закрыть текстовый редактор.
Получили пользовательский сценарий, пункты которого могут стать основой для шагов тест-кейса или целого набора отдельных тест-кейсов.
Сценарии могут быть достаточно длинными и сложными, могут содержать внутри себя циклы и условные ветвления, но при всём этом они обладают рядом весьма интересных преимуществ:
- Сценарии показывают реальные и понятные примеры использования продукта (в отличие от обширных чек-листов, где смысл отдельных пунктов может теряться).
- Сценарии понятны конечным пользователям и хорошо подходят для обсуждения и совместного улучшения.
- Сценарии и их части легче оценивать с точки зрения важности, чем отдельные пункты (особенно низкоуровневых) требований.
- Сценарии отлично показывают недоработки в требованиях (если становится непонятно, что делать в том или ином пункте сценария, — с требованиями явно что-то не то).
- В предельном случае (нехватка времени и прочие форс-мажоры) сценарии можно даже не прописывать подробно, а просто именовать — и само наименование уже подскажет опытному специалисту, что делать.
Последний пункт проиллюстрируем на примере.
Классифицируем потенциальных пользователей нашего приложения (напомним, что в нашем случае «пользователь» — это администратор, настраивающий работу приложения) по степени квалификации и склонности к экспериментам, а затем дадим каждому «виду пользователя» запоминающееся имя.
На этой стадии можно представить отличия в логике работы с приложением, например, «консервативного» и «отчаянного» пользователей.
Озаглавим для них сами сценарии, например, в ситуациях, когда такой пользователь позитивно и негативно относится к идее внедрения нашего приложения:
Можно представить, что и как будет происходить в каждой из получившихся восьми ситуаций. Причём на создание пары таких таблиц уходит всего несколько минут, а эффект от их использования на порядки превосходит бездумное «кликанье по кнопкам в надежде найти баг»
Тестовые сценарии (Test case), тестовые варианты. Оформление результатов тестирования.
ТЕРМИНОЛОГИЯ И ОБЩИЕ СВЕДЕНИЯ
Для начала определимся с терминологией, поскольку здесь есть много путаницы, вызванной разными переводами англоязычных терминов на русский язык и разными традициями в тех или иных странах, фирмах и отдельных командах.
Во главе всего лежит термин «тест». Официальное определение звучит так.
Тест — набор из одного или нескольких тест-кейсов.
Поскольку среди всех прочих терминов этот легче и быстрее всего произносить, в зависимости от контекста под ним могут понимать и отдельный пункт чек-листа, и отдельный шаг в тест-кейсе, и сам тест-кейс, и набор тест-кейсов и… продолжать можно долго. Главное здесь одно: если вы слышите или видите слово «тест», воспринимайте его в контексте.
Теперь рассмотрим самый главный для нас термин — «тест-кейс».
Тест-кейс — набор входных данных, условий выполнения и ожидаемых
результатов, разработанный с целью проверки того или иного свойства или поведения программного средства.
Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса.
Мы ещё вернёмся к этой мысли, но уже сейчас критически важно понять и запомнить: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (иногда он не имеет смысла, иногда его и
вовсе невозможно выполнить).
Иногда термин «test case» на русский язык переводят как «тестовый случай». Это вполне адекватный перевод, но из-за того, что «тест-кейс» короче произносить, наибольшее распространение получил именно этот вариант.
Высокоуровневый тест-кейс — тест-кейс без конкретных входных дан-
ных и ожидаемых результатов.
Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс — тест-кейс с конкретными входными дан-
ными и ожидаемыми результатами.
Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой
информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Спецификация тест-кейса — документ, описывающий набор
тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента.
Спецификация теста — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса и/или спецификации тест-процедуры.
Тест-сценарий — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).
ЦЕЛЬ НАПИСАНИЯ ТЕСТ-КЕЙСОВ
Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне в зависимости от множества факторов).
Наличие же тест-кейсов позволяет:
- Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
- Вычислять метрики тестового покрытия (test coverage 296 metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
- Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).
- Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях).
- Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни страниц текста).
- Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).
- Повышать качество требований (мы это уже рассматривали: написание чек-листов и тест-кейсов — хорошая техника тестирования требований).
- Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.
ЖИЗНЕННЫЙ ЦИКЛ ТЕСТ-КЕЙСА
В отличие от отчёта о дефекте, у которого есть полноценный развитый жизненный цикл, для тест-кейса речь скорее идёт о наборе состояний, в которых он может находиться (жирным шрифтом отмечены наиболее важные состояния).
- Создан — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
- Запланирован — в этом состоянии тест-кейс находится, когда он
или явно включён в план ближайшей итерации тестирования, или как минимум готов для выполнения. - Не выполнен — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
- Выполняется — если тест-кейс требует длительного времени на выполнение, он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
- Пропущен — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
- Провален — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
- Пройден успешно — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
- Заблокирован — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
- Закрыт — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.
- Требует доработки — как видно из схемы, в это состояние (и из него) тест-кейс может быть преведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния.
Ещё раз подчеркнём, что в отличие от жизненного цикла дефекта, который достаточно стандартизирован и формализован, для тест-кейса описанное выше носит общий рекомендательный характер, рассматривается скорее как разрозненный набор состояний (а не строгий жизненный цикл) и может сильно отличаться в разных компаниях (в связи с имеющимися традициями и/или возможностями систем управления тест-кейсами).
Атрибуты (поля) тест-кейса.
Как уже было сказано выше, термин «тест-кейс» может относиться к формальной записи тест-кейса в виде технического документа. Эта запись имеет общепринятую структуру, компоненты которой называются атрибутами (полями) тест-кейса.
В зависимости от инструмента управления тест-кейсами внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной.
Общий вид всей структуры тест-кейса представлен ниже:
Теперь рассмотрим каждый атрибут подробно.
Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если
позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например:
UR216_S12_DB_Neg).
Приоритет показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.
Приоритет тест-кейса может коррелировать с:
- важностью требования, пользовательского сценария или функции, с которыми связан тест-кейс;
- потенциальной важностью дефекта, на поиск которого направлен тест-кейс;
- степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием или функцией.
Основная задача этого атрибута — упрощение распределения внимания и усилий команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной ситуации, не позволяющей выполнить все запланированные тест-кейсы.
Связанное с тест-кейсом требование показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное — потому, что один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса,
как прослеживаемость.
Частые вопросы, связанные с заполнением этого поля, таковы:
- Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой привязки к требованиям, и (пока?) значение этого поля определить сложно. Хоть такой вариант и не считается хорошим, он достаточно распространён.
- Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются выбрать одно самое главное или «более высокоуровневое» (например, вместо того, чтобы перечислять R56.1, R56.2, R56.3 и т.д., можно просто написать R56). Чаще всего в инструментах управления тестами это поле представляет собой выпадающий список, где можно выбрать только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кейсы всё же направлены на проверку строго одного требования, и для них этот вопрос также неактуален.
Модуль и подмодуль приложения указывают на части приложения,
к которым относится тест-кейс, и позволяют лучше понять его цель.
Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разде-
ляется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули).
И вот уже для таких небольших частей приложения придумать чек-листы и создать хорошие тест-кейсы становится намного проще.
Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения.
Теперь — самое сложное: как выбираются модули и подмодули. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:
-
Механизм запуска:
- механизм анализа параметров;
- механизм сборки приложения;
- механизм обработки ошибочных ситуаций.
-
Механизм взаимодействия с файловой системой:
- механизм обхода дерева SOURCE_DIR;
- механизм обработки ошибочных ситуаций.
-
Механизм преобразования файлов:
- механизм определения кодировок;
- механизм преобразования кодировок;
- механизм обработки ошибочных ситуаций.
-
Механизм ведения журнала:
- механизм записи журнала;
- механизм отображения журнала в консоли;
- механизм обработки ошибочных ситуаций.
Согласитесь, что такие длинные названия с постоянно повторяющимся словом «механизм» читать и запоминать сложно. Перепишем:
- Стартер:
- анализатор параметров;
- сборщик приложения;
- обработчик ошибок.
- Сканер:
- обходчик;
- обработчик ошибок.
- Преобразователь:
- детектор;
- конвертер;
- обработчик ошибок.
- Регистратор:
- дисковый регистратор;
- консольный регистратор;
- обработчик ошибок.
Но что делать, если мы не знаем «внутренностей» приложения (или не очень разбираемся в программировании)? Модули и подмодули можно выделять на основе графического интерфейса пользователя (крупные области и элементы внутри них), на основе решаемых приложением
задач и подзадач и т.д. Главное, чтобы эта логика была одинаковым образом применена ко всему приложению.
Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ действия, это именно структурные части, «куски» приложения. В заблуждение вас могут ввести такие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду именно части приложения, отвечающие за печать и за настройку принтера (и названы
они отглагольными существительными), а не процесс печати или настройки принтера).Сравните (на примере человека): «дыхательная система, лёгкие» — это модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, мозг» — это модуль и подмодуль, а «кивание», «думание» — нет.
Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-кейса, как прослеживаемость.
Заглавие тест-кейса призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. Именно это поле является наиболее информативным при просмотре списка тест-кейсов.
Сравните.
| Плохо | Хорошо |
|---|---|
| Тест 1 | Запуск, одна копия, верные параметры |
| Тест 2 | Запуск одной копии с неверными путями |
| Тест 78 (улучшенный) | Запуск, много копий, без конфликтов |
| Остановка | Остановка по Ctrl+C |
| Закрытие | Остановка закрытием консоли |
Заглавие тест-кейса может быть полноценным предложением, фразой, набором словосочетаний — главное, чтобы выполнялись следующие условия:
- Информативность.
- Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы).
Внимание! Частая ошибка! Если инструмент управления тест-кейсами не требует писать заглавие, его всё равно надо писать. Тест-кейсы без заглавий превращаются в мешанину информации, использование которой сопряжено с колоссальными и совершенно бессмысленными затратами.
И ещё одна небольшая мысль, которая может помочь лучше формулировать заглавия. В дословном переводе с английского «test case» обозначает «тестовый случай (ситуация)». Так вот, заглавие как раз и описывает этот случай (ситуацию), т.е. что происходит в тест-кейсе, какую
ситуацию он проверяет.
Исходные данные, необходимые для выполнения тест-кейса, позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:
- Состояние базы данных.
- Состояние файловой системы и её объектов.
- Состояние серверов и сетевой инфраструктуры.
То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении.
Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин,
если не хватило денег и т. д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».
Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с тестируемым приложением. И здесь нет «правильного варианта» — просто в одной традиции решено одним образом, в другой — другим. Во многом это — ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без участия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами,
чтобы понять, какой точки зрения на данный вопрос они придерживаются.
Шаги тест-кейса описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы:
- начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т. п.);
- даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту);
- если вы пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»);
- соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т. д. — в зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до предельно чётко прописанных значений и указаний;
- ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»);
- пишите шаги последовательно, без условных конструкций вида «если… то…».
Внимание! Частая ошибка! Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы целиком: если те, другие тест-кейсы будут изменены или удалены, ваш тест-кейс начнёт ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие тест-кейсы или шаги приведут к возникновению
ошибки, вы не сможете закончить выполнение вашего тест-кейса.
Ожидаемые результаты по каждому шагу тест-кейса описывают реакцию
приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.
По написанию ожидаемых результатов можно порекомендовать следующее:
- описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо);
- пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия,
лучше оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие); - пишите кратко, но не в ущерб информативности;
- избегайте условных конструкций вида «если… то…».
Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной системе и аварийно завершается с потерей всех пользовательских данных».
При этом корректная работа приложения вполне может предполагать отображение сообщений о неверных действиях пользователя или неких критических ситуациях. Так, сообщение «Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно свободного места» — это не ошибка приложения, это его совершенно нормальная и правильная работа. Ошибкой приложения (в этой же ситуации) было бы
отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных.
Для более глубокого понимания принципов оформления тест-кейсов рекомендуется прямо сейчас ознакомиться с главой «Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов».
Свойства качественных тест-кейсов
Даже правильно оформленный тест-кейс может оказаться некачественным, если в нём нарушено одно из следующих свойств.
Правильный технический язык, точность и единообразие формулировок. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой до-
кументации. Основные идеи уже были описаны (см. главу «Атрибуты (поля) тест-кейсов»), а из самого общего и важного напомним и добавим:
- пишите лаконично, но понятно;
- используйте безличную форму глаголов (например, «открыть» вместо «откройте»);
- обязательно указывайте точные имена и технически верные названия элементов приложения;
- не объясняйте базовые принципы работы с компьютером (предполагается, что ваши коллеги знают, что такое, например, «пункт меню» и как с ним работать);
- везде называйте одни и те же вещи одинаково (например, нельзя в одном тест-кейсе некий режим работы приложения назвать «графическое представление», а в другом тот же режим — «визуальное отображение», т.к. многие люди могут подумать, что речь идёт о разных вещах);
- следуйте принятому на проекте стандарту оформления и написания тест-кейсов (иногда такие стандарты могут быть весьма жёсткими: вплоть до регламентации того, названия каких элементов должны быть приведены в двойных кавычках, а каких — в одинарных).
Баланс между специфичностью и общностью. Тест-кейс считается тем более специфичным, чем более детально в нём расписаны конкретные действия, конкретные значения и т. д., т. е. чем в нём больше конкретики. Соответственно, тест-кейс считается тем более общим, чем в нём меньше конкретики.
Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (подумайте, какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему):
Тест-кейс 1:
| Шаги | Ожидаемые результаты |
|---|---|
| Конвертация из всех поддерживаемых кодировок Приготовления: — Создать папки C:/A, C:/B, C:/C, C:/D. — Разместить в папке C:/D файлы 1.html, 2.txt, 3.md из прилагаемого архива. 1. Запустить приложение, выполнив команду php converter.php c:/a c:/b c:/c/converter.log.2. Скопировать файлы 1.html, 2.txt, 3.md из папки C:/D в папку C:/A. 3. Остановить приложение нажатием Crtl+C. |
1. Отображается консольный журнал приложения с сообщением «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log», в папке C:/C появляется файл converter.log, в котором появляется запись «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log». 2. Файлы 1.html, 2.txt, 3.md появляются в папке C:/A, затем пропадают оттуда и появляются в папке C:/B. В консольном журнале и файле C:/C/converter.log появляются сообщения (записи) «текущее_время processing 1.html (KOI8-R)», «текущее_время processing 2.txt (CP-1251)», «текущее_время processing 3.md (CP-866)». 3. В файле C:/C/converter.log появляется запись «текущее_время closed». Приложение завершает работу. |
Тест-кейс 2:
| Шаги | Ожидаемые результаты |
|---|---|
| Конвертация из всех поддерживаемых кодировок 1. Выполнить конвертацию трёх файлов до пустимого размера в трёх разных кодировках всех трёх допустимых форматов. |
1. Файлы перемещаются в папку-приёмник, кодировка всех файлов меняется на UTF-8. |
Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему», то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй — слишком общим. Можно сказать, что здесь до абсурда доведены идеи низкоуровневых и высокоуровневых тест-кейсов.
Почему плоха излишняя специфичность (тест-кейс 1):
- при повторных выполнениях тест-кейса всегда будут выполняться строго одни и те же действия со строго одними и теми же данными, что снижает вероятность обнаружения ошибки;
- возрастает время написания, доработки и даже просто прочтения тест-кейса;
- в случае выполнения тривиальных действий опытные специалисты тратят дополнительные мыслительные ресурсы в попытках понять, что же они упустили из виду, т. к. они привыкли, что так описываются только самые сложные и неочевидные ситуации.
Почему плоха излишняя общность (тест-кейс 2):
- тест-кейс сложен для выполнения начинающими тестировщиками или даже опытными специалистами, лишь недавно подключившимися к проекту;
- недобросовестные сотрудники склонны халатно относиться к таким тест-кейсам;
- тестировщик, выполняющий тест-кейс, может понять его иначе, чем было задумано автором (и в итоге будет выполнен фактически совсем другой тест-кейс).
Выход из этой ситуации состоит в том, чтобы придерживаться золотой середины (хотя, конечно же, какие-то тесты будут чуть более специфичными, какие-то — чуть более общими).
Вот пример такого срединного подхода:
Тест-кейс 3:
| Шаги | Ожидаемые результаты |
|---|---|
| Конвертация из всех поддерживаемых кодировок Приготовления: — Создать в корне любого диска четыре отдельные папки для входных файлов, выходных файлов, файла журнала и временного хранения тестовых файлов. — Распаковать содержимое прилагаемого архива в папку для временного хранения тестовых файлов. 1. Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное). 2. Скопировать файлы из папки для временного хранения в папку для входных файлов. 3. Остановить приложение. |
1. Приложение запускается и выводит сообщение о своём запуске в консоль и файл журнала. 2. Файлы из папки для входных файлов перемещаются в папку для выходных файлов, в консоли и файле журнала отображаются сообщения о конвертации каждого из файлов с указанием его исходной кодировки. 3. Приложение выводит сообщение о завершении работы в файл журнала и завершает работу. |
В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он стал короче и проще для выполнения, а отсутствие строго указанных значений приводит к тому, что
при многократном выполнении тест-кейса (особенно — разными тестировщиками) конкретные параметры будут менять свои значения, что увеличивает вероятность обнаружения ошибки.
Ещё раз главная мысль: сами по себе специфичность или общность тест-кейса не являются чем-то плохим, но резкий перекос в ту или иную сторону снижает качество тест-кейса.
Баланс между простотой и сложностью. Здесь не существует академических определений, но принято считать, что простой тест-кейс оперирует одним объектом (или в нём явно виден
главный объект), а также содержит небольшое количество тривиальных действий; сложный тест-кейс оперирует несколькими равноправными объектами и содержит много нетривиальных
действий.
Преимущества простых тест-кейсов:
- их можно быстро прочесть, легко понять и выполнить;
- они понятны начинающим тестировщикам и новым людям на проекте;
- они делают наличие ошибки очевидным (как правило, в них предполагается выполнение повседневных тривиальных действий, проблемы с которыми видны невооружённым взглядом и не вызывают дискуссий);
- они упрощают начальную диагностику ошибки, т.к. сужают круг поиска.
Преимущества сложных тест-кейсов:
- при взаимодействии многих объектов повышается вероятность возникновения ошибки;
- пользователи, как правило, используют сложные сценарии, а потому сложные тесты более полноценно эмулируют работу пользователей;
- программисты редко проверяют такие сложные случаи (и они совершенно не обязаны это делать).
Рассмотрим примеры.
Шаблон тестового сценария по стандартам WorldSkills (демо-экзамен) с комментариями
Для выполнения процедуры тестирования удаления товаров Вам нужно описать пять сценариев.
Удаление может быть выполнимо, а может быть отклонено согласно требованиям предметной области.
Необходимо, чтобы варианты тестирования демонстрировали различные исходы работы алгоритма. Для описания тестовых сценариев в ресурсах предоставлен шаблон
testing-template.docx(есть в этом репозитории в каталогеdocs).
Расшифровка тестовых информационных полей:
| Поле | Описание |
|---|---|
| Название проекта | Название тестируемого проекта |
| Рабочая версия | Версия проекта/программного обеспечения (первый тест считается 1.0). |
| Имя тестирующего | Имя того, кто проводил тесты |
| Дата(ы) теста | Дата(ы) проведения тестов – это один или несколько дней. Если тесты проводились в более протяженный период времени, нужно отметить отдельную дату для каждого теста. |
| Тестовый пример # | Уникальный ID для каждого тестового примера. Следуйте некоторым конвенциям, чтобы указать типы тестов. Например,‘TC_UI_1′ означает‘user interface test case #1′ ( ТС_ПИ_1: тестовый случай пользовательского интерфейса#1) |
| Приоритет тестирования (Низкий/Средний/Высокий) | Насколько важен каждый тест. Приоритет тестирования для бизнес-правил и функциональных тестовых случаев может быть средним или высоким, в то время как незначительные случаи пользовательского интерфейса могут иметь низкий приоритет. |
| Заголовок/название теста | Название тестового случая. Например, Подтвердите страницу авторизации с действительным именем пользователя и паролем. |
| Краткое изложение теста | Описание того, что должен достичь тест. |
| Этапы теста | Перечислите все этапы теста подробно. Запишите этапы теста в том порядке, в котором они должны быть реализованы. Предоставьте как можно больше подробностей и разъяснений. Пронумерованный список – хорошая идея. |
| Тестовые данные | Перечислите/опишите все тестовые данные, используемые для данного тестового случая. Так, фактические используемые входные данные можно отслеживать по результатам тестирования. Например, Имя пользователя и пароль для подтверждения входа. |
| Ожидаемый результат | Каким должен быть вывод системы после выполнения теста? Подробно опишите ожидаемый результат, включая все сообщения/ошибки, которые должны отображаться на экране. |
| Фактический результат | Каким должен быть фактический результат после выполнения теста? Опишите любое релевантное поведение системы после выполнения теста. |
| Предварительное условие | Любые предварительные условия, которые должны быть выполнены до выполнения теста. Перечислите все предварительные условия для выполнения этого тестового случая. |
| Постусловие | Каким должно быть состояние системы после выполнения теста? |
| Статус (Зачет/Незачет) | Если фактический результат не соответствует ожидаемому результату, отметьте тест как неудачный. В ином случае обновление пройдено. |
| Примечания/комментарии | Используйте эту область для любых дополнительных заметок/комментариев/вопросов. Эта область предназначена для поддержки вышеуказанных полей (например, если есть некоторые особые условия, которые не могут быть описаны в любом из вышеуказанных полей, или если есть вопросы, связанные с ожидаемыми или фактическими результатами). |
Аннотация теста
| Мои комментарии | ||
|---|---|---|
| Название проекта | DoeduSam | |
| Рабочая версия | 1.0 | Эту версию не плохо бы вписать в свойства проекта |
| Имя тестирующего | DEMO_xx | |
| Дата(ы) теста | 21.12.2020 | текущая |
Тестовый пример #1:
| Мои комментарии | ||
|---|---|---|
| Тестовый пример # | TC_DP_1 | расшифровывается: TestCase_DeleteProduct_x |
| Приоритет тестирования | средний | бизнес-правило |
| Заголовок/название теста | Удаление товара без продаж и дополнительных товаров | |
| Краткое изложение теста | Товар должен без ошибок удалиться из таблицы товаров | |
| Этапы теста | 1. Очистить таблицы продаж, дополнительных товаров, дополнительных картинок и товаров. 2. Добавить тестовый товар в таблицу Products 3. Вызвать метод удаления товара 4. Проверить наличие удаленной записи в таблице |
|
| Тестовые данные | Название: Моторное масло Motor Oil KE900-90042-R Изображение: Товары автосервиса8FE07916.jpg Производитель: Nissan Активен: да Цена: 2060 |
Тут нужно вставить содержимое любой записи из products_a_import |
| Ожидаемый результат | Запись должна быть удалена из таблицы без ошибок и исключений | |
| Фактический результат | Запись удалена | |
| Статус | зачет | |
| Предварительное условие | В базу должны быть загружен тестовый продукт | |
| Постусловие | Таблица товаров должна быть пустой | |
| Примечания/комментарии | Т.к. мы добавили только товар без продаж и дополнительных товаров, то ошибок в принципе быть не может ни по вине кода ни по ограничениям базы |
Что еще можно проверить
-
№2 — удаление товара с дополнительными товарами. Если ограничения настроены правильно (каскадное удаление), то тоже долно удаляться нормально.
-
№3 — удаление товара с дополнительными картинками. Аналогично №2.
-
№4 — удаление товара с продажами. Вариант без предварительной проверки — база должна вернуть ошибку, приложение это исключение должно перехватить и выдать сообщение, что удалять нельзя.
-
№5 — удаление товара с продажами. Вариант с предварительной проверкой — в коде нужно проверить есть ли у товара продажи и при наличии продаж вывести сообщение, что удалять товар нельзя.
24.2.2. Полнота покрытия пользовательского интерфейса
При определении понятия покрытия пользовательского интерфейса можно ввести следующие его уровни:
- функциональное покрытие — покрытие требований к пользовательскому интерфейсу;
- структурное покрытие — для обеспечения полного структурного покрытия каждый интерфейсный элемент должен быть использован в тестовых примерах хотя бы один раз;
- структурное покрытие с учетом состояния элементов интерфейса — для обеспечения этого уровня покрытия необходимо не только использовать каждый элемент интерфейса, но и привести его во все возможные состояния (например, для чек-боксов — отмечен/не отмечен, для полей ввода — пустое/заполненное не целиком/заполненное полностью и т.п.)
- структурное покрытие с учетом состояния элементов интерфейса и внутреннего состояния системы — поведение некоторых интерфейсных элементов может изменяться в зависимости от внутреннего состояния системы. Каждое такое различимое поведение интерфейсного элемента должно быть проверено. Например, система может иметь два режима работы — нормальный и для начинающего пользователя, в котором нажатие каждого элемента сопровождается появлением всплывающей подсказки. В этом случае нужно проверить оба режима и при этом проверить, что подсказки появляются только в режиме для начинающих.
При определении степени покрытия необходимо учитывать, что реакция на некоторые интерфейсные элементы определяется не программной системой, а на уровне операционной системы или среды выполнения. Так, например, реакция на использование многих интерфейсных элементов стандартного диалогового окна открытия файла определяется операционной системой и может не тестироваться.
Если уровень покрытия интерфейсных элементов тестами недостаточен, это является сигналом либо к уточнению требований к пользовательскому интерфейсу, либо к снижению степени подробности тестирования.
24.2.3. Методы проведения тестирования пользовательского интерфейса, повторяемость тестирования пользовательского интерфейса
Функциональное тестирование пользовательского интерфейса может проводиться различными методами — как вручную при непосредственном участии оператора, так и при помощи различного инструментария, автоматизирующего выполнение тестовых примеров. Рассмотрим эти методы более подробно.
24.2.3.1. Ручное тестирование
Ручное тестирование пользовательского интерфейса проводится тестировщиком-оператором, который руководствуется в своей работе описанием тестовых примеров в виде набора сценариев. Каждый сценарий включает в себя перечисление последовательности действий, которые должен выполнить оператор, и описание важных для анализа результатов тестирования ответных реакций системы, отражаемых в пользовательском интерфейсе. Типичная форма записи сценария для проведения ручного тестирования — таблица, в которой в одной колонке описаны действия (шаги сценария), в другой — ожидаемая реакция системы, а третья предназначена для записи того, совпала ли ожидаемая реакция системы с реальной и перечисления несовпадений (Таблица 24.1).
| № п/п | Действие | Реакция системы | Результат |
|---|---|---|---|
| 1 | Щелкните на пиктограмме System и выберите пункт меню ‘System Management Applet’. | Появится окно ввода логина и пароля | Верно |
| 2 | Введите в появившееся окно ввода имя пользователя ‘guest1’ и пароль ‘guest’. Затем нажмите кнопку ‘Login’. | Появится окно ‘System Management Applet’. В верхнем правом углу должно быть выведено имя вошедшего пользователя guest1
Все опции в окне должны быть отключены (выведены серым цветом) |
Неверно
Окно имеет название ‘System Management Application‘ |
| 3 | Завершите сеанс работы с апплетом щелчком по пиктограмме ‘Logout’. | Окно ‘System Management Applet’ должно быть закрыто | Верно |
Ручное тестирование пользовательского интерфейса удобно тем, что контроль корректности интерфейса проводится человеком, т.е. основным «потребителем» данной части программной системы. К тому же при чисто косметических изменениях в интерфейсах системы, не отраженных в требованиях (например, при перемещении кнопок управления на 10 пикселей влево), анализ успешности прохождения теста будет выполняться не по формальным признакам, а согласно человеческому восприятию.
При этом ручное тестирование имеет и существенный недостаток — для его проведения требуются значительные человеческие и временные ресурсы. Особенно сильно этот недостаток проявляется при проведении регрессионного тестирования и вообще любого повторного тестирования — на каждой итерации повторного тестирования пользовательского интерфейса требуется участие тестировщика-оператора. В связи с этим в последнее десятилетие получили распространение средства автоматизации тестирования пользовательского интерфейса, снижающие нагрузку на тестировщика-оператора.
24.2.3.2. Сценарии на формальных языках
Естественный способ автоматизации тестирования пользовательского интерфейса — использование программных инструментов, эмулирующих поведение тестировщика-оператора при ручном тестировании пользовательского интерфейса.
Такие инструменты используют в качестве входной информации сценарии тестовых примеров, записанные на некотором формальном языке, операторы которого соответствуют действиям пользователя — вводу команд, перемещению курсора, активизации пунктов меню и других интерфейсных элементов.
При выполнении автоматизированного теста инструмент тестирования имитирует действия пользователя, описанные в сценарии, и анализирует интерфейсную реакцию системы. Для определения ожидаемого состояния пользовательского интерфейса здесь могут применяться различные методы — либо анализ снимков экрана и сравнение их с эталонными, либо доступ к данным интерфейсных элементов средствами операционной системы (например, доступ ко всем кнопкам окна по их дескрипторам и получение значений текста).
И при передаче информации в тестируемый интерфейс, и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса:
- позиционный, при котором доступ к элементу осуществляется при помощи задания его абсолютных (относительно экрана) или относительных (относительно окна) координат и размеров;
- по идентификатору, при котором доступ к элементу осуществляется при помощи получения интерфейсного элемента при помощи его уникального идентификатора в пределах окна.
При внесении изменений в пользовательский интерфейс при использовании первого метода в результате проведения регрессионного тестирования будет выявлено большое количество не прошедших тестов — достаточно изменения местоположения одного ключевого интерфейсного элемента, как все сценарии начнут работать неверно. Соответственно при таком методе автоматизации тестирования необходимо менять значительную часть сценариев в системе тестов при каждом изменении интерфейса системы. Такой метод автоматизации тестирования подходит для систем с устоявшимся и редко изменяемым интерфейсом.
Второй метод автоматизации тестирования более устойчив к изменению расположения интерфейсных элементов, но изменения тестовых примеров могут потребоваться и здесь в случае изменения логики работы интерфейсных элементов. Например, пусть в первой версии системы при нажатии на кнопку «Передать данные» передача данных начиналась сразу и выводилось окно с индикатором прогресса. Сценарий тестового примера в этом случае включает в себя имитацию нажатия на кнопку и обращение к индикатору прогресса для получения значения прогресса в процентах.
Если во второй версии системы после нажатия на кнопку «Передать данные» вначале выводится окно «Вы уверены?» с кнопками «Да» и «Нет», то для проверки работы индикатора прогресса в тестовый сценарий необходимо добавить имитацию нажатия кнопки «Да».
Даже при обращении при помощи идентификаторов без модификации тестового примера тест не будет корректно выполняться. Тем не менее, этот способ обращения к интерфейсным элементам хорошо подходит для тестирования программных систем, в т.ч. с не устоявшимся пользовательским интерфейсом.