1 что означает тестирование удобства использования

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

Тестирование удобства пользования(Usability Testing).Иногда мы сталкиваемся с непонятными, нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. А значит они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее является неотъемлемой частью тестирования любых массовых продуктов.

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

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

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

правильность (accuracy) – сколько ошибок сделал пользователь во время работы с приложением? (меньше – лучше);

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

эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи – растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция – лучше).

Уровни проведения.Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке – тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода, и как следствие улучшить качество продукта в целом.

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

Советы по улучшению удобства пользования.Для дизайна удобных приложений полезно следовать принципам «пока–йока» или fail–safe. У нас это более известно как «защита от дурака». Простой пример, если поле требует цифровое значение, логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок. Для повышения юзабилити существующих приложений можно использовать цикл Демминга Plan–Do–Check–Act, собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

тестирование на практичность

4.50 тестирование на практичность (usability testing): Формальный процесс оценки соответствия документации установленным требованиям.

2.1.67 тестирование на практичность: Формальный процесс оценки соответствия документации установленным требованиям.

Словарь-справочник терминов нормативно-технической документации.
academic.ru.
2015.

Полезное

Смотреть что такое «тестирование на практичность» в других словарях:

  • тестирование — 3.22 тестирование : Процесс определения соответствия предмета испытания заявленным характеристикам. Источник …   Словарь-справочник терминов нормативно-технической документации

  • Тестирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен …   Википедия

  • ГОСТ Р ИСО/МЭК 15910-2002: Информационная технология. Процесс создания документации пользователя программного средства — Терминология ГОСТ Р ИСО/МЭК 15910 2002: Информационная технология. Процесс создания документации пользователя программного средства оригинал документа: 4.16 n штрих (en dash): Штрих, имеющий такую же ширину, как и строчная буква «n». Определения… …   Словарь-справочник терминов нормативно-технической документации

  • Р 50.1.048-2004: Информационно-телекоммуникационные игровые системы. Термины и определения — Терминология Р 50.1.048 2004: Информационно телекоммуникационные игровые системы. Термины и определения: 2.3.25 адаптивное сопровождение: Изменение программного продукта после поставки, обеспечивающее его работоспособное состояние в измененных… …   Словарь-справочник терминов нормативно-технической документации

  • Аналитик — (Analyst) Специалист, работник фирмы, банка Информация о сфере деятельности аналитиков, финансовая и бизнес аналитика, аналитика валютного и фондового рынка Содержание >>>>>>>> Аналитик это, оределение История Аналитика появилась тогда, когда… …   Энциклопедия инвестора

  • Юзабилити — Эту страницу предлагается объединить с Удобство. Пояснение причин и обсуждение на странице Википедия:К объединению/22 ноября 2012. Обсуждение длится одну неделю (или дольше, если оно идёт медленно) …   Википедия

  • Usability — Юзабилити (англ. usability дословно «удобство пользования», «применимость») понятие в микроэргономике, обозначающее общую степень удобства предмета при использовании; термин схож с термином «эргономичность», однако имеет иную область… …   Википедия

  • Веб-юзабилити — Юзабилити (англ. usability дословно «удобство пользования», «применимость») понятие в микроэргономике, обозначающее общую степень удобства предмета при использовании; термин схож с термином «эргономичность», однако имеет иную область… …   Википедия

  • Дружественный интерфейс — Юзабилити (англ. usability дословно «удобство пользования», «применимость») понятие в микроэргономике, обозначающее общую степень удобства предмета при использовании; термин схож с термином «эргономичность», однако имеет иную область… …   Википедия

  • Юзабилити-инженер — Юзабилити (англ. usability дословно «удобство пользования», «применимость») понятие в микроэргономике, обозначающее общую степень удобства предмета при использовании; термин схож с термином «эргономичность», однако имеет иную область… …   Википедия

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

Рассмотрим удобство использования с точки зрения человеческого фактора. Имелись ли какие-либо недоразумения в ходе анализа требований, на которые необходимо обратить внимание? Подходит ли программное обеспечение пользователю, становясь продолжением его рук? (Мы хотим, чтобы не только наши собственные инструменты были изготовлены по руке, но чтобы и те, которые мы создаем для пользователей, подходили им.)

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

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

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

Мы рассмотрели то, что подлежит тестированию. Теперь мы обратим внимание на то, как это делается, включая следующее:

• Регрессионное тестирование

• Тестовые данные

• Тестирование систем с графическим интерфейсом

• Тестирование самих тестов

• Исчерпывающее тестирование

Тестирование проектных решений/методологии

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

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

• Показатель цикломатической сложности Маккейба (измеряет сложность структуры решений)

• Коэффициент разветвления по входу при наследовании (количество базовых классов) и по выходу (количество производных модулей; используется в качестве родителя)

• Набор откликов (см. раздел «Несвязанность и закон Деметера»)

• Отношения связывания класса (см. [URL 48])

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

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

Регрессионное тестирование

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

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

Тестовые данные

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

Реальные данные исходят из некоего реального источника. Возможно, они были получены из существующей системы, конкурирующей системы или некоего прототипа. Они представляют типичные пользовательские данные. Большие сюрпризы возникают, как только вы открываете значение термина «типичный». При этом скорее всего являются дефекты и недоразумения в анализе требований.

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

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

• Вам необходимы данные для того, чтобы выделить определенные граничные условия. Эти данные могут быть полностью синтезированными: поля, содержащие дату 29 февраля 1999 г., огромные размеры записей или адреса с иностранными почтовыми индексами.

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

Читайте также:

©2015-2022 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-03-31
Нарушение авторских прав и Нарушение персональных данных



Поиск по сайту:


Мы поможем в написании ваших работ!

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

  • Функциональные.

  • Нефункциональные.

  • Связанные
    с изменениями.

1.1.5.1. Функциональные виды тестирования

  1. Функциональное
    тестирование
    рассматривает заранее
    указанное поведение и основывается на
    анализе спецификаций функциональности
    компонента или системы в целом.

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

Преимущества функционального тестирования:

  • имитирует
    фактическое использование системы;

Недостатки функционального тестирования:

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

  • вероятность
    избыточного тестирования.

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

Общая стратегия безопасности основывается
на трех основных принципах:

  • Конфиденциальность;

  • Целостность;

  • Доступность;

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

Существует два основных критерия при
определении понятия целостности:

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

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

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

  1. Тестирование
    взаимодействия —
    это функциональное
    тестирование, проверяющее способность
    приложения взаимодействовать с одним
    и более компонентами или системами и
    включающее в себя тестирование
    совместимости (compatibility
    testing) и интеграционное
    тестирование (integration
    testing).

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

1.1.5.2. Нефункциональные виды тестирования

  1. Нагрузочное тестирование или
    тестирование производительности — это
    автоматизированное тестирование,
    имитирующее работу определенного
    количества бизнес пользователей на
    каком либо общем (разделяемом ими)
    ресурсе.

  • Тестирование
    производительности (Performance testing):

Задачей тестирования производительности
является определение масштабируемости
приложения под нагрузкой, при этом
происходит:

измерение
времени выполнения выбранных операций
при определенных интенсивностях
выполнения этих операций

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

  • Стрессовое
    тестирование (Stress Testing):

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

  • Объемное
    тестирование (Volume Testing):

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


измерение времени выполнения выбранных
операций при определенных интенсивностях
выполнения этих операций


может производиться определение
количества пользователей, одновременно
работающих с приложением

  • Тестирование
    стабильности или надежности (Stability /
    Reliability Testing):

  1. Тестирование
    Установки (Installation Testing).
    Тестирование
    установки направленно на проверку
    успешной инсталляции и настройки, а
    также обновления или удаления программного
    обеспечения.

  2. Тестирование
    удобства пользования (Usability Testing.

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

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

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

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

  • правильность
    (accuracy) — сколько ошибок сделал пользователь
    во время работы с приложением? (меньше
    — лучше)

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

  • эмоциональная
    реакция (emotional response) – как пользователь
    себя чувствует после завершения задачи
    — растерян, испытал стресс? Порекомендует
    ли пользователь систему своим друзьям?
    (положительная реакция — лучше)

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

  1. Тестирование
    на отказ и восстановление (Failover and
    Recovery Testing)
    проверяет тестируемый
    продукт с точки зрения способности
    противостоять и успешно восстанавливаться
    после возможных сбоев, возникших в
    связи с ошибками программного обеспечения,
    отказами оборудования или проблемами
    связи (например, отказ сети). Целью
    данного вида тестирования является
    проверка систем восстановления (или
    дублирующих основной функционал
    систем), которые, в случае возникновения
    сбоев, обеспечат сохранность и целостность
    данных тестируемого продукта.

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

В зависимости от типа проекта
конфигурационное тестирование может
иметь разные цели:

  • Проект
    по профилированию работы системы:

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

  • Проект
    по миграции системы с одной платформы
    на другую:

Цель Тестирования: Проверить объект
тестирования на совместимость с
объявленным в спецификации оборудованием,
операционными системами и программными
продуктами третьих фирм.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

1. Тестирование удобства использования

2. Введение

Удобство использования, юзабилити (usability ) — это научноприкладная дисциплина, занимающаяся повышением
эффективности, продуктивности и удобства пользования
инструментами деятельности. От эргономики юзабилити отличает
заинтересованность в эффективности работы пользователя
(потребителя), а не человеко-машинной системы в целом
Международная организация стандартизации (ISO) дает следующее
определение: Удобство применения – это эффективность,
рентабельность и удовлетворение, с которым пользователи могут
выполнить те или иные задачи в заданной среде . Тестирование на
удобство применения проводится для того, чтобы оценить качество
работы продукта и выяснить, насколько он эффективен, рентабелен
и довольны ли им пользователи.

3. Определение удобства использования и его тестирование

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

4. Факторы, влияющие на уровень удобства использования

Тестирование удобства пользования дает оценку уровня удобства
использования приложения по следующим пунктам:
Простота изучения: насколько быстро пользователь, который никогда
прежде не видел интерфейса, может изучить его достаточно хорошо, чтобы
решать базовые задачи?
Эффективность использования: насколько быстро опытный пользователь,
однажды изучивший систему, может решать задачи?
Запоминаемость: если пользователь работал с системой раньше, будет ли он
помнить достаточно, чтобы эффективно её использовать в следующий раз?
Или ему придётся учиться всему заново?
Частота и серьёзность ошибок: насколько часто пользователи ошибаются,
работая с системой, насколько серьёзными являются последствия таких
ошибок и как пользователи исправляют эти последствия?
Личное удовлетворение: насколько пользователю нравится работать с
системой?

5. Цели разработки

Почему вы разрабатываете этот продукт
(программу, сайт);
Кто будет пользоваться вашим продуктом
(какова будет целевая аудитория);
Когда и зачем эти люди могут
использовать ваш продукт (программу,
сайт).

6. Основные тезисы тестирования

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

7. Основные тезисы тестирования

4. Тестирование юзабилити поможет ответить на
следующие вопросы:
Понимают ли пользователи основное назначение
продукта?
Могут ли пользователи найти в продукте нужную
функцию?
Насколько простым находят пользователи
использование функций продукта?
Насколько простым является для пользователей
заполнение форм(регистрация, авторизация, подачи
всевозможных запросов)?
Достигаются ли цели, которые определили владельцы
продукта и его пользователи?

8. Основные тезисы тестирования

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

9. Основные тезисы тестирования

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

10. Основные тезисы тестирования

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

11. Основные тезисы тестирования

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

12. Требования к юзабилити приложения

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

13. Заблуждения о тестировании удобства пользования

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

14. Заблуждения о тестировании удобства пользования

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

15. Способы проведения тестирования

Существуют следующие способы проведения
тестирования:
наблюдение;
карточная сортировка;
проведение опросов и исследований;
прототипирование;
контекстуальные исследования;
эвристическое исследование;
работа с выделенными группами
(фокусные группы).

16. Наблюдение

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

17. Наблюдение

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

18. Карточная сортировка (card sorting)

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

19. Опросы и исследования

Испытателям (пользователям продукта)
предоставляется анкета со списком вопросов, на
которые им необходимо ответить.
Есть 2 варианта развития событий:
1. Респонденты заполняют анкету сразу после сессии
тестирования юзабилити
2. Респонденты отправляют анкету по электронной
почте ответив на вопросы исходя из своего опыта
работы с приложением.
После, полученные анкеты подлежат анализу.

20. Прототирирование (prototyping)

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

21. Горизонтальное прототирирование

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

22. Вертикальное прототирирование

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

23. Контекстное исследование (contextual inquiry)

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

24. Контекстуальные исследования

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

25. Эвристическое исследование

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

26. Фокусные группы

Фокусная группа (focus group) это неформальное
собрание пользователей, у которых спрашивают мнение
по определенной теме. Цель данных опросов —
выяснить у пользователей их отношение и восприятие
темы, а также их идеи и мнения по ней (обычно 7-10
человек)
Задачи: собрать первоначальные мнения об интерфейсе,
проверить, насколько он соответствует ожиданиям,
выяснить, что вызывает вопросы. Такое исследование
позволяет сузить круг проблем и выдвинуть гипотезы
для их дальнейшего решения.

27. Фокусные группы

Опрос специально отобранной группы
Длительность: около 2 часов
Количество: 6-9 пользователей
Позволяют выявить спонтанные реакции и идеи
и оценивать отношение к этим идеям группы в
целом.
Ведущий должен иметь предварительный
сценарий работы, и следить, чтобы групповая
дискуссия не выходила из русла обсуждаемой
проблемы.

28. Фокусные группы

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

29. Оценочные листы

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

30. Общий оценочный лист тестирования usability web-сайта

31. Плюралистическая проработка

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

32. Протоколы самоотчёта (Self-Reporting Logs)

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

33. Экспертиза компонентов (Feature Inspection)

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

34. Экспертиза компонентов (Feature Inspection)

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

35. Написание итогового отчета

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