В основе любого пользовательского тестирования лежит четко сформулированный сценарий, который дает возможность получить более подробные данные и репрезентативные результаты.
Напротив, если сценарий неэффективен, ваши выводы, скорее всего, будут искажены и вы не сможете использовать их в дизайн-процессе, что сделает тестирование бесполезным.
Как написать свою программу на python? #python #программирование
Я опросил нескольких членов команды UX-дизайнеров компании Codal, чтобы узнать, каким образом они создают свои сценарии для тестирования юзабилити. Вот их советы.
1. Определите область исследования и отберите участников
Прежде чем брать ручку или создавать новый Google-документ, вам необходимо четко определить рамки вашего тестирования, а также отобрать для него участников. Эти вопросы заслуживают отдельной статьи, но пока просто запомните, что они станут определяющими при написании сценария.
Если использовать терминологию сценаристов: область исследования, то есть задачи, которые должны будут выполнить участники, составляют основную часть сюжета, а они сами выступают в качестве главных героев.
2. Получите согласие на запись
Все юзабилити-тесты записываются для последующего анализа. Вне зависимости от того, как именно это делается — с помощью веб-камеры, диктофона или программы для записи видео с экрана, вы должны проинформировать участника, что планируете вести запись и получить его прямое согласие на это. Тогда человек почувствует себя более комфортно (особенно, если перед его лицом камера). Отсутствие такого согласия ставит под сомнение результаты тестирования.
3. Начните с базовой информации
Прежде чем приступить к основной части тестирования, запишите персональные данные участника: его имя, возраст, род деятельности и другие сведения, релевантные предмету исследования.
Вы можете задавать участнику вопросы (например, “Как вас зовут?”, “Сколько вам лет?”, “Использовали ли вы раньше приложения для заказа такси?”) или озвучивать утверждения и просить участника подтвердить, правдивы они или нет (“Пожалуйста, подтвердите, что ваше имя X, вам Y лет и т.д.”).
Большинство дизайнеров предпочитают первый вариант, поскольку он напоминает обычную беседу. Как правило, в этом случае участники чувствуют себя более непринужденно.
Используйте сразу несколько способов фиксации полученных данных. Файлы могут быть повреждены, поэтому всегда полезно иметь резервную копию.
4. Убедите участника, что он не является предметом исследования
Зачастую участники чувствуют, что именно они являются предметом исследования, а не платформа или прототип, с которыми они взаимодействуют. Постарайтесь развеять эти страхи, убедив участника, что вы с ним составляете единую команду и работаете вместе, чтобы сделать продукт лучше. Будьте честны и открыты, и вы сможете создать благоприятную среду для получения репрезентативных, эмпирических данных.
5. Попросите участника озвучивать свои мысли
Задача UX-дизайна зачастую сводится к тому, чтобы понять, какие решения пользователи принимают за долю секунды, и повлиять на те впечатления, которые у них мгновенно возникают.
Трудно определить, что происходит в голове пользователя, когда он взаимодействует с вашим прототипом. При этом сам участник может даже не отслеживать свои подсознательные реакции.
Именно поэтому критически важно, чтобы участник озвучивал свои мысли, действия и мнения в ходе использования платформы. Конечно, рассказывать о том, какие мысли у тебя возникают, может быть неловко (особенно перед незнакомыми людьми), поэтому значительная часть вашего сценария должна быть посвящена действиям, которые следует предпринять, чтобы участники чувствовали себя непринужденно.
6. Дайте участнику возможность задавать вопросы перед началом тестирования
Это одна, но очень важная строка в вашем сценарии: не просите участника выполнять задачи, пока не убедитесь, что он располагает всей необходимой информацией и готов к тестированию. Также стоит предупредить его, что он может задавать любые вопросы в ходе тестирования.
7. Формулируйте задания так, чтобы они не повлияли на результаты
Чаще всего пользовательское тестирование проходит следующим образом: модератор ставит перед участником определенную задачу — выполнить действие или последовательность действий. Эти задачи различаются в зависимости от того, на какой платформе проводится тестирование, однако наиболее распространенные из них включают поиск конкретного товара, оформление возврата или создание профиля.
Не сомневайтесь, язык и манера выражения мыслей при постановке этих задач, обязательно повлияют на результаты. Как вы думаете, в чем заключается разница между “Теперь попробуйте найти мужские оксфордские рубашки” и “Теперь найди мужские оксфордские рубашки”?
Кажется, что здесь нет серьезных отличий, однако первая формулировка подразумевает, что задача является сложной или что платформа, на которой проходит тестирование, имеет плохой UX.
Каждый раз, когда участник думает, что от него ожидают определенного ответа, полученные данные являются нерепрезентативными. Это известная проблема качественных исследований, и хотя полностью побороть ее сложно, вы должны составить сценарий таким образом, чтобы свести к минимуму подобные ответы.
8. Задавайте открытые вопросы
В ходе выполнения участником задания модератор может задавать вопросы о полученном опыте. Если вы планируете включить такие промежуточные вопросы в свое исследование, убедитесь, что они краткие и точные, но при этом оставьте пользователям возможность выразить свои мысли, мнения и чувства.
Избегайте вопросов, на которые можно ответить “да” или “нет”, например, “Вам понравился полученный опыт?”, лучше задайте открытый вопрос: “Что вы думаете о полученном опыте?”
9. Приступайте к работе над сценарием
Если вы до сих пор не знаете, с чего начать или вам просто нужно вдохновение, в сети можно найти множество шаблонов таких сценариев. Вы обнаружите, что все они составлены в соответствии с моими рекомендациями. Вот один из шаблонов, который мне особенно нравится. Он создан гуру веб-дизайна Стивом Кругом.
Если вы хотите узнать больше полезной информации о том, как проводить пользовательские тестирования, изучите раздел, посвященный юзабилити-тестированию на нашем сайте. Помимо всего сказанного, лучший совет, который я могу вам дать — просто начните писать.
Источник: www.uprock.ru
Как написать тест-кейс
Создавайте простые тест-кейсы и учитывайте интересы пользователя.
Анастасия Хамидулина
Автор статьи
6 июня 2022 в 15:11
В тестировании, чтобы проверить, корректно ли работает программное обеспечение (ПО), делают определенные действия и сверяют полученный результат с ожидаемым. Другими словами — моделируют ситуацию работы ПО. Чтобы описать шаги, создают тест-кейсы.
Что такое тест-кейсы
Это четкое описание входных данных, условий и процедуры тестирования, ожидаемых результатов. Они определяют один сценарий — конкретную цель тестирования программного обеспечения. Целью может быть проверка ПО: соответствует ли оно требованиям.
Четко определенные тест-кейсы позволяют многократно запускать одни и те же тесты, применять для последовательно изменяющихся версий программного обеспечения. А еще отслеживать регрессивные ошибки ПО — то есть те, которые повторяются и ухудшают качество продукта.
Отличия
От чек-листа
В чек-листе перечисляют аспекты ПО, которые нужно проверить. Когда составляют тест-кейс, описывают состояние программного обеспечения и то, как его изменяют. То есть чек-листом определяют, что тестировать. А тест-кейсом — как тестировать. Чек-лист подойдет в качестве исходного документа, чтобы составить тест-кейсы.
От баг-репорта
Баг-репорт — это отчет об ошибке. Его составляют, когда находят ошибки в работе ПО. Тест-кейс же нужен, чтобы определить, есть ли ошибка. Он помогает составить качественный баг-репорт.
Виды тест-кейсов
Классификация зависит от типа входных данных, действий и ожидаемого поведения ПО.
1️⃣ Положительные. Подтверждают, что ПО соответствует требованиям. Показывают, что при корректных входных данных и действиях пользователя ПО выполняет функции.
2️⃣ Отрицательные. Показывают, что ПО способно обрабатывать некорректные входные данные или неверные действия пользователя. Например, выводить соответствующие сообщения, подсказывать, как исправить ситуацию.
3️⃣ Деструктивные. Демонстрируют, что никакие внешние воздействия или высокие нагрузки не приводят к потере данных пользователя, ПО можно использовать. Условие: нагрузки не разрушают аппаратную часть.
Пример
У вас есть требование к программной системе расписания занятий: «В систему нужно добавлять новые уроки».
Положительные тест-кейсы должны демонстрировать, что, если ввести корректные данные, новый урок появится в расписании.
Негативные попытаются сломать нормальную работу системы. Например, если добавляют урок, когда нет места в расписании, или не указывают его название.
Деструктивные покажут, сохранится ли расписание при сбоях. Например, если внезапно завершат программу или введут огромное количество данных за короткое время.
Жизненный цикл
У баг-репорта есть полноценный, развитый жизненный цикл. У тест-кейса — набор состояний. Они могут отличаться в зависимости от компании и возможностей систем управления тест-кейсами. Но обычно выделяют четыре состояния:
1️⃣ Не запускался. Тест-кейс создали, но тестирование по нему не проводили.
2️⃣ Пройден успешно. Ожидаемые и фактические результаты работы ПО совпадают.
3️⃣ Провален. Обнаружили дефект: ожидаемый результат минимум по одному шагу тест-кейса не совпадает с фактическим.
4️⃣ Пропущен. Тест-кейс отменили. Например, потому что изменили требования к ПО.
7 реальных историй тестировщиков из Skypro
Обязательные атрибуты
Они тоже зависят от внутренней культуры компании или возможностей систем управления тест-кейсами. И даже от типа тестируемого ПО. Но обычно выделяют следующие атрибуты:
✅ Уникальный идентификатор — некое уникальное значение. По нему на тест-кейс ссылаются из других документов или тест-кейсов. Бывает буквенным, числовым, буквенно-числовым. Чаще всего применяют простую сквозную нумерацию.
✅ Краткое описание — лаконичное описание сути тест-кейса. Может содержать ссылку на требование к ПО.
✅ Входные данные — сведения о первоначальном состоянии системы, которое важно для тест-кейса. А еще значения для ввода или передачи ПО.
✅ Шаги — полная последовательность действий. Ее выполняют, чтобы провести описываемую тест-кейсом проверку.
✅ Ожидаемый результат — описание планируемого поведения или результата ПО. Может базироваться на требовании к программному обеспечению, общей логике работы.
✅ Фактический результат — описание итогового поведения или результата ПО. Если они совпадают, это указывают. Когда не совпадают, подробно описывают расхождения. Пометка «не совпадает», «отличается» — это грубая ошибка.
✅ Статус — текущее состояние тест-кейса.
Правила составления тест-кейса
Создавайте простые тест-кейсы. То есть лаконичные и понятные не только вам. Используйте повелительное наклонение, например: «перейдите на домашнюю страницу», «введите данные», «нажмите здесь». Шаги должны быть четкие, без лишних деталей. Так проще понять шаги теста и ускорить работу.
Учитывайте интересы конечного пользователя. Конечная цель любого программного проекта — простое и понятное приложение, отвечающее запросу клиентов. Тестировщик создает тест-кейсы с учетом мнения конечного пользователя.
Избегайте повторов. Если тест-кейс нужен, чтобы выполнить другой тест-кейс, оставьте ссылку по идентификатору в столбце предварительного условия.
Не предполагайте. Не додумывайте функциональность и возможности ПО. Строго придерживайтесь спецификации.
Пишите тестовые примеры. Они должны покрывать все требования к ПО из спецификации. Используйте чек-листы и автоматизированные средства учета покрытия тестами. Это гарантия того, что ни одна функция или условие не останутся непроверенными.
Задавайте идентификатор тест-кейса. Так, чтобы его было легко идентифицировать. Например, когда отслеживают ошибки или определяют требования к ПО на более позднем этапе.
Внедряйте методы тестирования. Эти техники помогают спланировать несколько тест-кейсов и находить ошибки:
- анализ граничных значений — проверяйте верхние и нижние границы для допустимого диапазона значений;
- эквивалентное разделение — разбивайте диапазон всевозможных тест-кейсов на равные части/группы с одинаковым поведением;
- техника перехода состояний — создавайте тест-кейсы, которые покроют поведение ПО при переходе из одного состояния в другое.
Внедряйте самоочистку. Тест-кейс должен возвращать среду в предтестовое состояние. Особенно это касается тестирования конфигураций.
Создавайте повторяемые и самостоятельные текст-кейсы. Они должны всегда генерировать одинаковые результаты: независимо от того, кто их тестирует.
Проводите экспертную оценку. Отправляйте текст-кейсы на проверку коллегам. Они могут обнаружить ошибки в дизайне тест-кейса, которые вы пропустили.
Учитесь создавать тест-кейсы и системы управления ими на курсе «Инженер по тестированию» Skypro. Кроме этого узнаете, как писать чек-листы и тест-планы, составлять отчеты в системах отслеживания ошибок. Проведете функциональное, UX/UI- и регрессионное тестирование — и это только в одном модуле. На курсе рассмотрим еще и тестирование мобильных приложений и API, инструменты тестировщика.
На курсе больше 330 часов теории и практики, пройдете 7 мастер-классов, создадите 4 проекта для портфолио. Доступ к материалам останется навсегда.
Источник: sky.pro
Что такое тест кейс: пример и чек-лист тест кейсов для начинающих тестировщиков, которые подойдут каждому
Вы хотите узнать, по какой форме писать тест кейсы и увидеть пример правильного тест кейса? Мы собрали чек-лист из примеров и формы, как написать грамотный тест кейс по шаблону.
В этом материале о тест кейсах вы узнаете:
- Что такое тест кейс
- Из чего состоит тест кейс и какая у тест кейсов форма
- Правила написания хорошего тест кейса
- Типичные ошибки в тест кейсах
Что такое тест кейс
Тест кейс — это проверка работоспособности программы или проекта.
Написать тест кейс — значит создать текстовое описание процесса тестирования какой-то части или функции проекта.
Тест кейсы нужны, чтобы члены команды могли проверить программу и познакомиться с ней, не читая весь код, а изучив только тест кейс.
Хотите научиться писать правильные тест кейсы? Научиться писать тест кейсы вам помогут наши менторы-тестировщики!
Форма тест кейса: из чего состоит тест кейс и поля в тест кейсах
У стандартного тест кейса есть 5 частей, то есть 5 атрибутов тест кейса:
- Порядковый номер тест кейса
- Название тест кейса. Из него должно быть понятно, в чем суть тест кейса
- Предусловия тест кейса. Это условия, которые необходимы для проведения тест кейса. Они должны быть выполнены еще до запуска тест кейса.
Допустим: компания сдает самокаты в поминутную аренду. Нужно провести тест кейс функции, которая уведомляет пользователя о том, что заряд аккумулятора самоката. Предусловием тест кейса будет то, что самокат должен находиться в состоянии аренды - Порядок действий в тест кейсе и описания действий в тест кейсе
- Ожидаемый результат тест кейса.
Вот пример тест кейса:
Тест кейс №1
Название тест кейса: Уведомление пользователя о снижении заряда аккумулятора вручную
Предусловия тест кейса: статус самоката: в аренде
Шаги тест кейса:
- Шаг тест кейс №1: Зайти на сайт samokat.admin Логин — test, пароль — test
- Шаг тест кейса №2: Перейти на вкладку «Самокаты в аренде»
- Шаг тест кейса №3: Нажать…
- Шаг тест кейса №4: Включить…
- Шаг тест кейса №5: …
- Ожидаемый результат тест кейса Появляется сообщение об успешном выполнении тест кейса «Пользователь уведомлен о снижении заряда»
Как написать хороший тест кейс: правила и форма хороших тест кейсов
У тест кейса может быть 3 вида результатов:
- Положительный результат тест кейса. Фактический результат тест кейса совпадает с ожидаемым.
- Отрицательный результат тест кейса. Фактический результат тест кейса отличается от ожидаемого.
- Тест кейс не завершен. В процессе проверки тест кейса происходит ошибка.
Существуют 6 правил проведения тест кейсов:
- Один тест кейс должен проверять только одну конкретную вещь.
- Тест кейс не должен зависеть от других тест кейсов.
- Шаги и ожидаемый результат тест кейса должны быть сформулированы четко и однозначно.
- В тест кейсе должна быть вся информация. необходимая для его проведения.
- В тест кейсе не должно быть лишних деталей.
- Для каждого шага тест кейса нужно указывать тип вводимых данных: валидный или невалидный.
Типичные ошибки при написании тест кейсов
Абстрактное название тест кейса
Тест кейсы на одном проекте часто похожи друг на друга. Чтобы в них не было путаницы, названия должны быть конкретными и однозначными.
Плохо: Уведомление пользователя о заряде
Хорошо: Уведомление пользователя о снижении заряда аккумулятора вручную
Повелительное наклонение в тест кейсе
Это правило этикета тестировщиков.
Плохо: зайди на сайт; нажми на кнопку
Хорошо: зайти на сайт, нажать на кнопку
Не кликабельные ссылки
Не важно, это гиперссылки внутри вашей площадки или ссылки на какие-то внешние ресурсы. Вставили ссылку — нажмите «Ctrl + K». Добавьте тексту кликабельности.
Плохо: yandex.ru
Хорошо: yandex.ru
Лишние детали в тест кейсе
Тест кейс должны быть однозначно понятным, но и перегружать его лишними деталями не нужно.
Плохо: нажмите на красную кнопку с надписью «Войти» в верхнем правом углу экрана, под меню.
Хорошо: нажмите на кнопку «Войти»
Недостаток деталей для проведения тест кейса
Ошибка, обратная предыдущей. Хороший тест кейс — это тест кейс, все действия которого можно выполнить, основываясь только на тексте самого тест кейса.
Плохо: перейти в режим разработчика
Хорошо:
1) Открыть меню
2) Перейти во вкладку «Дополнительные возможности»
3) Нажать на кнопку «Включить режим разработчика»
Хотите избежать типичных ошибок в тест кейсах? Вам помогут наши менторы-тестировщики!
Источник: solvery.io