Оценивается критичность ошибки в юзабилити тестировании

Поможем в ✍️ написании учебной работы

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

Помимо технологии Eye-tracking, где объектом исследования служит направленность взора пользователя, Mouse-tracker представляет собой программное обеспечение, которое позволяет определять в реальном времени координаты компьютерной мыши, затем визуализировать, обрабатывать и анализировать их.

Принцип работы Mouse-tracker основан на «записи в реальном времени Х-, Y-координаты компьютерной мыши в пикселях и продолжительность задержки в данной точке. Получение такого рода информации требует определенных технологий и методов, которые в настоящее время используется» [14]:

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

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

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

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

Рис. 3. Пример тепловой карты Mouse-tracker

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

Стоит отметить, что тепловые карты mouse-tracker и eye-tracker основываются на разных количественных данных, что означает разное формирование карт.

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

Основными преимуществами технологии mouse-tracker в сравнении с технологией eye-tracker являются следующие качества:

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

— посетители не чувствуют наблюдения за действиями, тем самым более расслаблены.

— массовое исследование, тестирование всех посетителей.

— стоимость программного обеспечения значительно ниже.

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

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

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

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

Основные характеристики юзабилити из стандарта по взаимодействию «человек-система» ГОСТ ИСО 9241-210-2012 включает в себя три базовые характеристики юзабилити и показатели оценки качества (табл. 3).

Таблица 3

Количественные измерения четырех показателей юзабилити в соответствии с базовыми характеристиками

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

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

1. Общее время, время выполнения задачи и время, потраченное на обнаружение и исправление ошибок.

2. Процент или количество:

— выполненных задач;

— сделанных пользователем ошибок;

— участников, показавших более высокие результаты;

— благоприятных/неблагоприятных отзывов пользователя;

— раз использования помощи или документации;

— раз интерфейс вводил пользователя в заблуждение

— повторений неудавшихся действий;

— возвратов назад в действиях;

— произведенных действий;

— раз пользователи отрывались от работы;

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

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

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

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

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

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

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

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

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

Качественные методы осуществляют сбор данных в свободной форме. Они фокусируются не на статистических измерениях, а опираются на интерпретацию, объяснение, понимание и эмпирические данные, которые определяются как источник формирования продуктивных идей и гипотез. Проблемой методов качественных исследований является получение разведочных данных, а не количественное распределение суждений. В качественных методах для объяснения и интерпретации понятия, применяются слова, а не цифры. Иначе говоря, они отвечают не на вопрос «сколько», а на вопросы «что», «как» и «почему» [91].

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

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

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

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

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

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

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

— в случае оценки спецификации требований на этапе анализа проекта показатели качества должны быть выбраны из совокупности показателей внешнего качества и показателей качества использования;

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

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

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

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

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

Спецификация методов оценки должна полностью определять компоненты продукции, к которым эти методы следует применять.

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

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

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

Для возможных ошибок измерения, вызванных измерительными инструментами или человеческими ошибками, должен быть определен допустимый диапазон ошибок [41].

Спецификация оценки должна включать в себя следующее:

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

— перекрестные ссылки между информацией, необходимой для выполнения оценки, компонентами целевой продукции и другими соответствующими документами, перечисленными в описании продукции;

— спецификация выполняемых измерений и проверок со ссылками на компоненты целевой ИС;

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

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

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

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

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

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

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

-оценить качество промежуточных продуктов, чтобы определить, удовлетворяются ли требования к качеству;

— предсказать качество конечного продукта.

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

Технология Eye-tracking

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

Разнообразие дисциплин, использующих в своих исследованиях технологию eye-tracking, охватывает ряд областей: когнитивные науки, психологию, взаимодействие «человек-система», маркетинговые исследования, медицинские исследования (неврологическая диагностика) [96]. Юзабилити исследования также включает в себя взаимодействие с перечисленными дисциплинами, что объясняет эффективность использования технологии eye-tracking при оценки качества информационных систем.

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

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

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

— позволяет определить то, что является значимым для целевого пользователя, и что они игнорируют;

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

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

Исследования движения глаз в XIX в. проводилось при помощи простых наблюдений, которые занимали много времени на сбор и обработку полученной информации. Прежде основной сферой применения eye-tracking глаз было исследование психологических принципов зрительного восприятия человека. В последнее десятилетие благодаря созданию эффективных «eye-tracker», мощных программных средств обработки информации о реакции глаза на различные виды воздействий началось стремительное расширение сфер применения данного метода.

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

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

Рис. 4. Установка электродов при регистрации электроокулограммы

Недостатки метода — низкая разрешающая способность (точность разганиченности мелких деталей 3º–5º), достоинством метода отмечают низкую стоимость оборудования. Регистрация движений глаз не нарушает естественных условий зрительной активности испытуемого и может проводится как на свету, так и в темноте, даже с закрытыми глазами.

Фотооптический метод разработан «А. Л. Ярбусом в 50-е годы XX века. Узкий пучок света, направленный на глазное яблоко, отражается от установленного на нем миниатюрного зеркальца и поступает на вход фоторегистрирующего устройства» [39]. Достоинством данного метода является высокая разрешающая способность, недостатком проявляется потребность в строгой фиксации головы испытуемого, контактный вид методики, регистрацию проводят исключительно в затемненном помещении. В настоящее время этот метод не используют.

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

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

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

«На изображении программно определяется положение зрачка (в ИК лучах он представляет собой темный овал) и его размеры, а также позиция роговичного блика, представляющего собой отражение на роговице источника инфракрасного света. Направление взгляда система рассчитывает, основываясь на векторе, соединяющем позиции роговичного блика и центра зрачка» [92]. Достоинством методики определяют бесконтактный характер и возможность регистрации величины раскрытия.

В последние годы процесс регистрации точек фиксации взгляда и движения глаз полностью автоматизировался. Применяемые устройства eye-tracker эффективны в поддержке исследователей при изучении процессов юзабилити тестирования, позволяя получить до 80% необходимой информации. Особенностью исследований по технологии «Eye-tracking» является достаточно сложная процедура обработки данных.

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

Рис. 5. Eye-tracking на основе видеозаписи глаз

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

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

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

Рис. 6. Слева — установка системы, использующая камеру. Справа — блик на роговице глаза

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

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

Несколько десятков раз в секунду eye-tracker считывает координаты траектории взгляда, если они остаются неизменными, суммируется время. При превышении некоторого порогового значения – приблизительно 100 миллисекунд – прибор отмечает фиксацию. Учитывая, что глаза здорового человека постоянно находятся в состоянии движения, даже когда он смотрит в одну точку, координатам взгляда добавляется пороговый радиус (30 или 50 пикселей). В случае если значения координат остаются внутри заданного круга, тогда фиксация продолжается, если выходят – начинается отсчет новой фиксации.

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

Впоследствии вектор переводится в экранные координаты. Также eye-tracker записывает время, координаты и длительность фиксации траектории взгляда человека.

Обработка данных eye-tracker связана с выделением на каждом кадре видеоряда темного эллипса, представляющего собой изображение зрачка, и светлой точки – роговичного блика. Выводом диагностики изображения являются шесть чисел:

— X и Y значения координат центра зрачка (измеряется в пикселях на исходном кадре видеоряда);

— X и Y значения координаты роговичного блика (также в пикселях на исходном кадре видеоряда);

— высота и ширина эллипса, соответствующего зрачку.

Одновременно с записью данных, происходит вычисление траектории движения глаз. Взгляд человека движется рывками, перемещаясь от одной точки к другой. Быстрые движения взгляда называется «саккадами (succade), точки, на которых взгляд останавливается – точками фиксации или просто фиксациями (fixation). В русскоязычной интерпретации чаще всего под «взглядом» (в контексте eye-tracking’а) понимаются именно фиксации» [39]. Во время фиксаций анализатор человеческого мозга получает значительное количество информации. Продолжительность фиксаций, в среднем, находится в интервале от 200 мс во время чтения текста до 350 мс во время изучения статического изображения. Время процесса движения взгляда от одной точки фиксации к другой (саккада) занимает до 200 мс. Описанные показатели являются количественными, более подробно они представлены в таблице 4″ [63].

Таблица 4

Количественные показатели eye-tracker

Метрики движения глаз Значение метрики
Общее число фиксаций Большее общее число фиксаций означает наименее рациональный поиск требуемой информации (возможно из-за сложного дизайна продукта/интерфейса).
Число фиксаций на регион интереса Большее число фиксаций показывает большую привлекательность или значимость соответствующего региона интереса.
Число фиксаций на зону интереса, скорректированное относительно текста Если регион интереса содержит только текст, то среднее число фиксаций на этом регионе должно быть поделено на среднее число слов в тексте. Это обуславливается тем, что:
1) Большое число слов в тексте требует большего числа фиксаций,
2) Большое количество символов требует больше усилий для чтения и усвоения информации.
Интервал фиксации Интервал фиксации отражает трудности в извлечении информации того или иного объекта.
Сумма продолжительностей
фиксаций в определенной зоне 		Применяется для измерения распределения внимания среди различных зон.
Пространственная плотность
фиксаций 		Число фиксаций, сконцентрированных в одной небольшой зоне, отображает эффективность и рациональность поиска информации. Широко распределенные фиксации отражают неэффективность поиска.
Время до первой фиксации на объекте Чем короче время до первой фиксации на объекте, тем объект обладает более привлекательными качествами.
Пост фиксация Число фиксаций вне объекта после фиксации на требуемом объекте показывает низкую видимость объекта.
Процент фиксаций испытуемых на регионе интереса Если процент фиксаций всех испытуемых на регионе интереса был низок, то этот регион должен быть каким-то образом выделен или перемещен.
Соотношение фиксаций на объекте к числувсех фиксаций Чем ниже данный показатель, тем неэффективен поиск данного объекта.
Число саккад Большее число саккад указывают на более долгий поиск.
Смещение саккады Угол между двумя саккадами больше 90 градусов отображает резкую смену направления взгляда. Из этого можно судить о нерациональном дизайне интерфейса/продукта.
Регрессия саккад Регрессия саккад указывает на присутствие менее значимых объектов.
Длина пути взгляда Чем длиннее путь взгляда, тем неэффективен поиск требуемой информации.
Закономерность пути взгляда Если обнаружен так называемый «путь взгляда по кругу», то это показывает возникшие у испытуемого проблемы с поиском(возможно из-за сложного дизайна или слабых навыков испытуемого).

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

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

— суммарное время рассматривания каждой из областей;

— число фиксаций в каждой из областей;

— средняя продолжительность фиксаций в каждой из областей;

— порядок рассматривания.

При использовании специального программного обеспечения полученные качественные данные можно привести в более наглядную форму. R&B Group выделяют пять видов визуализации результатов полученной информации.

График взгляда (Рис.7) отображает последовательность перемещения, очередность и длительность взгляда, а также движения взгляда каждого респондента в отдельности.

Рис. 7. График взгляда захвата движения глаз записанная с помощью eye-tracker

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

Рис. 8. Тепловая карта захвата движения глаз записанная с помощью eye-tracker

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

Рис. 9. карты взгляда «пчелиный рой» записанный с помощью eye-tracker

Кластерный анализ (Рис.9) самостоятельно формирует близлежащие фиксации в кластеры, отображая процент респондентов, заинтересованных данными кластерами;

Рис. 10. Кластерный анализ захвата движения глаз записанная с помощью eye-tracker

Зоны интереса (Рис.11) отображает отношение респондентов к определенно заданным областям изображения. Предоставляет статистические данные.

Рис. 11. Зоны интереса захвата движения глаз записанная с помощью eye-tracker

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

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

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

Таким

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

Что такое юзабилити и зачем это нужно

Для начала разберемся, что такое юзабилити и как оно влияет на конверсию сайта и восприятие пользователей.

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

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

Нестандартная навигация на сайте

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

Когда нужно проводить юзабилити-тестирование

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

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

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

Подготовка к юзабилити-тестированию

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

Этот этап называется планированием тестирования. Команда проекта составляет план на основе нескольких аспектов.

1. Известные проблемные места

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

Простая веб-форма

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

Когда нужно проводить юзабилити-тестирование

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

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

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

Подготовка к юзабилити-тестированию

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

Этот этап называется планированием тестирования. Команда проекта составляет план на основе нескольких аспектов.

1. Известные проблемные места

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

Простая веб-форма

2. Сценарии пользователей

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

3. Вопросы

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

4. Гипотезы

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

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

Методы юзабилити-тестирования: какой выбрать

Юзабилити можно измерить различными способами. Выбор метода зависит от поставленных задач, отведенного времени на реализацию и заложенного бюджета (иногда применяют специальное ПО и оборудование). Рассмотрим основные способы юзабилити-тестирования.

1. Наблюдение за респондентом

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

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

2. Глубинное интервью

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

3. Фокус-группа

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

4. А/В тестирование

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

5. Айтрекинг

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

Пример использования айтрекинга

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

Классический метод юзабилити-тестирования первый: наблюдение за некоторым количеством респондентов (от 10 до 100, в зависимости от задачи) и оценка сервиса по некоторым критериям. Каким — расскажем далее.

Метрики юзабилити-тестирования

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

1. Эффективность выполнения заданий

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

  • выполнил без проблем — 100%;
  • столкнулся с проблемами при выполнении — 50%;
  • не сделал вообще — 0%.

После тестирования всей группы высчитывается среднее значение.

2. Количество ошибок

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

3. Удобство ориентирования на сайте

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

ориентирование на сайте

4. Удовлетворенность сервисом

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

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

Использование результатов теста

Классическое юзабилити-тестирование предполагает получение метрик как иллюстрацию общего состояния ресурса. Мнение, опыт и восприятие каждого респондента субъективно, поэтому мы можем делать только общие выводы.

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

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

результаты теста

3 совета по улучшению юзабилити сайта

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

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

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

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

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

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

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

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

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

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

1. Физический способ тестирования (лицом к лицу)

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

2. Виртуальный способ тестирования (через общий доступ к экрану)

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

Итак, теперь вы знаете, какие категории тестирования вы можете проводить, и как оценивать пользователей лично или удаленно. Вы, вероятно, спрашиваете: «Как мне все это сделать подешевле?» Я так рад, что вы спросили

Оптимальные по цене и качеству сервисы для тестирования

Существует множество способов быстрой оценки юзабилити сайта. Вы можете попробовать эти: 5-Second Usability Tests , Click Tests , Open Ended Question Tests, Navigation Tests , Preference Tests , Survey Monkey , Hallway Tests (попробуйте лично или через презентацию в Skype, Google Hangouts)

Примечание автора: Отечественные сервисы для проведения юзабилити-тестирования: https://uxcrowd.ru , http://sitepolice.ru/ , https://www.userpoint.ru/ , Вебвизор

5 примеров сбора обратной связи

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

1. Может ли пользователь легко объяснить, что вы продаете?

2. Какую информация или функции ожидают пользователи найти на вашем сайте (или не ожидают)

3. Нашел пользователь что-то полезное для себя?

4. Что удобно, что неудобно? Где сайт может работать лучше?

5. Что жизненно необходимо добавить на вашем сайте?

1. Определите цели исследования.

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

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

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

4. Задавайте открытые вопросы.
 Разговорите респондентов.

5. Используйте сегментацию.
Сегментируйте своих пользователей в зависимости от их показателей LTV (пожизненная ценность клиента).

6. Спланируйте действия, которые ваши респонденты должны выполнить
. Они должны основываться на первичных, вторичных и третичных функциях вашего продукта.

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

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

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

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

Если вы используете эти советы, то влюбитесь в тестирование так же как и мы

Анализ результатов

Хорошо, у вас есть куча цифр — что теперь?

Есть два способа превратить ваши количественные результаты в идеи:

1. Числовой: собирать данные в числовом формате, смотреть на цифры и искать зависимости.

2. Субъективный: спросить у самих пользователей нравиться или не нравиться им продукт

Для субъективного метода анализа вам понадобится числовая шкала. Напишете все важные технические характеристики и попросите пользователя оценить их удобство по шкале от 1 до 5.

Используйте цифровую шкалу, которая работает более 30 лет. Шкала называется SUS (от англ. System Usability Scale — шкала юзабилити системы). Это шкала Ликерта, которая была изобретена Джоном Бруком еще в 1986 году.Чаще всего это десять вопросов, по которым пользователи оценивают свою удовлетворенность продуктом.

Числовой метод поможет вам гораздо быстрее найти зависимости, чем пересмотр каждой анкеты пользователя. Покажем на примере сервиса Unbounce как использовать SUS Brooke.

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

Мы постоянно тестируем A / B на наших целевых страницах в Unbounce. Вот результат теста, который мы провели в Unbounce на странице с примерами наших работ. Наша команда дизайнеров предположила, что посетители могут лучше конвертироваться, если внесем следующие правки: подчеркнем призыв к действию, настроим обратную связь, сделаем форму более интерактивной. Эти изменения улучшили коэффициент конверсии на 61%. Это круто!

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

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

Что важно

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

  • С чего начинать?
  • Какие этапы нужно пройти?
  • Как не упускать важные детали?
  • Какие ловушки придется преодолеть?
  • Как получать валидные и значимые данные?

В планировании поможет следующий алгоритм.

Этап 1: Определите цель

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

Тест может включать общие вопросы:

  • Какая навигация улучшает пользовательский опыт?
  • Как посетители взаимодействуют с приложением / сайтом?

Или специфичные:

  • Что мешает пользователям совершать целевое действие на сайте?
  • Что при оформлении заказа привлекает внимание?

Однако чем больше вопросов в программе исследования, тем шире поле для ошибок в интерпретации. Спрашивайте только то, что помогает в достижении цели.

Этап 2: Привлекайте правильных участников

Это посетители сайта и целевые пользователи.

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

Определите число участников. Обычно от 3 до 8. Чем их больше, тем больше ошибок юзабилити можно выявить. Так выглядит эта зависимость:

Этап 3: Выберите формат

Персональное юзабилити-тестирование

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

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

Удаленное юзабилити-тестирование

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

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

Этап 4: Сформулируйте задачи / сценарии

Вот два вида задач:

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

Важно найти золотую середину. Как это сделать?

Требования к задачам

  • Задача ≠ вопрос

Почему? Нет никакой пользы от вопросов с предсказуемыми или «от балды» ответами.

  • Конкретные формулировки

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

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

  • Избегайте инструкций

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

  • Создайте условия, близкие к реальным

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

Этап 5: Составьте вопросники

Есть два основных типа вопросников для юзабилити-тестов.

Предварительные вопросники

Как часто вы покупаете онлайн?

  • Никогда;
  • Покупал(а) 1-2 раза в прошлом году;
  • Примерно 3-7 раз в год;
  • Регулярно (укажите, как часто).

Вы оцениваете, как эффективнее вовлечь целевую аудиторию и от чего это зависит.

Послетестовые вопросники

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

Как вам приложение?

  • Легко использовать;
  • Сложно использовать.

Пожалуйста, объясните, почему вы так считаете? (открытый вопрос).

Этап 6: Проведите пробный запуск

«Репетиция» исследования помогает оценить готовность, выявить и устранить проблемы на раннем этапе.

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

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

Если пилотный запуск успешный, он также дает полезные, а порой неожиданные открытия.

Важно! Привлекайте пользователей, которые не знакомы со всеми нюансами системы, которую вы тестируете.

Этап 7: Фиксируйте результаты

Универсального метода анализа данных нет. Выберите то, что работает для вас.

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

Кейс: юзабилити-тест в действии

Цель: ответить на вопросы и изменить нужные разделы сайта:

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

Дизайн продукта, сайта или приложения — весьма длительный процесс, требующий терпения, проницательности и наличия ряда инструментов. Чтобы понять, что в действительности работает, а что нет, важно знать мнение пользователей. Здесь-то и приходит на помощь пользовательское тестирование (user testing).

Объединив усилия, UXPin, UserTesting и Optimal Workshop решили описать UX-процесс, которому они следовали для гипотетического Yelp:

Весь процесс скорее напоминал дизайн-спринт, состоящий из 1-3 недельных проектов, сфокусированных на решении конкретных задач.

Краткий обзор процесса UX-дизайна

1. Определение продукта

На начальном этапе специалисты определили ценностное предложение (value proposition), незаслуженное преимущество (unfair advantage) и общую бизнес-модель. Поскольку Yelp уже добился значительного успеха в привлечении посетителей, они решили, что было бы интересно понять, как можно повысить частоту использования (frequency of use). Далее был разработан общий план тестирования.

2. Тестирование и анализ

На этапе исследования команда рассмотрела в деталях план тестирования и перешла к немодерируемым сессиям. Была определена демография пользователей и детализированы конкретные задачи. В ходе работы использовались различные методы тестирования, начиная от анализа записей взаимодействий пользователей с сайтом, удаленной карточной сортировки (card sorting) и тестирования первого клика (first-click testing).

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

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

  • Переработка текста.
     В целях извлечения максимальной пользы специалисты несколько раз корректировали инструкции, чтобы язык был как можно более лаконичным и побуждал к конкретным действиям. Это непременное условие для удаленных немодерируемых тестирований, поскольку письменные инструкции являются единственными директивами для участников.
  • Проведение (pilot test).
     Как только инструкции были готовы, было проведено немодерируемое удаленное тестирование с одним пользователем из группы тестирования. Он также оставил отзыв касательно самих инструкций, чтобы команда могла исправить мелкие недочеты и обеспечить полную ясность.
  • Обеспечение задач релевантными вопросами.
     По каждому заданию участник тестирования должен был ответить на вопрос «Была ли выполнена задача?», а также «Оцените уровень ее легкости/сложности». Ответ на первый вопрос давал понять, осуществима ли задача; в то время как второй — позволял углубиться в возможные улучшения дизайна.
  • Избегание наводящих вопросов.
     При тестировании использовался такой, к примеру, вопрос, как «Насколько легко или трудно было вам выполнить эту задачу?» вместо «Насколько трудно было выполнить эту задачу?», что предотвращает вероятность необъективного ответа.

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

3. Дизайн и итерация

Глен Липка (Glen Lipka), вице-президент User Experience, считает, что последовательный (UI, user interface) лучше, чем совершенный пользовательский интерфейс. Последовательность порождает узнаваемость, которая в свою очередь способствует более частому обращению. Ниже приводятся несколько руководящих принципов:

  • Дизайн для информации.
     Люди используют веб-сайты не для того, чтобы восхищаться красивыми дизайнами, но потому что им нужен контент. В описываемом случае, учитывая, что Yelp — это сайт для поиска на местном рынке услуг, редизайн нуждался в лучшей доставке нужной информации нужным людям, и тестирование информационной архитектуры при помощи карточной сортировки было неотъемлемой частью этого процесса.
  • Следование принципу MAYA (Most Advanced Yet Acceptable)
    , «наиболее передовой и в то же время воспринимаемый». В то время как команда хотела обеспечить лучший опыт для изредка заходящих на сайт Yelp пользователей, они не хотели создать нечто настолько чужеродное, что могло бы оттолкнуть опытных пользователей или запутать новых.
  • Изучение паттернов пользовательских интерфейсов.
     Были изучены существующие модели пользовательского интерфейса на других известных сайтах и найдено то, что можно было перенять у них.
  • Сделать сайт приятным и удобным для использования (usable).
     Опыт для изредка заходящих на сайт Yelp пользователей должен был быть более понятным. В то же время, специалисты хотели сохранить приятный внешний вид сайта.

Конечная цель состояла в достижении локального максимума (local maximum). Проект был завершен как только затраты превысили выгоды дополнительной итерации. С учетом ограниченности по времени дизайн-спринта, разработчики не зацикливались на получении глобального максимума (global maximum).

Понимание вашего бизнеса перед проведением тестирования

Прежде чем начать работу над UX, вы должны сперва понять свой бизнес. Какие проблемы он решает, каким образом приносит деньги? В чем он успешен, а в чем его можно улучшить?

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

Для первого шага специалисты выбрали , поскольку это легкая и вместе с тем всесторонняя визуализация бизнеса:

Не будем утомлять вас всей документацией, поэтому просто посмотрим на то, как вы можете сделать это в целях UX на примере Yelp:

  • Самая главная проблема: Люди в определенном городе хотят получить [лучший / быстрый / самый дешевый / самый простой] [продукт / услугу].
  • 3 самые основные функции: Отзывы пользователей, лента активности (activity stream), поиск по городу / категории.
  • Уникальное ценностное предложение: Возможность вносить компании в список, добавлять отзывы и видеть компании, рекомендованные друзьями и другими пользователями.
  • «Несправедливое преимущество» (то, что не может быть скопировано или куплено): Сетевые эффекты (network effects) наличия большой базы пользователей.

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

2. Определение объектов пользовательского тестирования

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

  • Какие функции используют люди при выборе ресторана? (например, фотографии, рейтинг и т.д.)
  • Могут ли пользователи выбрать ресторан на основе нескольких конкретных критериев?
  • Знают ли пользователи, как сохранять варианты?
  • Могут ли они узнать, открыто ли конкретное место в данный момент?

3. Выбор методов тестирования

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

Планирование и сбор качественных данных (qualitative data)

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

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

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

Такие критерии отбора как возраст, пол, уровень дохода или уровень владения интернетом были не важны. Поскольку это исследование проводилось исключительно с целью качественного анализа, специлаисты не нуждались в (statistical significance) для подтверждения полученных данных. Они последовали лучшим отраслевым практикам и провели свое исследование с участием 5 пользователей. И, наконец, для простоты дизайн-спринта они тестировали сайт Yelp только на стационарном компьютере.

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

Задания общего характера включали в себя:

  • Сфокусированное задание — найти компанию на основании конкретных параметров
  • Открытое задание — найти компанию при наличии очень малого количества директив
  • Очень конкретное задание — найти определенное место и узнать конкретную информацию о нем

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

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

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

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

Качественный анализ пользовательского исследования

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

1. Функция поиска была основной отправной точкой для любой задачи.

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

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

2. Вкладка «События» не была достаточно заметной.

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

Как ни странно, никто не воспользовался вкладкой «События». Один из участников теста обратился к панели поиска, а другой перешел в категорию «Искусство и Развлечения».

3. Функция закладок оказалось непонятной, а также никто не использовал списки.

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

Из трех участников:

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

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

4. Поиск конкретного места оказалось очень быстрым и легким заданием.

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

5. Пользователи руководствовались фотографиями для определения атмосферы ресторана.

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

6. Фильтры использовались участниками, но могут быть улучшены.

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

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

Когда участники искали ресторан по определенным параметрам, одним из требований было найти ресторан в пределах $ 20/чел. Двое из пяти пользователей были сбиты с толку, в какую категорию следует отнести ресторан с таким бюджетом: $, $$, или $$$ категорию. Один из них заявил, что не знает, что означают эти символы, а другой выбрал неверную категорию. Остальные трое пользователей верно выбрали $$ категорию.

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

Сбор количественных данных о поведении пользователя

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

1. Сортировка закрытыми картами с помощью инструмента OptimalSort.

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

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

Применяемая в описываемом тесте сортировка картами имела три простые цели:

  • Определить, как часто люди используют поисковые фильтры на сайте Yelp
  • Определить, какие фильтры являются наиболее важными
  • Определить, какие фильтры являются наименее важными

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

2. Тестирование первого клика с помощью инструмента Chalkmark

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

  1. Пропишите четко задачи. Убедитесь, что участник думает о том, как решить проблему, а не просто о том, где кликнуть.
  2. Определите лучшие пути для выполнения задачи. Начиная с домашней страницы, постройте все возможные пути для достижения каждой цели.
  3. Отведите определенное время на выполнение задач.

Данное тестирование должно было:

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

Специалисты попросили пользователей выполнить определенные задачи, снабдив их скриншотами страниц Yelp. Затем они проанализировали результаты (heatmap) и скорость выполнения этих задач участниками.

Количественный анализ пользовательского исследования

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

1. Результаты тестирования фильтров поиска на сайте Yelp с помощью сортировки закрытыми картами

92,5% участников сказали, что регулярно используют фильтры поиска на этом сайте.

Наиболее важными фильтрами для пользователей оказались «Отрыто сейчас», «Принимают кредитные карты» и «Специальные предложения».

Более 88% участников решили, что 7 фильтров вовсе не важны.

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

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

Результаты тестирования первого клика на домашней странице Yelp

2. 30% участников посчитали сайт «перенасыщенным» или «сбивающим с толку».

Тепловая карта продемонстрировала значительные различия того, где именно кликали пользователи. Участников попросили найти ресторан с умеренными ценами, который мог бы вместить компанию до 20 человек. Выполнение задания заняло в среднем 15 секунд — что в условиях интернета много. На изображении ниже вы видите, что 55% кликнули по пункту меню «Рестораны» в верхнем правом углу. Остальные 45% кликнули в совершенно разных местах. Наличие потенциальных ответов в нескольких местах на странице увеличивает когнитивную нагрузку пользователей и вероятность неверного первого клика:

24% участников использовали панель поиска, когда искали механика из их города (одно из заданий). Большинство участников перешли к категориям услуг, расположенных в левой части сайта. Но вторым по популярности действием все же стало использование панели поиска.

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

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

На основе полученных количественных данных были определены следующие задачи для редизайна:

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

Дизайн, ориентированный на пользователя, и Итерация

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

Якоб Нильсен (Jakob Nielsen), соучредитель Nielsen Norman Group, классифицирует большинство процессов проектирования, включающих юзабилити-тестирование, по двум категориям: итерационное проектирование (iterative design) и параллельное проектирование (parallel design).

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

1 схематично изображенный каркас, несколько итераций → бумажный / интерактивный каркас, несколько итераций → визуальные дизайны, несколько итераций

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

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

3 разных одновременно сделанных дизайна → Пользовательское тестирование (соединяются лучшие идеи дизайна) → 1 дизайн → Итерационый процесс проектирования

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

Описанный процесс редизайна Yelp был по существу параллельным процессом совместно с UX-тестированием, проведенного в самом начале. Так как это был лишь гипотетический редизайн, разработчики остановились после шага «1 дизайн». Если бы это был настоящий редизайн, следующим шагом стало бы проведение дальнейшего тестирования для улучшения прототипа.

Составление эскиза

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

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

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

  • Повышение видимости панели поиска
  • Сделать вкладку «События» более заметной
  • Оптимизировать категории

Кроме того, был добавлен футер и «Отзыв дня» перемещен с правой части страницы в низ.

2. Страница результатов поиска Yelp

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

В этом эскизе были учтены следующие моменты:

  • Фотографии должны быть более заметными
  • Обозначить категории цен

Создание каркаса

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

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

  • Улучшение панели поиска

Текущий дизайн:

Панель поиска находится в верхней части страницы.

Измененный каркас:

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

  • Оптимизировать перечень категорий

Текущий дизайн:

Измененный каркас:

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

  • Облегчить нахождение вкладки «События»

Текущий дизайн:

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

Измененный каркас:

Измененный макет помещает «События» в центр прокрутки. Можно либо вставить функцию «Фото» слева от текста, либо добавить видео, проигрывающееся в фоновом режиме.

  • Уменьшение общего хаоса

Текущий дизайн:

Измененный каркас:

Любые вторичные элементы, такие как «Популярные события» или «Списки» (которые по результатам юзабилити-тестирования ни разу не были даже использованы) были перенесены в футер.

2. Страницы результатов поиска Yelp

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

Текущий дизайн:

Фильтры и сортировка Yelp испытывают недостаток иерархии.

Измененный каркас:

Новый каркас выделяет наиболее важные фильтры и перестраивает всю область на квадраты. Каждая категория фильтра включает в себя только четыре варианта, что дает визуальную упорядоченность.Так как 90% пользователей посчитали фильтр «Открыто сейчас» важным, разработчики выделили его как отдельный элемент. Цены прояснены диапазонами доллара, а 7 неважных фильтров скрыты.

  • Улучшение макета результатов поиска

Текущий дизайн:

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

Измененный каркас:

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

Прототипирование: низкая и высокая точность

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

1. Прототипирование с низкой точностью

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

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

2. Прототипирование с высокой точностью

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

Специалисты добавили точности, задействовав свою библиотеку элементов пользовательского интерфейса. Что нельзя было сделать в браузере, было создано в Photoshop или Sketch, а затем импортировано непосредственно в UXPin с помощью функции drag & drop. Слои были сохранены, так что надо было только нажимать на элементы и добавлять взаимодействия.

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

Заключение

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

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

К слову, дизайн сайта Yelp, описанный в данной статье, все же претерпел некоторые изменения и теперь выглядит так:

Не исключено, что его разработчики использовали перечисленные выше принципы, чтобы добиться результата, отчасти напоминающего тот, к которому пришли специалисты из UXPin, UserTesting и Optimal Workshop





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

Классический метод юзабилити-тестирования первый: наблюдение за некоторым количеством респондентов (от 10 до 100, в зависимости от задачи) и оценка сервиса по некоторым критериям. Каким — расскажем далее.

Метрики юзабилити-тестирования

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

1. Эффективность выполнения заданий

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

  • выполнил без проблем — 100%;
  • столкнулся с проблемами при выполнении — 50%;
  • не сделал вообще — 0%.

После тестирования всей группы высчитывается среднее значение.

2. Количество ошибок

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

3. Удобство ориентирования на сайте

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

ориентирование на сайте

4. Удовлетворенность сервисом

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

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

Использование результатов теста

Классическое юзабилити-тестирование предполагает получение метрик как иллюстрацию общего состояния ресурса. Мнение, опыт и восприятие каждого респондента субъективно, поэтому мы можем делать только общие выводы.

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

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

результаты теста

3 совета по улучшению юзабилити сайта

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

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

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

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

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

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

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

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

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

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

1. Физический способ тестирования (лицом к лицу)

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

2. Виртуальный способ тестирования (через общий доступ к экрану)

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

Итак, теперь вы знаете, какие категории тестирования вы можете проводить, и как оценивать пользователей лично или удаленно. Вы, вероятно, спрашиваете: «Как мне все это сделать подешевле?» Я так рад, что вы спросили

Оптимальные по цене и качеству сервисы для тестирования

Существует множество способов быстрой оценки юзабилити сайта. Вы можете попробовать эти: 5-Second Usability Tests , Click Tests , Open Ended Question Tests, Navigation Tests , Preference Tests , Survey Monkey , Hallway Tests (попробуйте лично или через презентацию в Skype, Google Hangouts)

Примечание автора: Отечественные сервисы для проведения юзабилити-тестирования: https://uxcrowd.ru , http://sitepolice.ru/ , https://www.userpoint.ru/ , Вебвизор

5 примеров сбора обратной связи

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

1. Может ли пользователь легко объяснить, что вы продаете?

2. Какую информация или функции ожидают пользователи найти на вашем сайте (или не ожидают)

3. Нашел пользователь что-то полезное для себя?

4. Что удобно, что неудобно? Где сайт может работать лучше?

5. Что жизненно необходимо добавить на вашем сайте?

1. Определите цели исследования.

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

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

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

4. Задавайте открытые вопросы.
 Разговорите респондентов.

5. Используйте сегментацию.
Сегментируйте своих пользователей в зависимости от их показателей LTV (пожизненная ценность клиента).

6. Спланируйте действия, которые ваши респонденты должны выполнить
. Они должны основываться на первичных, вторичных и третичных функциях вашего продукта.

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

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

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

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

Если вы используете эти советы, то влюбитесь в тестирование так же как и мы

Анализ результатов

Хорошо, у вас есть куча цифр — что теперь?

Есть два способа превратить ваши количественные результаты в идеи:

1. Числовой: собирать данные в числовом формате, смотреть на цифры и искать зависимости.

2. Субъективный: спросить у самих пользователей нравиться или не нравиться им продукт

Для субъективного метода анализа вам понадобится числовая шкала. Напишете все важные технические характеристики и попросите пользователя оценить их удобство по шкале от 1 до 5.

Используйте цифровую шкалу, которая работает более 30 лет. Шкала называется SUS (от англ. System Usability Scale — шкала юзабилити системы). Это шкала Ликерта, которая была изобретена Джоном Бруком еще в 1986 году.Чаще всего это десять вопросов, по которым пользователи оценивают свою удовлетворенность продуктом.

Числовой метод поможет вам гораздо быстрее найти зависимости, чем пересмотр каждой анкеты пользователя. Покажем на примере сервиса Unbounce как использовать SUS Brooke.

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

Мы постоянно тестируем A / B на наших целевых страницах в Unbounce. Вот результат теста, который мы провели в Unbounce на странице с примерами наших работ. Наша команда дизайнеров предположила, что посетители могут лучше конвертироваться, если внесем следующие правки: подчеркнем призыв к действию, настроим обратную связь, сделаем форму более интерактивной. Эти изменения улучшили коэффициент конверсии на 61%. Это круто!

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

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

Что важно

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

  • С чего начинать?
  • Какие этапы нужно пройти?
  • Как не упускать важные детали?
  • Какие ловушки придется преодолеть?
  • Как получать валидные и значимые данные?

В планировании поможет следующий алгоритм.

Этап 1: Определите цель

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

Тест может включать общие вопросы:

  • Какая навигация улучшает пользовательский опыт?
  • Как посетители взаимодействуют с приложением / сайтом?

Или специфичные:

  • Что мешает пользователям совершать целевое действие на сайте?
  • Что при оформлении заказа привлекает внимание?

Однако чем больше вопросов в программе исследования, тем шире поле для ошибок в интерпретации. Спрашивайте только то, что помогает в достижении цели.

Этап 2: Привлекайте правильных участников

Это посетители сайта и целевые пользователи.

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

Определите число участников. Обычно от 3 до 8. Чем их больше, тем больше ошибок юзабилити можно выявить. Так выглядит эта зависимость:

Этап 3: Выберите формат

Персональное юзабилити-тестирование

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

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

Удаленное юзабилити-тестирование

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

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

Этап 4: Сформулируйте задачи / сценарии

Вот два вида задач:

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

Важно найти золотую середину. Как это сделать?

Требования к задачам

  • Задача ≠ вопрос

Почему? Нет никакой пользы от вопросов с предсказуемыми или «от балды» ответами.

  • Конкретные формулировки

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

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

  • Избегайте инструкций

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

  • Создайте условия, близкие к реальным

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

Этап 5: Составьте вопросники

Есть два основных типа вопросников для юзабилити-тестов.

Предварительные вопросники

Как часто вы покупаете онлайн?

  • Никогда;
  • Покупал(а) 1-2 раза в прошлом году;
  • Примерно 3-7 раз в год;
  • Регулярно (укажите, как часто).

Вы оцениваете, как эффективнее вовлечь целевую аудиторию и от чего это зависит.

Послетестовые вопросники

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

Как вам приложение?

  • Легко использовать;
  • Сложно использовать.

Пожалуйста, объясните, почему вы так считаете? (открытый вопрос).

Этап 6: Проведите пробный запуск

«Репетиция» исследования помогает оценить готовность, выявить и устранить проблемы на раннем этапе.

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

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

Если пилотный запуск успешный, он также дает полезные, а порой неожиданные открытия.

Важно! Привлекайте пользователей, которые не знакомы со всеми нюансами системы, которую вы тестируете.

Этап 7: Фиксируйте результаты

Универсального метода анализа данных нет. Выберите то, что работает для вас.

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

Кейс: юзабилити-тест в действии

Цель: ответить на вопросы и изменить нужные разделы сайта:

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

Дизайн продукта, сайта или приложения — весьма длительный процесс, требующий терпения, проницательности и наличия ряда инструментов. Чтобы понять, что в действительности работает, а что нет, важно знать мнение пользователей. Здесь-то и приходит на помощь пользовательское тестирование (user testing).

Объединив усилия, UXPin, UserTesting и Optimal Workshop решили описать UX-процесс, которому они следовали для гипотетического Yelp:

Весь процесс скорее напоминал дизайн-спринт, состоящий из 1-3 недельных проектов, сфокусированных на решении конкретных задач.

Краткий обзор процесса UX-дизайна

1. Определение продукта

На начальном этапе специалисты определили ценностное предложение (value proposition), незаслуженное преимущество (unfair advantage) и общую бизнес-модель. Поскольку Yelp уже добился значительного успеха в привлечении посетителей, они решили, что было бы интересно понять, как можно повысить частоту использования (frequency of use). Далее был разработан общий план тестирования.

2. Тестирование и анализ

На этапе исследования команда рассмотрела в деталях план тестирования и перешла к немодерируемым сессиям. Была определена демография пользователей и детализированы конкретные задачи. В ходе работы использовались различные методы тестирования, начиная от анализа записей взаимодействий пользователей с сайтом, удаленной карточной сортировки (card sorting) и тестирования первого клика (first-click testing).

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

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

  • Переработка текста.
     В целях извлечения максимальной пользы специалисты несколько раз корректировали инструкции, чтобы язык был как можно более лаконичным и побуждал к конкретным действиям. Это непременное условие для удаленных немодерируемых тестирований, поскольку письменные инструкции являются единственными директивами для участников.
  • Проведение (pilot test).
     Как только инструкции были готовы, было проведено немодерируемое удаленное тестирование с одним пользователем из группы тестирования. Он также оставил отзыв касательно самих инструкций, чтобы команда могла исправить мелкие недочеты и обеспечить полную ясность.
  • Обеспечение задач релевантными вопросами.
     По каждому заданию участник тестирования должен был ответить на вопрос «Была ли выполнена задача?», а также «Оцените уровень ее легкости/сложности». Ответ на первый вопрос давал понять, осуществима ли задача; в то время как второй — позволял углубиться в возможные улучшения дизайна.
  • Избегание наводящих вопросов.
     При тестировании использовался такой, к примеру, вопрос, как «Насколько легко или трудно было вам выполнить эту задачу?» вместо «Насколько трудно было выполнить эту задачу?», что предотвращает вероятность необъективного ответа.

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

3. Дизайн и итерация

Глен Липка (Glen Lipka), вице-президент User Experience, считает, что последовательный (UI, user interface) лучше, чем совершенный пользовательский интерфейс. Последовательность порождает узнаваемость, которая в свою очередь способствует более частому обращению. Ниже приводятся несколько руководящих принципов:

  • Дизайн для информации.
     Люди используют веб-сайты не для того, чтобы восхищаться красивыми дизайнами, но потому что им нужен контент. В описываемом случае, учитывая, что Yelp — это сайт для поиска на местном рынке услуг, редизайн нуждался в лучшей доставке нужной информации нужным людям, и тестирование информационной архитектуры при помощи карточной сортировки было неотъемлемой частью этого процесса.
  • Следование принципу MAYA (Most Advanced Yet Acceptable)
    , «наиболее передовой и в то же время воспринимаемый». В то время как команда хотела обеспечить лучший опыт для изредка заходящих на сайт Yelp пользователей, они не хотели создать нечто настолько чужеродное, что могло бы оттолкнуть опытных пользователей или запутать новых.
  • Изучение паттернов пользовательских интерфейсов.
     Были изучены существующие модели пользовательского интерфейса на других известных сайтах и найдено то, что можно было перенять у них.
  • Сделать сайт приятным и удобным для использования (usable).
     Опыт для изредка заходящих на сайт Yelp пользователей должен был быть более понятным. В то же время, специалисты хотели сохранить приятный внешний вид сайта.

Конечная цель состояла в достижении локального максимума (local maximum). Проект был завершен как только затраты превысили выгоды дополнительной итерации. С учетом ограниченности по времени дизайн-спринта, разработчики не зацикливались на получении глобального максимума (global maximum).

Понимание вашего бизнеса перед проведением тестирования

Прежде чем начать работу над UX, вы должны сперва понять свой бизнес. Какие проблемы он решает, каким образом приносит деньги? В чем он успешен, а в чем его можно улучшить?

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

Для первого шага специалисты выбрали , поскольку это легкая и вместе с тем всесторонняя визуализация бизнеса:

Не будем утомлять вас всей документацией, поэтому просто посмотрим на то, как вы можете сделать это в целях UX на примере Yelp:

  • Самая главная проблема: Люди в определенном городе хотят получить [лучший / быстрый / самый дешевый / самый простой] [продукт / услугу].
  • 3 самые основные функции: Отзывы пользователей, лента активности (activity stream), поиск по городу / категории.
  • Уникальное ценностное предложение: Возможность вносить компании в список, добавлять отзывы и видеть компании, рекомендованные друзьями и другими пользователями.
  • «Несправедливое преимущество» (то, что не может быть скопировано или куплено): Сетевые эффекты (network effects) наличия большой базы пользователей.

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

2. Определение объектов пользовательского тестирования

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

  • Какие функции используют люди при выборе ресторана? (например, фотографии, рейтинг и т.д.)
  • Могут ли пользователи выбрать ресторан на основе нескольких конкретных критериев?
  • Знают ли пользователи, как сохранять варианты?
  • Могут ли они узнать, открыто ли конкретное место в данный момент?

3. Выбор методов тестирования

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

Планирование и сбор качественных данных (qualitative data)

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

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

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

Такие критерии отбора как возраст, пол, уровень дохода или уровень владения интернетом были не важны. Поскольку это исследование проводилось исключительно с целью качественного анализа, специлаисты не нуждались в (statistical significance) для подтверждения полученных данных. Они последовали лучшим отраслевым практикам и провели свое исследование с участием 5 пользователей. И, наконец, для простоты дизайн-спринта они тестировали сайт Yelp только на стационарном компьютере.

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

Задания общего характера включали в себя:

  • Сфокусированное задание — найти компанию на основании конкретных параметров
  • Открытое задание — найти компанию при наличии очень малого количества директив
  • Очень конкретное задание — найти определенное место и узнать конкретную информацию о нем

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

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

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

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

Качественный анализ пользовательского исследования

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

1. Функция поиска была основной отправной точкой для любой задачи.

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

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

2. Вкладка «События» не была достаточно заметной.

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

Как ни странно, никто не воспользовался вкладкой «События». Один из участников теста обратился к панели поиска, а другой перешел в категорию «Искусство и Развлечения».

3. Функция закладок оказалось непонятной, а также никто не использовал списки.

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

Из трех участников:

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

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

4. Поиск конкретного места оказалось очень быстрым и легким заданием.

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

5. Пользователи руководствовались фотографиями для определения атмосферы ресторана.

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

6. Фильтры использовались участниками, но могут быть улучшены.

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

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

Когда участники искали ресторан по определенным параметрам, одним из требований было найти ресторан в пределах $ 20/чел. Двое из пяти пользователей были сбиты с толку, в какую категорию следует отнести ресторан с таким бюджетом: $, $$, или $$$ категорию. Один из них заявил, что не знает, что означают эти символы, а другой выбрал неверную категорию. Остальные трое пользователей верно выбрали $$ категорию.

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

Сбор количественных данных о поведении пользователя

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

1. Сортировка закрытыми картами с помощью инструмента OptimalSort.

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

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

Применяемая в описываемом тесте сортировка картами имела три простые цели:

  • Определить, как часто люди используют поисковые фильтры на сайте Yelp
  • Определить, какие фильтры являются наиболее важными
  • Определить, какие фильтры являются наименее важными

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

2. Тестирование первого клика с помощью инструмента Chalkmark

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

  1. Пропишите четко задачи. Убедитесь, что участник думает о том, как решить проблему, а не просто о том, где кликнуть.
  2. Определите лучшие пути для выполнения задачи. Начиная с домашней страницы, постройте все возможные пути для достижения каждой цели.
  3. Отведите определенное время на выполнение задач.

Данное тестирование должно было:

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

Специалисты попросили пользователей выполнить определенные задачи, снабдив их скриншотами страниц Yelp. Затем они проанализировали результаты (heatmap) и скорость выполнения этих задач участниками.

Количественный анализ пользовательского исследования

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

1. Результаты тестирования фильтров поиска на сайте Yelp с помощью сортировки закрытыми картами

92,5% участников сказали, что регулярно используют фильтры поиска на этом сайте.

Наиболее важными фильтрами для пользователей оказались «Отрыто сейчас», «Принимают кредитные карты» и «Специальные предложения».

Более 88% участников решили, что 7 фильтров вовсе не важны.

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

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

Результаты тестирования первого клика на домашней странице Yelp

2. 30% участников посчитали сайт «перенасыщенным» или «сбивающим с толку».

Тепловая карта продемонстрировала значительные различия того, где именно кликали пользователи. Участников попросили найти ресторан с умеренными ценами, который мог бы вместить компанию до 20 человек. Выполнение задания заняло в среднем 15 секунд — что в условиях интернета много. На изображении ниже вы видите, что 55% кликнули по пункту меню «Рестораны» в верхнем правом углу. Остальные 45% кликнули в совершенно разных местах. Наличие потенциальных ответов в нескольких местах на странице увеличивает когнитивную нагрузку пользователей и вероятность неверного первого клика:

24% участников использовали панель поиска, когда искали механика из их города (одно из заданий). Большинство участников перешли к категориям услуг, расположенных в левой части сайта. Но вторым по популярности действием все же стало использование панели поиска.

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

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

На основе полученных количественных данных были определены следующие задачи для редизайна:

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

Дизайн, ориентированный на пользователя, и Итерация

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

Якоб Нильсен (Jakob Nielsen), соучредитель Nielsen Norman Group, классифицирует большинство процессов проектирования, включающих юзабилити-тестирование, по двум категориям: итерационное проектирование (iterative design) и параллельное проектирование (parallel design).

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

1 схематично изображенный каркас, несколько итераций → бумажный / интерактивный каркас, несколько итераций → визуальные дизайны, несколько итераций

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

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

3 разных одновременно сделанных дизайна → Пользовательское тестирование (соединяются лучшие идеи дизайна) → 1 дизайн → Итерационый процесс проектирования

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

Описанный процесс редизайна Yelp был по существу параллельным процессом совместно с UX-тестированием, проведенного в самом начале. Так как это был лишь гипотетический редизайн, разработчики остановились после шага «1 дизайн». Если бы это был настоящий редизайн, следующим шагом стало бы проведение дальнейшего тестирования для улучшения прототипа.

Составление эскиза

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

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

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

  • Повышение видимости панели поиска
  • Сделать вкладку «События» более заметной
  • Оптимизировать категории

Кроме того, был добавлен футер и «Отзыв дня» перемещен с правой части страницы в низ.

2. Страница результатов поиска Yelp

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

В этом эскизе были учтены следующие моменты:

  • Фотографии должны быть более заметными
  • Обозначить категории цен

Создание каркаса

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

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

  • Улучшение панели поиска

Текущий дизайн:

Панель поиска находится в верхней части страницы.

Измененный каркас:

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

  • Оптимизировать перечень категорий

Текущий дизайн:

Измененный каркас:

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

  • Облегчить нахождение вкладки «События»

Текущий дизайн:

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

Измененный каркас:

Измененный макет помещает «События» в центр прокрутки. Можно либо вставить функцию «Фото» слева от текста, либо добавить видео, проигрывающееся в фоновом режиме.

  • Уменьшение общего хаоса

Текущий дизайн:

Измененный каркас:

Любые вторичные элементы, такие как «Популярные события» или «Списки» (которые по результатам юзабилити-тестирования ни разу не были даже использованы) были перенесены в футер.

2. Страницы результатов поиска Yelp

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

Текущий дизайн:

Фильтры и сортировка Yelp испытывают недостаток иерархии.

Измененный каркас:

Новый каркас выделяет наиболее важные фильтры и перестраивает всю область на квадраты. Каждая категория фильтра включает в себя только четыре варианта, что дает визуальную упорядоченность.Так как 90% пользователей посчитали фильтр «Открыто сейчас» важным, разработчики выделили его как отдельный элемент. Цены прояснены диапазонами доллара, а 7 неважных фильтров скрыты.

  • Улучшение макета результатов поиска

Текущий дизайн:

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

Измененный каркас:

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

Прототипирование: низкая и высокая точность

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

1. Прототипирование с низкой точностью

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

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

2. Прототипирование с высокой точностью

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

Специалисты добавили точности, задействовав свою библиотеку элементов пользовательского интерфейса. Что нельзя было сделать в браузере, было создано в Photoshop или Sketch, а затем импортировано непосредственно в UXPin с помощью функции drag & drop. Слои были сохранены, так что надо было только нажимать на элементы и добавлять взаимодействия.

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

Заключение

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

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

К слову, дизайн сайта Yelp, описанный в данной статье, все же претерпел некоторые изменения и теперь выглядит так:

Не исключено, что его разработчики использовали перечисленные выше принципы, чтобы добиться результата, отчасти напоминающего тот, к которому пришли специалисты из UXPin, UserTesting и Optimal Workshop





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

Каких результатов можно добиться при помощи юзабилити-тестирования сайта?

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

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

Разновидности тестирования юзабилити

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

Качественное тестирование.

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

Количественное тестирование.

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

Количественное тестирование.

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

Сравнительное тестирование.

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

Кросс-культурное тестирование.

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

Кросс-культурное тестирование.

Цель — адаптировать зарубежный продукт для российского покупателя или наоборот.

Пользовательское тестирование

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

Айтрекинг-тестирование

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

Тестирование методом персонажей

Цель — понять поведение на сайте типичных представителей различных групп ЦА и на основе полученных знаний об их предпочтениях удовлетворить наиболее широкую группу пользователей.

Экспертный анализ

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

A/B-тестирование

Цель — предложить пользователям несколько вариантов дизайна и сравнить реакцию. Выделяются последовательные и параллельные A/B-тесты. При последовательном тестировании usability правки сразу вносятся на сайт и замеряются периоды до и после изменений. При параллельном делается несколько версий, которые сравниваются с основной.

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

  • оценку удобства использования;
  • сравнение с сайтами-конкурентами.

Подготовка к юзабилити-тестированию и получение отчета

Подготовка состоит из 4 основных этапов:

    Формирование гипотез.

Определение метрик для тестирования.

Проводится для нахождения проблемных мест на сайте или в продукте. Главной его целью является последующее внесение правок в сайт и выдвижение новых гипотез для A/B – тестирований.

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

6 шагов юзабилити-тестирования

Шаг 1. Определите ключевые цели исследования

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

Плохой пример:

  • Цель исследования – выявить все проблемы сайта.

Хороший пример:

  • Цель исследования – узнать, насколько легко пользователю найти нужный товар и оформить заказ.

Шаг 2. Подберите целевую аудиторию

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

Где искать тестировщиков?

Если у вас b2c-компания и вы продаете товары или услуги для широкой аудитории (обувь, товары для дома и т.д.), рекомендуем использовать наш интернет-сервис юзабилити-тестирования Userpoint
.
ru
, где есть большая база тестировщиков, среди которых можно подобрать свою целевую аудиторию по возрасту, полу и любым другим параметрам:

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

Сколько пользователей нужно привлечь для тестирования?

В научных кругах – это старая тема для споров. По данным исследований Якоба Нильсена и Томаса Ландауэра 5 пользователей находят 85% проблем в юзабилити, 15 пользователей – находят 100% проблем. На рисунке математическая модель нахождения юзабилити-проблем, представленная Нильсеном.

Более поздние и основательные исследования показывают необходимость привлечения большего числа участников. Доктор Гитте Линдгаарт из Карлтонского университета доказала большую зависимость процента найденных проблем от качества составленных задач для тестирования, нежели от выборки. Группы из 5-6 пользователей в ее исследованиях находят 30-50% проблем в юзабилити при разных подходах к формулированию задач. Ознакомиться с хронологией исследований и споров можно по ссылке – История магического числа 5 в юзабилити-тестировании .

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

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

Шаг 3. Создайте сценарий и задачи

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

Как мы уже говорили, не стоит исследовать все сразу за одно тестирование. Идеальный вариант – проводить для каждой цели свое исследование, создавая для него определенный сценарий с набором задач. Помните, что для качественного тестирования 15-20 минут – оптимальное время выполнения одного сценария пользователем. Также мы не рекомендуем делать более 4-5 задач в одном сценарии.

Используйте разные типы задач в сценариях

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

Примеры широких задач:

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

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

Примеры конкретных задач:

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

Не делайте сложные составные задачи

Плохой пример:

  • Добавьте товар в корзину. Теперь выберите еще один товар и добавьте его тоже. Затем увеличьте количество первого товара в корзине. Теперь оформите заказ и выберите доставку.

Лучше сделайте 4 разные задачи:

  • Добавить товар в корзину.
  • Найти другой товар и добавить в корзину.
  • Увеличить количество первого товара в корзине.
  • Оформить заказ с доставкой.

Ставьте задачи для сравнения с конкурентами

Конечно, цена и условия доставки – важнейшие факторы выбора магазина. Но вы уверены, что клиент купил товар у конкурента, потому что у него он стоит на 1% дешевле? Может быть, ваш сайт просто внушает меньше доверия? А может быть не хватает онлайн-чата? Или дело в условиях доставки? Если есть подозрение, что причина именно в условиях доставки, можно сделать задачу «сравнить условия доставки и оплаты с конкурентом Х» или даже «с конкурентами из топ-3 выдачи Яндекса». Может быть очень много причин для выбора компании, и юзабилити-тестирование – отличная возможность узнать, почему клиенты предпочитают покупать товары на сайтах ваших конкурентов.

Ставьте правильные вопросы к задачам

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

Пример задачи:

  • Подберите подарок для друга в ценовом диапазоне от 5 до 10 тыс. рублей на сайтах xxx.ru и yyy.ru.

Пример вопроса:

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

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

Шаг 4. Протестируйте свой тест

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

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

Можно поступить следующим образом:

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

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

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

Шаг 5. Проведите тест

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

Если же вы решили проводить традиционное тестирование, рекомендуем ознакомиться с материалами одних из первопроходцев традиционного тестирования Nielsen Norman Group.

Шаг 6. Анализируйте результаты и выдвигайте гипотезы для
A
/
B
 — тестирований

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

Зафиксируйте все проблемы

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

Плохие примеры:

  • Путался в навигации.
  • Нажал на неправильную ссылку.

Хороший пример:

  • На этапе покупки нажал на ссылку «Вход», вместо ссылки «Оформить заказ».

Отмечайте степень важности проблем.

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

Формулируйте выводы, вносите правки, выдвигайте гипотезы для следующих
A
/
B
-тестирований

Каждый вывод должен основываться на полученных данных и содержать в себе рекомендации о том, что нужно делать дальше. Если проблема критическая, необходимо сразу вносить правки в сайт или продукт. На основе большинства проблем потребуется выдвигать гипотезы для запуска A/B – тестирований.

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

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

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

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

Какими знаниями мы будем делиться?

  • обзоры инструментов аналитики и A/B – тестирования,
  • опыт и кейсы российских и зарубежных компаний по повышению конверсии,
  • приемы улучшения юзабилити и секреты пользовательских интерфейсов,
  • UX-исследования, инсайты и аналитика,
  • интервью и вебинары с экспертами рынка.

Ну а теперь ближе к теме.

Что такое юзабилити-тестирование и в чем его польза?

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

Для крупного, среднего бизнеса, интернет-сервисов это важный этап профессионального юзабилити-анализа. Используя юзабилити-тестирование вместе со стандартными методами и инструментами (системами аналитики, Вебвизором, эвристическим анализом и т.д.), вы сможете выдвигать правильные гипотезы для A/B-тестов, вносить правки в сайт и добиваться устойчивого повышения конверсии.

2. Онлайн-тестирование

Развитие интернета способствовало развитию дистанционного онлайн-тестирования
, которое, как правило, гораздо дешевле и быстрее. Это исследование без взаимодействия с тестировщиком в реальном времени. Если вы правильно напишете сценарий, этот метод значительно сэкономит ваши ресурсы. Конечно, можно найти удаленную фокус-группу, составить список вопросов, отослать по электронной почте и попросить людей самостоятельно протестировать сайт или продукт, проходя через сценарий и комментируя свои мысли и действия вслух. Но гораздо проще воспользоваться сервисами автоматизации. Флагманом зарубежного рынка является usertesting.com , на российском рынке мы предлагаем его аналог – . Огромные базы реальных тестировщиков позволяют мгновенно подобрать по любым параметрам фокус-группу (например, десять женщин от 30 до 35 лет, у которых есть кот) и в течение пары дней провести тестирование.

Преимущества онлайн-тестирования с помощью специализированных сервисов очевидны:

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

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

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

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

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

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

Уровни проведения

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

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

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

Для повышения юзабилити существующих приложений можно использовать цикл Демминга Plan-Do-Check-Act , собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

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

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

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

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

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

) есть этап оценки дизайна, именно в нем может проводится качественное юзабилити-тестирование.

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

Когда стоит проводить юзабилити-тестирование и что ему предшествует?

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

Следующим шагом должно быть определение KPI (Wikipedia: Key Performance Indicators — ключевые показатели эффективности). Необходимо проанализировать, что важно для бизнеса, определить цели, которые должны быть достигнуты сайтам.

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

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

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

Подготовка к юзабилити-тестированию

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

Следующим шагом должно быть определение KPI (Wikipedia: Key Performance Indicators — ключевые показатели эффективности). Необходимо проанализировать, что важно для бизнеса, определить цели, которые должны быть достигнуты сайтам.

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

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

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

Подготовка к юзабилити-тестированию

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

Четвертым шагом должно стать формирование гипотез по поводу того, что не так со страницей, и исходя из этого, необходимо определить метрики (Wikipedia: ISO 9126 — Оценка программного продукта), по которым будут тестироваться функции (есть метод экспертной оценки, при котором эксперт выдвигает гипотезы по улучшению интерфейса сайта и, исходя из них, происходит перепроектирование сайта, однако проверить, действительно ли эта гипотеза верна, можно только по итогу внедрения изменений, что влечет за собой большую цену ошибки).

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

После определения метрик, по которым будем тестировать проблемные зоны на сайте, необходимо определить персонаж и сценарий работы (книга: Алан Купер об интерфейсе. Основы проектирования взаимодействия), по которому будет проводиться юзабилити-тестирование. Данный шаг необходим для привлечения нужных респондентов и выбора задания для юзабилити-тестирования. Если упустить этот момент, то респондент, который не является целевым пользователем, может с успехом пройти проблемную зону, а у пользователя, который действительно использует данную страницу, возникнут действительно большие проблемы. Итогом будет перепроектирование интерфейса без учета данных, а проблема останется. Точное определение сценария поможет дать респонденту правильное задание. То есть, если задание будет купить мобильный телефон, а респондент и вовсе не будет регистрироваться (а мы тестируем именно регистрацию), то юзабилити-тестирование бесполезно.

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

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

Непосредственно перед самим юзабилити-тестированием дайте респонденту заполнить анкету, чтобы проверить на соответствие необходимых характеристик у выделенного персонажа и респондента. Проведите вводный инструктаж, в ходе которого опишите контекст использования сайта и задание (книги: Веб-дизайн: книга Стива Круга, или «не заставляйте меня думать!»).

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

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

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

Обработка данных юзабилити-тестирования

Непосредственно перед самим юзабилити-тестированием дайте респонденту заполнить анкету, чтобы проверить на соответствие необходимых характеристик у выделенного персонажа и респондента. Проведите вводный инструктаж, в ходе которого опишите контекст использования сайта и задание (книги: Веб-дизайн: книга Стива Круга, или «не заставляйте меня думать!»).

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

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

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

Обработка данных юзабилити-тестирования

Далее необходимо просмотреть собранные видео материалы, проанализировать результаты юзабилит-тестирования и определить требования к интерфейсу для перепроектирования (книга: Web-дизайн. Удобство использования Web-сайтов). Изменения, которые будут внесены, исходя из определенных требований, стоит проверить при следующем юзабилити-тестировании. Количество таких итераций во многом должно зависеть от целей и бюджета, выделенного на перепроектирование сайта.

Примеры: добавить подсказки в форму регистрации, выделить кнопку покупки, добавить поле “платформа” в форму подбора телефона по параметрам и т.д.

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

  1. Формирование гипотез
  2. Определение метрик для тестирования
  3. Определение персонажей и сценариев
  4. Подбор респондентов
  5. Заполнение анкеты
  6. Вводный инструктаж
  7. Проведение юзабилити-тестирования
  8. Опрос респондентов
  9. Анализ результатов
  10. Определение требований для проектирования сайта

Основной проблемой, с которой я столкнулся при юзабилити-тестировании в данном случае, это тестирование статического дизайна, а не полноценного сайта. В действительности лучше протестировать сверстанный и даже запрограммированный сайт, однако цена итерации в дизайн будет уже высока. Чем раньше найдена проблема в интерфейсе, тем меньше затрат на ее устранение. Как провести полноценное юзабилити-тестирование статической картинки? Решением данной проблемы явилась программа Axure. Самым дешевым и удачным способом было искусственно расставить ссылки на статической картинке дизайна сайта и сгенерировать его в HTML страницы. Данный способ дает возможность протестировать сайт, не затрачивая ресурсов даже на верстку. Конечно, в сгенерированных страницах почти нет функционала, он отображается только в определенном виде, однако для определения большего количества проблем этого достаточно.

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

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









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

Каких результатов можно добиться при помощи юзабилити-тестирования сайта?

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

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

Разновидности тестирования юзабилити

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

Качественное тестирование.

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

Количественное тестирование.

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

Количественное тестирование.

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

Сравнительное тестирование.

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

Кросс-культурное тестирование.

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

Кросс-культурное тестирование.

Цель — адаптировать зарубежный продукт для российского покупателя или наоборот.

Пользовательское тестирование

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

Айтрекинг-тестирование

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

Тестирование методом персонажей

Цель — понять поведение на сайте типичных представителей различных групп ЦА и на основе полученных знаний об их предпочтениях удовлетворить наиболее широкую группу пользователей.

Экспертный анализ

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

A/B-тестирование

Цель — предложить пользователям несколько вариантов дизайна и сравнить реакцию. Выделяются последовательные и параллельные A/B-тесты. При последовательном тестировании usability правки сразу вносятся на сайт и замеряются периоды до и после изменений. При параллельном делается несколько версий, которые сравниваются с основной.

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

  • оценку удобства использования;
  • сравнение с сайтами-конкурентами.

Подготовка к юзабилити-тестированию и получение отчета

Подготовка состоит из 4 основных этапов:

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

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

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

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

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

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

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

Как создать сценарий для респондентов?

Чтобы создать сценарий пользователя, важно понять 3 вещи:

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

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

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

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

Вот в качестве примера два варианта задания:

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

    Забронируйте номер в отеле Италии.

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

Примеры наших кейсов по юзабилити-тестированию

Проведение юзабилити-тестирования сайта

Процедура состоит из двух этапов.

    Юзабилити-тест.
    Для него нужен компьютер с веб-камерой и программа Eye Tracking для записи движения глаз пользователей. Программа учитывает все действия, которые происходят на экране: перемещение курсора, использование клавиатуры, переходы между вкладками. Важно записать тайм-коды заданий, чтобы быстрее ориентироваться в длинном видео.

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

Анализ результатов тестирования юзабилити

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

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

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

Примерное описание удобного ресурса

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

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

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

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

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

    Ресурс понятен и для новичков, и для опытных пользователей.

    Сообщение об ошибке пишется понятным языком, и посетитель понимает, как решить проблему, если она возникла.

    Информацию на сайте легко найти, и она соответствует запросам аудитории.

Проводится для нахождения проблемных мест на сайте или в продукте. Главной его целью является последующее внесение правок в сайт и выдвижение новых гипотез для A/B – тестирований.

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

6 шагов юзабилити-тестирования

Шаг 1. Определите ключевые цели исследования

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

Плохой пример:

  • Цель исследования – выявить все проблемы сайта.

Хороший пример:

  • Цель исследования – узнать, насколько легко пользователю найти нужный товар и оформить заказ.

Шаг 2. Подберите целевую аудиторию

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

Где искать тестировщиков?

Если у вас b2c-компания и вы продаете товары или услуги для широкой аудитории (обувь, товары для дома и т.д.), рекомендуем использовать наш интернет-сервис юзабилити-тестирования Userpoint
.
ru
, где есть большая база тестировщиков, среди которых можно подобрать свою целевую аудиторию по возрасту, полу и любым другим параметрам:

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

Сколько пользователей нужно привлечь для тестирования?

В научных кругах – это старая тема для споров. По данным исследований Якоба Нильсена и Томаса Ландауэра 5 пользователей находят 85% проблем в юзабилити, 15 пользователей – находят 100% проблем. На рисунке математическая модель нахождения юзабилити-проблем, представленная Нильсеном.

Более поздние и основательные исследования показывают необходимость привлечения большего числа участников. Доктор Гитте Линдгаарт из Карлтонского университета доказала большую зависимость процента найденных проблем от качества составленных задач для тестирования, нежели от выборки. Группы из 5-6 пользователей в ее исследованиях находят 30-50% проблем в юзабилити при разных подходах к формулированию задач. Ознакомиться с хронологией исследований и споров можно по ссылке – История магического числа 5 в юзабилити-тестировании .

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

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

Шаг 3. Создайте сценарий и задачи

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

Как мы уже говорили, не стоит исследовать все сразу за одно тестирование. Идеальный вариант – проводить для каждой цели свое исследование, создавая для него определенный сценарий с набором задач. Помните, что для качественного тестирования 15-20 минут – оптимальное время выполнения одного сценария пользователем. Также мы не рекомендуем делать более 4-5 задач в одном сценарии.

Используйте разные типы задач в сценариях

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

Примеры широких задач:

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

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

Примеры конкретных задач:

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

Не делайте сложные составные задачи

Плохой пример:

  • Добавьте товар в корзину. Теперь выберите еще один товар и добавьте его тоже. Затем увеличьте количество первого товара в корзине. Теперь оформите заказ и выберите доставку.

Лучше сделайте 4 разные задачи:

  • Добавить товар в корзину.
  • Найти другой товар и добавить в корзину.
  • Увеличить количество первого товара в корзине.
  • Оформить заказ с доставкой.

Ставьте задачи для сравнения с конкурентами

Конечно, цена и условия доставки – важнейшие факторы выбора магазина. Но вы уверены, что клиент купил товар у конкурента, потому что у него он стоит на 1% дешевле? Может быть, ваш сайт просто внушает меньше доверия? А может быть не хватает онлайн-чата? Или дело в условиях доставки? Если есть подозрение, что причина именно в условиях доставки, можно сделать задачу «сравнить условия доставки и оплаты с конкурентом Х» или даже «с конкурентами из топ-3 выдачи Яндекса». Может быть очень много причин для выбора компании, и юзабилити-тестирование – отличная возможность узнать, почему клиенты предпочитают покупать товары на сайтах ваших конкурентов.

Ставьте правильные вопросы к задачам

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

Пример задачи:

  • Подберите подарок для друга в ценовом диапазоне от 5 до 10 тыс. рублей на сайтах xxx.ru и yyy.ru.

Пример вопроса:

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

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

Шаг 4. Протестируйте свой тест

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

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

Можно поступить следующим образом:

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

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

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

Шаг 5. Проведите тест

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

Если же вы решили проводить традиционное тестирование, рекомендуем ознакомиться с материалами одних из первопроходцев традиционного тестирования Nielsen Norman Group.

Шаг 6. Анализируйте результаты и выдвигайте гипотезы для
A
/
B
 — тестирований

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

Зафиксируйте все проблемы

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

Плохие примеры:

  • Путался в навигации.
  • Нажал на неправильную ссылку.

Хороший пример:

  • На этапе покупки нажал на ссылку «Вход», вместо ссылки «Оформить заказ».

Отмечайте степень важности проблем.

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

Формулируйте выводы, вносите правки, выдвигайте гипотезы для следующих
A
/
B
-тестирований

Каждый вывод должен основываться на полученных данных и содержать в себе рекомендации о том, что нужно делать дальше. Если проблема критическая, необходимо сразу вносить правки в сайт или продукт. На основе большинства проблем потребуется выдвигать гипотезы для запуска A/B – тестирований.

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

Интервью / фокус-группа

Массовый опрос

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

Полевое исследование

Карточная сортировка

Мультиканальное исследование

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

Артефакты

Бизнес-требования

Портреты пользователей

Требования пользователей

Спланировать проект

Методы и артефакты

  • Интервью / фокус-группа
  • Массовый опрос
  • Полевое исследование
  • Карточная сортировка
  • Мультиканальное исследование

Интервью / фокус-группа

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

Массовый опрос

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

Полевое исследование

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

Карточная сортировка

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

Мультиканальное исследование

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

Юзабилити- исследование Проектирование- интерфейсов Юзабилити- аудит

Артефакты

  • Бизнес требования
  • Портреты пользователей
  • Портреты деятельности
    пользователей
  • Требования пользователей

Бизнес требования

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

Портреты пользователей

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

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

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

Требования пользователей

Цели и задачи проектирования нового интерфейса с учетом потребностей пользователей и контекста использования продукта.

60 000 юзабилити-часов

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

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

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

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

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

Мы используем множество различных методов в зависимости от бизнес-задач клиентов. Одни клиенты приходят за «инсайтами», им требуется приток новых идей о том, где «хромает» юзабилити. Другие приходят со своими идеями и хотят их количественно проверить и приоритизировать согласно потребностям пользователей. Третьи нуждаются в построении эффективной каталожной системы. Методология Human Centered Design предлагает достаточный набор инструментов, которые можно комбинировать и найти ответы на важные для бизнеса вопросы о пользовательских качествах продукта.

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









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

Каких результатов можно добиться при помощи юзабилити-тестирования сайта?

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

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

Разновидности тестирования юзабилити

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

Качественное тестирование.

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

Количественное тестирование.

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

Количественное тестирование.

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

Сравнительное тестирование.

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

Кросс-культурное тестирование.

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

Кросс-культурное тестирование.

Цель — адаптировать зарубежный продукт для российского покупателя или наоборот.

Пользовательское тестирование

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

Айтрекинг-тестирование

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

Тестирование методом персонажей

Цель — понять поведение на сайте типичных представителей различных групп ЦА и на основе полученных знаний об их предпочтениях удовлетворить наиболее широкую группу пользователей.

Экспертный анализ

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

A/B-тестирование

Цель — предложить пользователям несколько вариантов дизайна и сравнить реакцию. Выделяются последовательные и параллельные A/B-тесты. При последовательном тестировании usability правки сразу вносятся на сайт и замеряются периоды до и после изменений. При параллельном делается несколько версий, которые сравниваются с основной.

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

  • оценку удобства использования;
  • сравнение с сайтами-конкурентами.

Подготовка к юзабилити-тестированию и получение отчета

Подготовка состоит из 4 основных этапов:

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

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

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

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

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

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

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

Как создать сценарий для респондентов?

Чтобы создать сценарий пользователя, важно понять 3 вещи:

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

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

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

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

Вот в качестве примера два варианта задания:

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

    Забронируйте номер в отеле Италии.

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

Примеры наших кейсов по юзабилити-тестированию

Проведение юзабилити-тестирования сайта

Процедура состоит из двух этапов.

    Юзабилити-тест.
    Для него нужен компьютер с веб-камерой и программа Eye Tracking для записи движения глаз пользователей. Программа учитывает все действия, которые происходят на экране: перемещение курсора, использование клавиатуры, переходы между вкладками. Важно записать тайм-коды заданий, чтобы быстрее ориентироваться в длинном видео.

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

Анализ результатов тестирования юзабилити

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

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

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

Примерное описание удобного ресурса

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

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

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

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

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

    Ресурс понятен и для новичков, и для опытных пользователей.

    Сообщение об ошибке пишется понятным языком, и посетитель понимает, как решить проблему, если она возникла.

    Информацию на сайте легко найти, и она соответствует запросам аудитории.

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

Зачем нужно юзабилити-тестирование?

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

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

Также тестирование понадобится, если вы хотите:

  • сравнить два интерфейса, например, старый и новый, ваш и конкурента, чтобы выяснить, какой из них лучше;
  • сравнить удобство интерфейса для двух групп пользователей, например, для новичков и опытных;
  • выявить потенциальные юзабилити-проблемы нового продукта еще до того, как он будет выпущен на рынок;
  • оценить соответствие продукта определенным KPI (например, «процесс оформления заказа занимает не более 5 минут»).

Чем юзабилити-тестирование отличается от фокус-групп?

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

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

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

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

В зависимости от степени участия модератора (UX-аналитика):

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

Один из вариантов удаленного немодерируемого тестирования

В зависимости от места расположения респондента:

  • очное — респондент и модератор находятся в одном помещении, как правило, в лаборатории, и общаются непосредственно;
  • удаленное — респондент участвует в тестировании из дома или со своего рабочего места. Как правило, это немодерируемое тестирование. Если требуется участие модератора, аналитик общается с респондентом по видеосвязи.

В зависимости от целей:

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

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

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

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

Как правило, мы проводим очные модерируемые юзабилити-тестирования. Это значит, что респондент приезжает в нашу лабораторию и выполняет задания под наблюдением юзабилити-специалиста.

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

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

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

Параллельно с написанием сценария идет поиск респондентов. Как правило, это 8-12 человек . Некоторые компании помогают нам привлекать респондентов из числа своих клиентов. Если такой возможности нет или это не соответствует задачам исследования, то мы ищем респондентов через специализированные агентства, например, РусОпрос. Мы передаем им требования к респондентам, а они предоставляют списки потенциальных участников тестирования. При этом мы тщательно контролируем качество рекрутинга: проводим дополнительный обзвон респондентов, задаем им вопросы об опыте участия в подобных исследованиях, и, если респондент кажется нам неподходящим, отсеиваем его.

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

Наша юзабилити-лаборатория. Вид из комнаты модератора. На экране дублируется изображение с экрана респондента

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

После того, как все сессии тестирования проведены, UX-аналитик составляет отчет, который передает заказчику.

Сколько времени занимает юзабилити-тестирование?

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

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

Входит ли eye-tracking в юзабилити-тестирование?

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

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

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

Что входит в юзабилити-отчет?

Как правило, отчет включает в себя:

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

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

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

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

Хотите, чтобы мы провели для вас юзабилити-тестирование?

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

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

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

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

Какими знаниями мы будем делиться?

  • обзоры инструментов аналитики и A/B – тестирования,
  • опыт и кейсы российских и зарубежных компаний по повышению конверсии,
  • приемы улучшения юзабилити и секреты пользовательских интерфейсов,
  • UX-исследования, инсайты и аналитика,
  • интервью и вебинары с экспертами рынка.

Ну а теперь ближе к теме.

Что такое юзабилити-тестирование и в чем его польза?

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

Для крупного, среднего бизнеса, интернет-сервисов это важный этап профессионального юзабилити-анализа. Используя юзабилити-тестирование вместе со стандартными методами и инструментами (системами аналитики, Вебвизором, эвристическим анализом и т.д.), вы сможете выдвигать правильные гипотезы для A/B-тестов, вносить правки в сайт и добиваться устойчивого повышения конверсии.

2. Онлайн-тестирование

Развитие интернета способствовало развитию дистанционного онлайн-тестирования
, которое, как правило, гораздо дешевле и быстрее. Это исследование без взаимодействия с тестировщиком в реальном времени. Если вы правильно напишете сценарий, этот метод значительно сэкономит ваши ресурсы. Конечно, можно найти удаленную фокус-группу, составить список вопросов, отослать по электронной почте и попросить людей самостоятельно протестировать сайт или продукт, проходя через сценарий и комментируя свои мысли и действия вслух. Но гораздо проще воспользоваться сервисами автоматизации. Флагманом зарубежного рынка является usertesting.com , на российском рынке мы предлагаем его аналог – . Огромные базы реальных тестировщиков позволяют мгновенно подобрать по любым параметрам фокус-группу (например, десять женщин от 30 до 35 лет, у которых есть кот) и в течение пары дней провести тестирование.

Преимущества онлайн-тестирования с помощью специализированных сервисов очевидны:

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

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

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

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

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

Для чего проводится тестирование ПО?

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

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

  • Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
    Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
  • Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
    Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
  • Принцип 3 — Раннее тестирование (Early testing).
    Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
  • Принцип 4 — Скопление дефектов (Defects clustering).
    Большая часть дефектов находится в ограниченном количестве модулей.
  • Принцип 5 — Парадокс пестицида (Pesticide paradox).
    Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
  • Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
  • Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

  • проверка готовности ПО к релизу;
  • проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:

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

Скриншот

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

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

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

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

  1. Анализ продукта
  2. Работа с требованиями
  3. Разработка стратегии тестирования и планирование процедур контроля качества
  4. Создание тестовой документации
  5. Тестирование прототипа
  6. Основное тестирование
  7. Стабилизация
  8. Эксплуатация

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

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

  1. анализ требований к проекту;
  2. проектирование;
  3. реализация;
  4. тестирование продукта;
  5. внедрение и поддержка.

Требования

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

Атрибуты требований:

  1. Корректность — точное описание разрабатываемого функционала.
  2. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
  3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
  4. Недвусмысленность — требование должно содержать однозначные формулировки.
  5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
  6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
  7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.
  8. Модифицируемость — в каждое требование можно внести изменение.
  9. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

  1. Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
  2. Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
  3. Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
  4. Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
  5. Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
  6. Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
  7. Вложения (Attachments) — скриншоты, видео или лог-файлы.
  8. Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
  9. Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
  10. Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
  11. Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Скриншот

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

  • Блокирующий (S1 – Blocker)
    тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
  • Критический (S2 – Critical)
    критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
  • Значительный (S3 – Major)
    не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
  • Незначительный (S4 – Minor)
    часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
  • Тривиальный (S5 – Trivial)
    почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

  • P1 Высокий (High)
    Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
  • P2 Средний (Medium)
    Не критичная для проекта ошибка, однако требует обязательного решения.
  • P3 Низкий (Low)
    Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Существует шесть базовых типов задач:

  • Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
  • Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
  • История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
  • Задача (task) — техническая задача, которую делает один из членов команды.
  • Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
  • Баг (bug) — задача, которая описывает ошибку в системе.

Тестовые среды

  • Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
  • Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
  • Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
  • Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
  • Продакшн среда (Production Env) – среда, в которой работают пользователи.

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

  • Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
  • Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
  • Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
  • Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
  • Release: финальная версия программы, которая готова к использованию.

Основные виды тестирования ПО

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

Скриншот

  1. Классификация по запуску кода на исполнение:
    • Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
    • Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
  2. Классификация по доступу к коду и архитектуре:
    • Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
    • Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
    • Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
  3. Классификация по уровню детализации приложения:
    • Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
    • Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
    • Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
    • Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
  4. Классификация по степени автоматизации:
    • Ручное тестирование.
    • Автоматизированное тестирование.
  5. Классификация по принципам работы с приложением
    • Позитивное тестирование — тестирование, при котором используются только корректные данные.
    • Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
  6. Классификация по уровню функционального тестирования:
    • Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
    • Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
    • Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
  7. Классификация в зависимости от исполнителей:
    • Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
    • Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
  8. Классификация в зависимости от целей тестирования:
    • Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
    • Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
      1. Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
      2. Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
      3. Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
      4. Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
      5. Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
      6. Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
      7. Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
      8. Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
      9. Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
      10. Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
      11. Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
      12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
      13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

  1. Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
  2. Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
  3. Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
  4. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
  5. Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
  6. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
  7. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Методы тестирования

Скриншот

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

  • тестирование, основанное на анализе внутренней структуры компонента или системы;
  • тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
  • Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

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

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

Согласно ISTQB, тестирование черного ящика — это:

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

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

  • Что необходимо протестировать?
  • Как будет проводиться тестирование?
  • Когда будет проводиться тестирование?
  • Критерии начала тестирования.
  • Критерии окончания тестирования.

Основные пункты тест плана:

  1. Идентификатор тест плана (Test plan identifier);
  2. Введение (Introduction);
  3. Объект тестирования (Test items);
  4. Функции, которые будут протестированы (Features to be tested;)
  5. Функции, которые не будут протестированы (Features not to be tested);
  6. Тестовые подходы (Approach);
  7. Критерии прохождения тестирования (Item pass/fail criteria);
  8. Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
  9. Результаты тестирования (Test deliverables);
  10. Задачи тестирования (Testing tasks);
  11. Ресурсы системы (Environmental needs);
  12. Обязанности (Responsibilities);
  13. Роли и ответственность (Staffing and training needs);
  14. Расписание (Schedule);
  15. Оценка рисков (Risks and contingencies);
  16. Согласования (Approvals).

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

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

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

Атрибуты тест кейса:

  • Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
  • Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
  • Ожидаемый результат (Expected result) — что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

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

  • P1 – Высокий (High) – требуется исправить в первую очередь;
  • P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом;
  • P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.

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

  • S1 – Блокирующий (Blocker) – дефект полностью блокирует выполнение функционала, нет никакого способа его обойти. Если провести аналогию с закрытым помещением и дверью – то дверь закрыта, у вас нет никакой возможности её открыть и покинуть помещение. Окон нет, ключ к двери не подходит.
  • S2 – Критический (Critical) – дефект блокирует часть функциональности, но есть альтернативный путь для его обхода. По аналогии с помещением и дверью: вы можете покинуть помещение через окно, хотя дверь по-прежнему закрыта и ключ к ней не подходит.
  • S3 – Значительный (Major) – дефект, указывающий на некорректную работу части функциональности. Зачастую связан не с тем, что функция не работает, а с тем, что она работает неправильно. В любом случае, существует более одной точки входа для инициации нужной функциональности. Так, вы можете покинуть помещение без использования ключа (дыра в безопасности), через вентиляцию (другая точка входа) или дверь открывается не в ту сторону (как следствие, упирается в угол и открывается только частично – некорректная реализация). Наиболее часто встречаются дефекты, которые можно отнести именно к этому уровню серьезности.
  • S4 – Незначительный (Minor) – дефект, не относящийся к функциональности системы. Обычно серьезность Minor проставляется для тех дефектов, которые относятся к удобству использования или интерфейсу. По аналогии с помещением и дверью – на двери написано «От себя», хотя она открывается на себя, неудобное расположение замочной скважины и т.д.
  • S5 – Тривиальный (Trivial) – дефект, не затрагивающий функциональность системы, а также оказывающий минимальное влияние на общее качество системы. Часто неотличим от уровня «minor». Обычно это грамматические дефекты в сопроводительной документации к системе. Иногда дефект относится к «невидимым» проблемам с точки зрения пользователя или пользовательского интерфейса и рассматривает сторонние библиотеки или сервисы, не относящиеся к самой разработанной системе. По аналогии с помещением и дверью – замок и ключ не одного производителя, в помещении слышится шум сверху (не относится к самому помещению) и т.д.

Но зачем нужно это деление, разве нельзя обойтись только одним атрибутом, например, серьезностью? Предположим, в некой системе не работает модуль отчетности. Это –дефект с уровнем серьезности «Блокирующий». Однако этот модуль потребуется только в конце отчетного периода (перед Новым Годом). Если сейчас лето, то данная функциональность не будет использоваться еще несколько месяцев. Как следствие, руководитель проекта или лицо, принимающее решение, может проставить низкий приоритет исправления.

Обратная ситуация: на лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании). Данный дефект способен сильно ударить по доверию пользователей к продукции, которую им предлагают: потенциальные клиенты могут подумать, что качество услуг весьма сомнительно, раз даже в названии компании присутствует дефект – и отказаться от использования продукта. С точки зрения подхода к качеству, даже нефункциональные дефекты с уровнем серьезности «Тривиальный» способны отрицательно повлиять на репутацию Компании. Поэтому такому дефекту может быть проставлен высокий приоритет исправления.

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

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

Для начала рассмотрим каждый атрибут в отдельности.

Серьезность

Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.

Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).

  • S1 – Блокирующая (Blocker). Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее функциями становится невозможна.
  • S2 – Критическая (Critical). Критическая ошибка, неправильно работающая бизнес-логика, проблема, приводящая в нерабочее состояние некоторую часть системы, но есть возможность для работы с тестируемой функцией, используя другие входные точки.
  • S3 – Значительная (Major). Значительная ошибка, часть бизнес-логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
  • S4 – Незначительная (Minor). Незначительная ошибка, не нарушающая бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
  • S5 – Тривиальная (Trivial). Тривиальная ошибка, не касающаяся бизнес-логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

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

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

1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.

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

У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.

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

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

2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.

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

Приоритет

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

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

  • P1 – Высокий (High) – требуется исправить в первую очередь.
  • P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом.
  • P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.

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

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

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

Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:

Матрица определения приоритета

Матрица определения приоритета

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

Различия Серьезности и Приоритета

Различия Серьезности и Приоритета

________________________________
Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.
________________________________

Предыдущие статьи по оформлению баг-репорта:
Назначение отчета https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-naznachenie/
Шаблон отчета об ошибке https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-shablon-otcheta-ob-oshibke/

Классификация ошибок с точки зрения тестировщика

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

Предлагается различать.

  1. Ошибки
    кодирования.

  2. Ошибки
    проектирования.

  3. Предложения
    тестировщика по улучшению программы.

  4. Расхождение
    с документацией.

  5. Взаимодействие
    с аппаратурой.

  6. Поведение
    программы, вызывающее вопросы
    тестировщика.

Как бы не привлекала такая классификация
своей простотой, приведенный выше
перечень возможных ошибок, говорит о
том, что воспользоваться ею можно только
в очень простых и частных случаях. В
общем случае у тестировщика нет
убедительных оснований отнести ошибку
к тому или иному разделу данной
классификации, так как обычно проблема
носит комплексный характер. Вероятность
ошибки такого отнесения также высока.
Следствием подобных ошибок в классификации
будет увеличение время отладки программы,
так как программные ошибки будут
направляться на исправление не тем
сотрудникам или подразделениям, которые
на самом деле должны ими заниматься.
Для предотвращения подобных ситуаций
могут применяться системы автоматизированной
классификации ошибок, позволяющие
быстро оценивать серьезность ошибок,
информировать об их возникновении
нужных специалистов и т.д. Вопросы
построения такого рода систем, в основу
работы которых положен анализ сообщений
об ошибках, рассмотрены в работе [8]. Их
функционирование должно опираться на
использование методов и моделей
искусственного интеллекта (в частности
методов классификации текстов).

Классификация ошибок по степени их критичности

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

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

Классификация может быть следующей.

Разрушение системы (Causes crash) — Под ним
объединяют все те ошибки в программе,
которые могут вызвать крах или зависание
всей системы, нарушить стабильность ее
работы.

Косметические (Cosmetic) — под этим понятием
объединяют ошибки дизайна (например,
не тот цвет линии или шрифт), пользовательского
интерфейса и т.п., которые не мешают
работать программе, но портят ее «товарный
вид».

Критические (Critical) – ошибки, которые
приводят к «зависанию» или «падению»
самой программы, не затрагивая операционной
системы в целом.

Error Handling — ошибки при обработке ошибок.

Functional — ошибки функциональности, не
относящиеся к критическим.

Setup — ошибки инсталляции.

Minor — малозначимые.

Suggestion – предложения по улучшению
программы (так называемые «фичи»
(feature).

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

Catastrophic — Failure may cause a crash.

Hazardous — Failure has a large negative impact on safety or
performance, or reduces the ability of the crew to operate the plane
due to physical distress or a higher workload, or causes serious or
fatal injuries among the passengers.

Major — Failure is significant, but has a lesser impact than a
Hazardous failure (for example, leads to passenger discomfort rather
than injuries).

Minor — Failure is noticeable, but has a lesser impact than a Major
failure (for example, causing passenger inconvenience or a routine
flight plan change)

No Effect — Failure has no impact on safety, aircraft operation, or
crew workload.

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

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

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

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

Что такое серьезность?

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

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

Что такое приоритет?

Приоритет определяется как порядок, в котором дефект должен быть исправлен. Чем выше приоритет, тем скорее дефект должен быть устранен.

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

Степень серьезности и приоритетность дефекта

В тестировании программного обеспечения серьезность дефекта можно разделить на четыре класса

  • Критическое : этот дефект указывает на полное завершение процесса, дальше ничего не может продолжаться
  • Major : Это очень серьезный дефект, который разрушает систему. Тем не менее, некоторые части системы остаются функциональными
  • Средняя : вызывает нежелательное поведение, но система все еще функционирует.
  • Низкий : это не приведет к серьезному отказу системы

Приоритет дефекта можно разделить на три класса

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

Советы по определению серьезности дефекта

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

Серьезность и приоритет в тестировании: введение и различия

Приоритет против серьезности: ключевое различие

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

  • Приоритет делится на три типа

    • Низкий
    • средний
    • Высокая

  • Серьезность подразделяется на пять типов

    • критический
    • Крупный
    • умеренный
    • Незначительный
    • косметический
  • Приоритет связан с планированием
  • Серьезность связана с функциональностью или стандартами
  • Приоритет указывает, как скоро ошибка должна быть исправлена
  • Серьезность указывает на серьезность дефекта на функциональности продукта
  • Приоритет дефектов определяется по согласованию с менеджером / клиентом
  • QA инженер определяет уровень серьезности дефекта
  • Приоритет определяется ценностью бизнеса
  • Серьезность определяется функциональностью
  • Его значение субъективно и может меняться в течение определенного периода времени в зависимости от изменения ситуации в проекте.
  • Его значение объективно и менее вероятно изменить
  • Высокий приоритет и низкий уровень серьезности указывают, дефект должен быть исправлен немедленно, но не влияет на приложение
  • Высокая степень серьезности и статус низкого приоритета указывают на то, что дефект должен быть исправлен, но не на немедленной основе
  • Статус приоритета основан на требованиях клиента
  • Статус серьезности основан на техническом аспекте продукта
  • Во время UAT команда разработчиков исправляет дефекты в зависимости от приоритета
  • Во время SIT команда разработчиков исправит дефекты в зависимости от серьезности, а затем приоритета

Пример серьезности и приоритета дефекта

Серьезность и приоритет в тестировании: введение и различия

Давайте посмотрим на пример низкой серьезности и высокого приоритета и наоборот

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

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

Дефект Triage

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

Как определить дефект дефектов:

Серьезность и приоритет в тестировании: введение и различия

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

Процесс сортировки включает в себя следующие этапы

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

Рекомендации, которые должен учитывать каждый тестер, прежде чем выбирать уровень серьезности

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

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

Вывод:

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

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

Поэтому баги, внесенные в системы отслеживания (bug-tracking системы), дифференцируются.

Каждый баг имеет атрибуты серьезности (Severity) и приоритета (Priority). На первый взгляд может показаться, что разницы между этими понятиями нет, но она все же есть. Серьезность больше касается технической стороны дела, а приоритет — организационной.

Серьезность (Severity) бага

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

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

Пример классификации серьезности багов:

  • Blocker. Блокирующая ошибка. Она делает невозможной всю последующую работу с программой. Для возобновления работы нужно исправить Blocker.
  • Critical. Критическая ошибка. Нарушает работу основного функционала. Баг проявляется постоянно и делает невозможным использование основных функций программы.
  • Major. Существенный баг. Затрудняет работу основного функционала или делает невозможным использование дополнительных функций.
  • Minor. Незначительный баг. На функционал системы влияет относительно мало, затрудняет использование  дополнительных функций. Для обхода этого бага могут быть очевидные пути.
  • Trivial. Тривиальный баг. Не влияет на функционал проекта, но ухудшает общее впечатление от работы с продуктом.

Приоритет (Priority) бага

Приоритет — атрибут, определяющий скорость устранения бага.

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

Виды приоритетов:

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

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

Частота (Frequency) — это показатель количества пользователей, которые сталкиваются с ошибкой. Определяется при анализе алгоритмов.

Частота бывает:

  • High. Высокая: с багом сталкиваются больше 80% пользователей.
  • Medium. Средняя: баг обнаружат от 30% до 80% пользователей.
  • Low. Низкая: баг проявляется у 10-30% пользователей.
  • Very low. Незначительная: такой баг встретится меньше чем 10% пользователей.

Глобальный приоритет бага (Global Severity)

Для определения глобального приоритета необходимо определить частоту проявления бага. Частота влияет на приоритет, а приоритет и серьезность влияют на глобальный приоритет бага.

Таким образом, для определения глобального приоритета бага нужно:

  1. Определить серьезность бага.
  2. Отдельно от серьезности определить приоритет.
  3. Определить частоту (независимо от серьезности и приоритета).
  4. Рассчитать влияние частоты на изначально определенный приоритет.

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

Средняя частота бага меняет приоритет только с низкого на обычный.

Низкая или незначительная частота вообще не меняет приоритет бага.

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

Приоритет/Серьезность Blocker Critical Minor Trivial
High Critical Critical Minor Trivial
Medium Critical Critical Minor Trivial
Low — — Trivial Trivial

Если глобальный приоритет — Critical, значит, баг нужно непременно исправить. Баги с приоритетом Minor тоже желательно исправить до релиза, хотя некоторое количество таких дефектов может остаться в проекте. Баги с приоритетом Trivial могут вообще не исправляться.

Высокий приоритет и низкая серьезность

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

Вот пара примеров:

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

Высокая серьезность и низкий приоритет

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

Примеры:

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

Итоги

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

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

Если кратко, то хороший баг-репорт позволяет:

  • воспроизвести проблему;
  • понять, в чем проблема, и какова ее важность.

Что такое баг, типы багов

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

Критичность и приоритет бага. Атрибуты баг-репорта

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

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

По критичности баги делят на:

S1. Блокирующий (Blocker). Всё тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.

S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функционал, не связанный с расшифровыванием каналов.

S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.

S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести неточный перевод с русского на английский в меню приёмника.

S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.

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

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

P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.

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

Что такое баг репорт, его типичная структура

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

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

Состав баг репорта приведен в таблице:

Заголовок (Summary)

Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.

Проект (Project)

Название тестируемого проекта

Компонент приложения (Component)

Название части или функции тестируемого продукта

Номер версии (Version)

Версия, на которой была найдена ошибка

Критичность

(Severity)

Наиболее распространена пятиуровневая система критичности:

S1 Блокирующий (Blocker)

S2 Критический (Critical)

S3 Значительный (Major)

S4 Незначительный (Minor)

S5 Тривиальный (Trivial)

Приоритет (Priority)

Приоритет дефекта:

P1 Высокий (High)

P2 Средний (Medium)

P3 Низкий (Low)

Статус (Status)

Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например:

  • Новый
  • Открыт
  • Закрыт

Автор (Author)

Создатель баг репорта

Назначен на (Assigned To)

Имя сотрудника, назначенного на решение проблемы

Описание (Description)

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

Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.

Полученный результат

Ожидаемый результат

Прикрепленный файл (Attachment)

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

Как правильно оформить баг-репорт

  1. Для начала нужно убедиться, что найденный баг ещё не был оформлен. Следует провести поиск его в соответствующем проекте по всем подходящим ключевым словам иили полям. Если баг уже есть, следует обновить его описание.
  2. Если баг не найден – нажимаем на кнопку создания бага. Не стоит забывать важное правило: один дефект — один баг в трекере.
  3. Далее нужно постараться кратко описать, что не работает — это и будет заголовок баг-репорта.
  4. После этого перейти к подробному описанию бага: указать шаги к воспроизведению.
  5. Указать ожидаемый результат. Можно добавить ссылку на спецификацию.
  6. Указать полученный результат.
  7. Указать версию ПО, также указать версию окружения.
  8. Если необходимо, приложить соответствующие артефакты: логи, скриншоты, дампы и т.д.

Ошибки при создании баг-репорта

Здесь перечислим проблемы, которые чаще всего встречаются при написании баг репорта.

Заголовок не понятен. Есть риск, что ни разработчик, ни коллеги не обратят внимания на довольно критичную проблему.

Отсутствуют шаги для воспроизведения. Есть риск, что разработчик, не поняв как повторить проблему, вернёт баг со статусом «Не воспроизводится».

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

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

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

Жизненный цикл бага

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

Если кратко, то после создания баг-репорта статус бага может выглядеть следующим образом:

  • Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.
  • Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека, который должен её проанализировать. В зависимости от решения, баг может быть:
  • Отложен (Postponed). Исправление бага отложено, т.к. он не является критичным на данном этапе разработки или по другим причинам.
  • Отклонен (Rejected). По разным причинам дефект может и не считаться таковым, что вынуждает отклонить его. Не баг, а фича.
  • Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему.
  • Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика, который должен исправить ошибку.
  • Исправлено (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
  • Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект. Если бага больше нет, он получает данный статус.
  • Повторно открыт (Reopened). Если опасения тестировщика оправданы, и баг в новом билде не исправлен – он все так же потребует исправления, поэтому вновь открывается.
  • Закрытый (Closed). В результате определенного количества перепроверок баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

Более наглядно жизненный цикл бага можно посмотреть на диаграмме:

При использовании системы тест менеджмента TestIT существует возможность интеграции с системами баг-трекинга. В нашей компании это JIRA. Достаточно нажать “save and create bug” и мы получаем почти готовый баг репорт в JIRA.

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

В разделе Description уже есть разделы steps, actual result and expected result, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

Вместо заключения

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

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

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

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

20 ВИДОВ ПРОГРАММНЫХ ДЕФЕКТОВ, КОТОРЫЕ ДОЛЖЕН ЗНАТЬ КАЖДЫЙ ТЕСТЕР

В этой статье мы обсудим самые распространенные типы ПО дефекты и способы их выявления.

Что такое дефект?

Дефект программного обеспечения — это ошибка, изъян, сбой или неисправность в компьютерной программе, из-за которой она выдает неправильный или неожиданный результат или ведет себя непреднамеренным образом. Программная ошибка возникает, когда фактические результаты не совпадают с ожидаемыми. Разработчики и программисты иногда допускают ошибки, которые создают ошибки, называемые дефектами. Большинство ошибок возникает из-за ошибок, которые допускают разработчики или программисты.

Обязательно прочтите: Разница между дефектом, ошибкой, ошибкой и сбоем

Типы программных ошибок при тестировании программного обеспечения

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

Ошибки программного обеспечения подразделяются на три типа:

  1. Дефекты программного обеспечения по своей природе
  2. Дефекты программного обеспечения по их приоритету
  3. Дефекты программного обеспечения по их серьезности

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

#1. Дефекты программного обеспечения по своей природе

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

#1. Функциональные ошибки

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

Функциональные ошибки можно исправить, выполнив функциональное тестирование.

#2. Ошибки на уровне модуля

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

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

#3. Ошибки уровня интеграции

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

Ошибки интеграции можно исправить, выполнив интеграционное тестирование.

#4. Дефекты юзабилити

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

Во время тестирования удобства использования тестировщики программного обеспечения проверяют приложения на соответствие требованиям пользователей и Руководству по доступности веб-контента (WCAG) для выявления таких проблем. Однако они могут оказать существенное влияние на общее качество программного обеспечения.

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

#5. Дефекты производительности

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

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

#6. Дефекты безопасности

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

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

#7. Дефекты совместимости

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

Ошибки совместимости можно исправить, выполнение тестирования совместимости.

#8. Синтаксические ошибки

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

#9. Логические ошибки

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

Общие симптомы логических ошибок включают:

  • Неверные результаты или выходные данные
  • Неожиданное поведение
  • Сбой или зависание программного обеспечения

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

#2. Дефекты программного обеспечения по степени серьезности

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

#1. Критические дефекты

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

#2. Серьезные дефекты

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

#3. Незначительные дефекты

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

#4. Тривиальные дефекты

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

#3. Дефекты программного обеспечения по приоритету

#1. Дефекты с низким приоритетом

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

#2. Дефекты со средним приоритетом

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

#3. Дефекты с высоким приоритетом

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

Некоторые распространенные примеры дефектов с высоким приоритетом включают:

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

#4. Срочные дефекты

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

#4. Дополнительные дефекты

#1. Отсутствующие дефекты

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

#2. Неправильные дефекты

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

#3. Дефекты регрессии

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

Часто задаваемые вопросы — Типы программных ошибок< /h2>

Почему так важна правильная классификация дефектов?

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

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

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

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

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

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

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

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

1) Репликация. Первым этапом является воспроизведение ошибки. Это включает в себя попытку воспроизвести тот же набор шагов, в котором возникла ошибка. Это поможет проверить, является ли ошибка реальной или нет.
2) Изоляция. После того, как ошибка воспроизведена, следующим шагом будет попытка ее изоляции. Это включает в себя выяснение того, что именно вызывает ошибку. Для этого тестировщики должны задать себе несколько вопросов, например:
– Какие входные данные вызывают ошибку?
– При каких различных условиях возникает ошибка?
– Каковы различные способы проявления ошибки?
3) Анализ: после Изолируя ошибку, следующим шагом будет ее анализ. Это включает в себя понимание того, почему возникает ошибка. Тестировщики должны задать себе несколько вопросов, таких как:
– Какова основная причина ошибки?
– Какими способами можно исправить ошибку?
– Какое исправление было бы наиболее эффективным? эффективно?
4) Отчет. После анализа ошибки следующим шагом является сообщение о ней. Это включает в себя создание отчета об ошибке, который включает всю соответствующую информацию об ошибке. Отчет должен быть четким и кратким, чтобы разработчики могли его легко понять.
5) Проверка. После сообщения об ошибке следующим шагом является проверка того, была ли она исправлена. Это включает в себя повторное тестирование программного обеспечения, чтобы убедиться, что ошибка все еще существует. Если ошибка исправлена, то тестер может подтвердить это и закрыть отчет об ошибке. Если ошибка все еще существует, тестировщик может повторно открыть отчет об ошибке.

Заключение

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

Задавая правильные вопросы и применяя правильные методы, тестировщики могут помочь обеспечить чтобы дефекты обнаруживались и исправлялись как можно раньше в процессе разработки.
TAG: qa

Источник

Как правильно описывать юзабилити-проблемы

24 октября 2017

24 Октябрь

Определение юзабилити-проблемы

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

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

Описание проблемы

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

Плохо Хорошо
Респонденты испытывают трудности с поиском истории операций, потому что надпись «История операций» плохо заметна. Почему: Не указано, как это проявляется в поведении пользователей. Невнятно описана особенность интерфейса, из-за которой возникает проблема. Ссылка на историю операций расположена в нетипичном месте: около левого края экрана, в отрыве от главного меню. Надпись «История операций» сделана мелким белым шрифтом, который трудно читается на сером фоне. Поэтому респонденты испытывают трудности с поиском истории операций: они ищут ее в главном меню и в правой колонке, но не замечают ее слева.
При выборе некоторых курсов всплывающее окно с курсом оказывается не полностью развернутым, при этом возможность развернуть его отсутствует. Почему: Из описания проблемы непонятно, чем это мешает пользователям. При выборе некоторых курсов всплывающее окно с курсом оказывается не полностью развернуто, при этом возможность развернуть его отсутствует. Часть контента, размещенного на странице курса, не умещается в окно. Чтобы прочитать расположенный на странице текст, респонденты вынуждены использовать горизонтальную прокрутку. После выполнения задания респонденты снижали оценку удовлетворенности и отмечали неудобство, связанное с горизонтальной прокруткой.
Респонденты не читают раздел о медицинской и юридической поддержке держателей премиальных карт. Почему: Если, не ознакомившись с информацией из этих разделов, пользователь все же смог достичь своей цели (выбрать нужную карту), то это не юзабилити-проблема. В противном случае нужно указать, чем плохо то, что пользователь не получил эту информацию. Респонденты не находят информацию о преимуществах премиальной карты, которая должна дать информацию, достаточную для принятия решения о покупке. Описание преимуществ находится в разделе под названием «Медицинская и юридическая поддержка», куда 5 из 8 респондентов решили не заходить, а 3 из 8 зашли и сразу вышли.

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

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

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

Плохо Хорошо
Название ссылки «Виртуальная карта MasterCard» непонятно для пользователей. Почему: Не указано, по каким признакам аналитик определил, что название ссылки непонятно; не указано, к каким последствиям это приводит. Неопытные респонденты, никогда не совершавшие покупки через Интернет, не знают, что такое «виртуальная карта». Пытаясь найти способ безопасно оплачивать покупки через интернет, они ищут ссылки с названием «Безопасные покупки», «Безопасная оплата через интернет», и, не найдя их, решают, что такой возможности у них нет. Название ссылки «Виртуальная карта MasterCard Virtual» непонятно для респондентов и не помогает им сделать правильный выбор.

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

Плохо Хорошо
Окно чата с консультантом раздражает пользователей. Почему: «Раздражает» — эмоционально окрашенное слово. Из описания проблемы непонятны признаки, по которым аналитик определил, что окно чата действительно раздражает пользователей и причина, по которой пользователи чувствуют раздражение. 5 респондентов из 8 отказались читать текст на странице, сказав, что им мешает окно чата с консультантом. Окно чата с консультантом мигает, издает звуки и закрывает часть текста, делая чтение практически невозможным.
Цветовое оформление системы мрачное и не нравится респондентам. Почему: «Мрачное» — ничем не подкрепленная оценка автора отчета. Все экраны системы имеют черный фон. Впервые увидев систему, 6 из 12 респондентов сообщили, что черный цвет их «напрягает». Неприятие черного цвета сохраняется на протяжении всего тестирования.

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

Критичность и встречаемость

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

Примеры проблем разной степени критичности:

Высокая Средняя Низкая
Респонденты не могли найти раздел «Счета». 3 из 8 респондентов сделали вывод, что у них нет счетов, а есть только карты. Респонденты не нашли раздел «Счета» и-за того, что он находится за линией прокрутки. Не найдя раздел, пользователи пытались взаимодействовать с картой, однако и там информацию не находили. Респондентам приходилось прицеливаться, вводя сумму оплаты телефона. При вводе суммы оплаты мобильной связи открывается стандартная символьная клавиатура, а кнопки с цифрами на ней мелкие, поэтому респондентам приходилось прилагать значительные усилия, чтобы не ошибиться: респонденты щурились, наклонялись ближе к экрану, а в некоторых случаях делали ошибки. 1 респондент из 8 принял пиктограмму «галочка в кружочке» на экране со статусом завершения операции за кнопку, закрывающую окно, и несколько раз пытался нажать на нее вместо кнопки «ОК». Пиктограмма крупная, обведена в кружок, выделена тенью, поэтому выглядит как интерактивный элемент. Кнопка «ОК», напротив, мелкая и сливается с фоном. Это спровоцировало пользователя совершить ошибку.

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

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

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

Иллюстрации

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

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

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

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

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

  1. Анализ продукта
  2. Работа с требованиями
  3. Разработка стратегии тестирования и планирование процедур контроля качества
  4. Создание тестовой документации
  5. Тестирование прототипа
  6. Основное тестирование
  7. Стабилизация
  8. Эксплуатация

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

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

  1. анализ требований к проекту;
  2. проектирование;
  3. реализация;
  4. тестирование продукта;
  5. внедрение и поддержка.

Требования

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

Атрибуты требований:

  1. Корректность — точное описание разрабатываемого функционала.
  2. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
  3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
  4. Недвусмысленность — требование должно содержать однозначные формулировки.
  5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
  6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
  7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.
  8. Модифицируемость — в каждое требование можно внести изменение.
  9. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

  1. Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
  2. Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
  3. Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
  4. Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
  5. Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
  6. Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
  7. Вложения (Attachments) — скриншоты, видео или лог-файлы.
  8. Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
  9. Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
  10. Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
  11. Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Скриншот

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

  • Блокирующий (S1 – Blocker)
    тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
  • Критический (S2 – Critical)
    критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
  • Значительный (S3 – Major)
    не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
  • Незначительный (S4 – Minor)
    часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
  • Тривиальный (S5 – Trivial)
    почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

  • P1 Высокий (High)
    Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
  • P2 Средний (Medium)
    Не критичная для проекта ошибка, однако требует обязательного решения.
  • P3 Низкий (Low)
    Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Существует шесть базовых типов задач:

  • Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
  • Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
  • История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
  • Задача (task) — техническая задача, которую делает один из членов команды.
  • Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
  • Баг (bug) — задача, которая описывает ошибку в системе.

Тестовые среды

  • Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
  • Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
  • Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
  • Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
  • Продакшн среда (Production Env) – среда, в которой работают пользователи.

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

  • Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
  • Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
  • Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
  • Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
  • Release: финальная версия программы, которая готова к использованию.

Основные виды тестирования ПО

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

Скриншот

  1. Классификация по запуску кода на исполнение:
    • Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
    • Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
  2. Классификация по доступу к коду и архитектуре:
    • Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
    • Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
    • Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
  3. Классификация по уровню детализации приложения:
    • Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
    • Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
    • Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
    • Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
  4. Классификация по степени автоматизации:
    • Ручное тестирование.
    • Автоматизированное тестирование.
  5. Классификация по принципам работы с приложением
    • Позитивное тестирование — тестирование, при котором используются только корректные данные.
    • Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
  6. Классификация по уровню функционального тестирования:
    • Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
    • Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
    • Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
  7. Классификация в зависимости от исполнителей:
    • Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
    • Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
  8. Классификация в зависимости от целей тестирования:
    • Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
    • Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
      1. Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
      2. Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
      3. Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
      4. Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
      5. Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
      6. Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
      7. Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
      8. Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
      9. Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
      10. Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
      11. Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
      12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
      13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

  1. Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
  2. Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
  3. Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
  4. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
  5. Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
  6. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
  7. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Методы тестирования

Скриншот

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

  • тестирование, основанное на анализе внутренней структуры компонента или системы;
  • тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
  • Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

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

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

Согласно ISTQB, тестирование черного ящика — это:

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

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

  • Что необходимо протестировать?
  • Как будет проводиться тестирование?
  • Когда будет проводиться тестирование?
  • Критерии начала тестирования.
  • Критерии окончания тестирования.

Основные пункты тест плана:

  1. Идентификатор тест плана (Test plan identifier);
  2. Введение (Introduction);
  3. Объект тестирования (Test items);
  4. Функции, которые будут протестированы (Features to be tested;)
  5. Функции, которые не будут протестированы (Features not to be tested);
  6. Тестовые подходы (Approach);
  7. Критерии прохождения тестирования (Item pass/fail criteria);
  8. Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
  9. Результаты тестирования (Test deliverables);
  10. Задачи тестирования (Testing tasks);
  11. Ресурсы системы (Environmental needs);
  12. Обязанности (Responsibilities);
  13. Роли и ответственность (Staffing and training needs);
  14. Расписание (Schedule);
  15. Оценка рисков (Risks and contingencies);
  16. Согласования (Approvals).

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

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

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

Атрибуты тест кейса:

  • Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
  • Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
  • Ожидаемый результат (Expected result) — что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

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

  • P1 – Высокий (High) – требуется исправить в первую очередь;
  • P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом;
  • P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.

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

  • S1 – Блокирующий (Blocker) – дефект полностью блокирует выполнение функционала, нет никакого способа его обойти. Если провести аналогию с закрытым помещением и дверью – то дверь закрыта, у вас нет никакой возможности её открыть и покинуть помещение. Окон нет, ключ к двери не подходит.
  • S2 – Критический (Critical) – дефект блокирует часть функциональности, но есть альтернативный путь для его обхода. По аналогии с помещением и дверью: вы можете покинуть помещение через окно, хотя дверь по-прежнему закрыта и ключ к ней не подходит.
  • S3 – Значительный (Major) – дефект, указывающий на некорректную работу части функциональности. Зачастую связан не с тем, что функция не работает, а с тем, что она работает неправильно. В любом случае, существует более одной точки входа для инициации нужной функциональности. Так, вы можете покинуть помещение без использования ключа (дыра в безопасности), через вентиляцию (другая точка входа) или дверь открывается не в ту сторону (как следствие, упирается в угол и открывается только частично – некорректная реализация). Наиболее часто встречаются дефекты, которые можно отнести именно к этому уровню серьезности.
  • S4 – Незначительный (Minor) – дефект, не относящийся к функциональности системы. Обычно серьезность Minor проставляется для тех дефектов, которые относятся к удобству использования или интерфейсу. По аналогии с помещением и дверью – на двери написано «От себя», хотя она открывается на себя, неудобное расположение замочной скважины и т.д.
  • S5 – Тривиальный (Trivial) – дефект, не затрагивающий функциональность системы, а также оказывающий минимальное влияние на общее качество системы. Часто неотличим от уровня «minor». Обычно это грамматические дефекты в сопроводительной документации к системе. Иногда дефект относится к «невидимым» проблемам с точки зрения пользователя или пользовательского интерфейса и рассматривает сторонние библиотеки или сервисы, не относящиеся к самой разработанной системе. По аналогии с помещением и дверью – замок и ключ не одного производителя, в помещении слышится шум сверху (не относится к самому помещению) и т.д.

Но зачем нужно это деление, разве нельзя обойтись только одним атрибутом, например, серьезностью? Предположим, в некой системе не работает модуль отчетности. Это –дефект с уровнем серьезности «Блокирующий». Однако этот модуль потребуется только в конце отчетного периода (перед Новым Годом). Если сейчас лето, то данная функциональность не будет использоваться еще несколько месяцев. Как следствие, руководитель проекта или лицо, принимающее решение, может проставить низкий приоритет исправления.

Обратная ситуация: на лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании). Данный дефект способен сильно ударить по доверию пользователей к продукции, которую им предлагают: потенциальные клиенты могут подумать, что качество услуг весьма сомнительно, раз даже в названии компании присутствует дефект – и отказаться от использования продукта. С точки зрения подхода к качеству, даже нефункциональные дефекты с уровнем серьезности «Тривиальный» способны отрицательно повлиять на репутацию Компании. Поэтому такому дефекту может быть проставлен высокий приоритет исправления.

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

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

Для начала рассмотрим каждый атрибут в отдельности.

Серьезность

Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.

Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).

  • S1 – Блокирующая (Blocker). Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее функциями становится невозможна.
  • S2 – Критическая (Critical). Критическая ошибка, неправильно работающая бизнес-логика, проблема, приводящая в нерабочее состояние некоторую часть системы, но есть возможность для работы с тестируемой функцией, используя другие входные точки.
  • S3 – Значительная (Major). Значительная ошибка, часть бизнес-логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
  • S4 – Незначительная (Minor). Незначительная ошибка, не нарушающая бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
  • S5 – Тривиальная (Trivial). Тривиальная ошибка, не касающаяся бизнес-логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

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

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

1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.

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

У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.

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

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

2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.

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

Приоритет

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

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

  • P1 – Высокий (High) – требуется исправить в первую очередь.
  • P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом.
  • P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.

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

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

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

Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:

Матрица определения приоритета

Матрица определения приоритета

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

Различия Серьезности и Приоритета

Различия Серьезности и Приоритета

________________________________
Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.
________________________________

Предыдущие статьи по оформлению баг-репорта:
Назначение отчета https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-naznachenie/
Шаблон отчета об ошибке https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-shablon-otcheta-ob-oshibke/

Классификация ошибок с точки зрения тестировщика

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

Предлагается различать.

  1. Ошибки
    кодирования.

  2. Ошибки
    проектирования.

  3. Предложения
    тестировщика по улучшению программы.

  4. Расхождение
    с документацией.

  5. Взаимодействие
    с аппаратурой.

  6. Поведение
    программы, вызывающее вопросы
    тестировщика.

Как бы не привлекала такая классификация
своей простотой, приведенный выше
перечень возможных ошибок, говорит о
том, что воспользоваться ею можно только
в очень простых и частных случаях. В
общем случае у тестировщика нет
убедительных оснований отнести ошибку
к тому или иному разделу данной
классификации, так как обычно проблема
носит комплексный характер. Вероятность
ошибки такого отнесения также высока.
Следствием подобных ошибок в классификации
будет увеличение время отладки программы,
так как программные ошибки будут
направляться на исправление не тем
сотрудникам или подразделениям, которые
на самом деле должны ими заниматься.
Для предотвращения подобных ситуаций
могут применяться системы автоматизированной
классификации ошибок, позволяющие
быстро оценивать серьезность ошибок,
информировать об их возникновении
нужных специалистов и т.д. Вопросы
построения такого рода систем, в основу
работы которых положен анализ сообщений
об ошибках, рассмотрены в работе [8]. Их
функционирование должно опираться на
использование методов и моделей
искусственного интеллекта (в частности
методов классификации текстов).

Классификация ошибок по степени их критичности

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

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

Классификация может быть следующей.

Разрушение системы (Causes crash) — Под ним
объединяют все те ошибки в программе,
которые могут вызвать крах или зависание
всей системы, нарушить стабильность ее
работы.

Косметические (Cosmetic) — под этим понятием
объединяют ошибки дизайна (например,
не тот цвет линии или шрифт), пользовательского
интерфейса и т.п., которые не мешают
работать программе, но портят ее «товарный
вид».

Критические (Critical) – ошибки, которые
приводят к «зависанию» или «падению»
самой программы, не затрагивая операционной
системы в целом.

Error Handling — ошибки при обработке ошибок.

Functional — ошибки функциональности, не
относящиеся к критическим.

Setup — ошибки инсталляции.

Minor — малозначимые.

Suggestion – предложения по улучшению
программы (так называемые «фичи»
(feature).

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

Catastrophic — Failure may cause a crash.

Hazardous — Failure has a large negative impact on safety or
performance, or reduces the ability of the crew to operate the plane
due to physical distress or a higher workload, or causes serious or
fatal injuries among the passengers.

Major — Failure is significant, but has a lesser impact than a
Hazardous failure (for example, leads to passenger discomfort rather
than injuries).

Minor — Failure is noticeable, but has a lesser impact than a Major
failure (for example, causing passenger inconvenience or a routine
flight plan change)

No Effect — Failure has no impact on safety, aircraft operation, or
crew workload.

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

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

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

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

Что такое серьезность?

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

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

Что такое приоритет?

Приоритет определяется как порядок, в котором дефект должен быть исправлен. Чем выше приоритет, тем скорее дефект должен быть устранен.

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

Степень серьезности и приоритетность дефекта

В тестировании программного обеспечения серьезность дефекта можно разделить на четыре класса

  • Критическое : этот дефект указывает на полное завершение процесса, дальше ничего не может продолжаться
  • Major : Это очень серьезный дефект, который разрушает систему. Тем не менее, некоторые части системы остаются функциональными
  • Средняя : вызывает нежелательное поведение, но система все еще функционирует.
  • Низкий : это не приведет к серьезному отказу системы

Приоритет дефекта можно разделить на три класса

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

Советы по определению серьезности дефекта

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

Серьезность и приоритет в тестировании: введение и различия

Приоритет против серьезности: ключевое различие

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

  • Приоритет делится на три типа

    • Низкий
    • средний
    • Высокая

  • Серьезность подразделяется на пять типов

    • критический
    • Крупный
    • умеренный
    • Незначительный
    • косметический
  • Приоритет связан с планированием
  • Серьезность связана с функциональностью или стандартами
  • Приоритет указывает, как скоро ошибка должна быть исправлена
  • Серьезность указывает на серьезность дефекта на функциональности продукта
  • Приоритет дефектов определяется по согласованию с менеджером / клиентом
  • QA инженер определяет уровень серьезности дефекта
  • Приоритет определяется ценностью бизнеса
  • Серьезность определяется функциональностью
  • Его значение субъективно и может меняться в течение определенного периода времени в зависимости от изменения ситуации в проекте.
  • Его значение объективно и менее вероятно изменить
  • Высокий приоритет и низкий уровень серьезности указывают, дефект должен быть исправлен немедленно, но не влияет на приложение
  • Высокая степень серьезности и статус низкого приоритета указывают на то, что дефект должен быть исправлен, но не на немедленной основе
  • Статус приоритета основан на требованиях клиента
  • Статус серьезности основан на техническом аспекте продукта
  • Во время UAT команда разработчиков исправляет дефекты в зависимости от приоритета
  • Во время SIT команда разработчиков исправит дефекты в зависимости от серьезности, а затем приоритета

Пример серьезности и приоритета дефекта

Серьезность и приоритет в тестировании: введение и различия

Давайте посмотрим на пример низкой серьезности и высокого приоритета и наоборот

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

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

Дефект Triage

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

Как определить дефект дефектов:

Серьезность и приоритет в тестировании: введение и различия

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

Процесс сортировки включает в себя следующие этапы

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

Рекомендации, которые должен учитывать каждый тестер, прежде чем выбирать уровень серьезности

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

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

Вывод:

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

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

Поэтому баги, внесенные в системы отслеживания (bug-tracking системы), дифференцируются.

Каждый баг имеет атрибуты серьезности (Severity) и приоритета (Priority). На первый взгляд может показаться, что разницы между этими понятиями нет, но она все же есть. Серьезность больше касается технической стороны дела, а приоритет — организационной.

Серьезность (Severity) бага

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

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

Пример классификации серьезности багов:

  • Blocker. Блокирующая ошибка. Она делает невозможной всю последующую работу с программой. Для возобновления работы нужно исправить Blocker.
  • Critical. Критическая ошибка. Нарушает работу основного функционала. Баг проявляется постоянно и делает невозможным использование основных функций программы.
  • Major. Существенный баг. Затрудняет работу основного функционала или делает невозможным использование дополнительных функций.
  • Minor. Незначительный баг. На функционал системы влияет относительно мало, затрудняет использование  дополнительных функций. Для обхода этого бага могут быть очевидные пути.
  • Trivial. Тривиальный баг. Не влияет на функционал проекта, но ухудшает общее впечатление от работы с продуктом.

Приоритет (Priority) бага

Приоритет — атрибут, определяющий скорость устранения бага.

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

Виды приоритетов:

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

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

Частота (Frequency) — это показатель количества пользователей, которые сталкиваются с ошибкой. Определяется при анализе алгоритмов.

Частота бывает:

  • High. Высокая: с багом сталкиваются больше 80% пользователей.
  • Medium. Средняя: баг обнаружат от 30% до 80% пользователей.
  • Low. Низкая: баг проявляется у 10-30% пользователей.
  • Very low. Незначительная: такой баг встретится меньше чем 10% пользователей.

Глобальный приоритет бага (Global Severity)

Для определения глобального приоритета необходимо определить частоту проявления бага. Частота влияет на приоритет, а приоритет и серьезность влияют на глобальный приоритет бага.

Таким образом, для определения глобального приоритета бага нужно:

  1. Определить серьезность бага.
  2. Отдельно от серьезности определить приоритет.
  3. Определить частоту (независимо от серьезности и приоритета).
  4. Рассчитать влияние частоты на изначально определенный приоритет.

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

Средняя частота бага меняет приоритет только с низкого на обычный.

Низкая или незначительная частота вообще не меняет приоритет бага.

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

Приоритет/Серьезность Blocker Critical Minor Trivial
High Critical Critical Minor Trivial
Medium Critical Critical Minor Trivial
Low — — Trivial Trivial

Если глобальный приоритет — Critical, значит, баг нужно непременно исправить. Баги с приоритетом Minor тоже желательно исправить до релиза, хотя некоторое количество таких дефектов может остаться в проекте. Баги с приоритетом Trivial могут вообще не исправляться.

Высокий приоритет и низкая серьезность

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

Вот пара примеров:

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

Высокая серьезность и низкий приоритет

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

Примеры:

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

Итоги

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

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

Если кратко, то хороший баг-репорт позволяет:

  • воспроизвести проблему;
  • понять, в чем проблема, и какова ее важность.

Что такое баг, типы багов

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

Критичность и приоритет бага. Атрибуты баг-репорта

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

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

По критичности баги делят на:

S1. Блокирующий (Blocker). Всё тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.

S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функционал, не связанный с расшифровыванием каналов.

S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.

S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести неточный перевод с русского на английский в меню приёмника.

S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.

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

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

P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.

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

Что такое баг репорт, его типичная структура

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

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

Состав баг репорта приведен в таблице:

Заголовок (Summary)

Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.

Проект (Project)

Название тестируемого проекта

Компонент приложения (Component)

Название части или функции тестируемого продукта

Номер версии (Version)

Версия, на которой была найдена ошибка

Критичность

(Severity)

Наиболее распространена пятиуровневая система критичности:

S1 Блокирующий (Blocker)

S2 Критический (Critical)

S3 Значительный (Major)

S4 Незначительный (Minor)

S5 Тривиальный (Trivial)

Приоритет (Priority)

Приоритет дефекта:

P1 Высокий (High)

P2 Средний (Medium)

P3 Низкий (Low)

Статус (Status)

Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например:

  • Новый
  • Открыт
  • Закрыт

Автор (Author)

Создатель баг репорта

Назначен на (Assigned To)

Имя сотрудника, назначенного на решение проблемы

Описание (Description)

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

Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.

Полученный результат

Ожидаемый результат

Прикрепленный файл (Attachment)

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

Как правильно оформить баг-репорт

  1. Для начала нужно убедиться, что найденный баг ещё не был оформлен. Следует провести поиск его в соответствующем проекте по всем подходящим ключевым словам иили полям. Если баг уже есть, следует обновить его описание.
  2. Если баг не найден – нажимаем на кнопку создания бага. Не стоит забывать важное правило: один дефект — один баг в трекере.
  3. Далее нужно постараться кратко описать, что не работает — это и будет заголовок баг-репорта.
  4. После этого перейти к подробному описанию бага: указать шаги к воспроизведению.
  5. Указать ожидаемый результат. Можно добавить ссылку на спецификацию.
  6. Указать полученный результат.
  7. Указать версию ПО, также указать версию окружения.
  8. Если необходимо, приложить соответствующие артефакты: логи, скриншоты, дампы и т.д.

Ошибки при создании баг-репорта

Здесь перечислим проблемы, которые чаще всего встречаются при написании баг репорта.

Заголовок не понятен. Есть риск, что ни разработчик, ни коллеги не обратят внимания на довольно критичную проблему.

Отсутствуют шаги для воспроизведения. Есть риск, что разработчик, не поняв как повторить проблему, вернёт баг со статусом «Не воспроизводится».

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

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

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

Жизненный цикл бага

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

Если кратко, то после создания баг-репорта статус бага может выглядеть следующим образом:

  • Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.
  • Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека, который должен её проанализировать. В зависимости от решения, баг может быть:
  • Отложен (Postponed). Исправление бага отложено, т.к. он не является критичным на данном этапе разработки или по другим причинам.
  • Отклонен (Rejected). По разным причинам дефект может и не считаться таковым, что вынуждает отклонить его. Не баг, а фича.
  • Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему.
  • Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика, который должен исправить ошибку.
  • Исправлено (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
  • Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект. Если бага больше нет, он получает данный статус.
  • Повторно открыт (Reopened). Если опасения тестировщика оправданы, и баг в новом билде не исправлен – он все так же потребует исправления, поэтому вновь открывается.
  • Закрытый (Closed). В результате определенного количества перепроверок баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

Более наглядно жизненный цикл бага можно посмотреть на диаграмме:

При использовании системы тест менеджмента TestIT существует возможность интеграции с системами баг-трекинга. В нашей компании это JIRA. Достаточно нажать “save and create bug” и мы получаем почти готовый баг репорт в JIRA.

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

В разделе Description уже есть разделы steps, actual result and expected result, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

Вместо заключения

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

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

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

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

20 ВИДОВ ПРОГРАММНЫХ ДЕФЕКТОВ, КОТОРЫЕ ДОЛЖЕН ЗНАТЬ КАЖДЫЙ ТЕСТЕР

В этой статье мы обсудим самые распространенные типы ПО дефекты и способы их выявления.

Что такое дефект?

Дефект программного обеспечения — это ошибка, изъян, сбой или неисправность в компьютерной программе, из-за которой она выдает неправильный или неожиданный результат или ведет себя непреднамеренным образом. Программная ошибка возникает, когда фактические результаты не совпадают с ожидаемыми. Разработчики и программисты иногда допускают ошибки, которые создают ошибки, называемые дефектами. Большинство ошибок возникает из-за ошибок, которые допускают разработчики или программисты.

Обязательно прочтите: Разница между дефектом, ошибкой, ошибкой и сбоем

Типы программных ошибок при тестировании программного обеспечения

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

Ошибки программного обеспечения подразделяются на три типа:

  1. Дефекты программного обеспечения по своей природе
  2. Дефекты программного обеспечения по их приоритету
  3. Дефекты программного обеспечения по их серьезности

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

#1. Дефекты программного обеспечения по своей природе

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

#1. Функциональные ошибки

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

Функциональные ошибки можно исправить, выполнив функциональное тестирование.

#2. Ошибки на уровне модуля

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

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

#3. Ошибки уровня интеграции

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

Ошибки интеграции можно исправить, выполнив интеграционное тестирование.

#4. Дефекты юзабилити

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

Во время тестирования удобства использования тестировщики программного обеспечения проверяют приложения на соответствие требованиям пользователей и Руководству по доступности веб-контента (WCAG) для выявления таких проблем. Однако они могут оказать существенное влияние на общее качество программного обеспечения.

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

#5. Дефекты производительности

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

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

#6. Дефекты безопасности

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

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

#7. Дефекты совместимости

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

Ошибки совместимости можно исправить, выполнение тестирования совместимости.

#8. Синтаксические ошибки

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

#9. Логические ошибки

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

Общие симптомы логических ошибок включают:

  • Неверные результаты или выходные данные
  • Неожиданное поведение
  • Сбой или зависание программного обеспечения

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

#2. Дефекты программного обеспечения по степени серьезности

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

#1. Критические дефекты

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

#2. Серьезные дефекты

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

#3. Незначительные дефекты

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

#4. Тривиальные дефекты

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

#3. Дефекты программного обеспечения по приоритету

#1. Дефекты с низким приоритетом

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

#2. Дефекты со средним приоритетом

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

#3. Дефекты с высоким приоритетом

Как следует из названия, дефекты с высоким приоритетом — это те, которые сильно влияют на функционирование программного обеспечения. В большинстве случаев эти дефекты необходимо исправлять немедленно, так как они могут привести к серьезным нарушениям нормального рабочего процесса. Дефекты с высоким приоритетом обычно классифицируются как непреодолимые, так как они могут помешать пользователю продолжить выполнение поставленной задачи.

Некоторые распространенные примеры дефектов с высоким приоритетом включают:

  • Дефекты, из-за которых приложение не работает. сбой
  • Дефекты, препятствующие выполнению задачи пользователем
  • Дефекты, приводящие к потере или повреждению данных
  • Дефекты, раскрывающие конфиденциальную информацию неавторизованным пользователям
  • Дефекты, делающие возможным несанкционированный доступ к системе
  • Дефекты, приводящие к потере функциональности
  • Дефекты, приводящие к неправильным результатам или неточным данным
  • Дефекты, вызывающие проблемы с производительностью, такие как чрезмерное использование памяти или медленное время отклика

#4. Срочные дефекты

Срочные дефекты — это дефекты, которые необходимо устранить в течение 24 часов после сообщения о них. В эту категорию попадают дефекты со статусом критической серьезности. Однако дефекты с низким уровнем серьезности также могут быть классифицированы как высокоприоритетные. Например, опечатка в названии компании на домашней странице приложения не оказывает технического влияния на программное обеспечение, но оказывает существенное влияние на бизнес, поэтому считается срочной.

#4. Дополнительные дефекты

#1. Отсутствующие дефекты

Отсутствующие дефекты возникают из-за требований, которые не были включены в продукт. Они также считаются несоответствиями спецификации проекта и обычно негативно сказываются на пользовательском опыте или качестве программного обеспечения.

#2. Неправильные дефекты

Неправильные дефекты — это те дефекты, которые удовлетворяют требованиям, но не должным образом. Это означает, что хотя функциональность достигается в соответствии с требованиями, но не соответствует ожиданиям пользователя.

#3. Дефекты регрессии

Дефект регрессии возникает, когда изменение кода вызывает непреднамеренное воздействие на независимую часть программного обеспечения.

Часто задаваемые вопросы — Типы программных ошибок< /h2>

Почему так важна правильная классификация дефектов?

Правильная классификация дефектов важна, поскольку она помогает эффективно использовать ресурсы и управлять ими, правильно приоритизировать дефекты и поддерживать качество программного продукта.

Команды тестирования программного обеспечения в различных организациях используют различные инструменты отслеживания дефектов, такие как Jira, для отслеживания дефектов и управления ими. Несмотря на то, что в этих инструментах есть несколько вариантов классификации дефектов по умолчанию, они не всегда могут наилучшим образом соответствовать конкретным потребностям организации.

Следовательно, важно сначала определить и понять типы дефектов программного обеспечения, которые наиболее важны для организации, а затем соответствующим образом настроить инструмент управления дефектами.

Правильная классификация дефектов также гарантирует, что команда разработчиков сможет сосредоточиться на критических дефектах и ​​исправить их до того, как они повлияют на конечных пользователей.

Кроме того, это также помогает определить потенциальные области улучшения в процессе разработки программного обеспечения, что может помочь предотвратить появление подобных дефектов в будущих выпусках.

Таким образом, отслеживание и устранение дефектов программного обеспечения может показаться утомительной и трудоемкой задачей. , правильное выполнение может существенно повлиять на качество конечного продукта.

Как найти лежащие в основе ошибки программного обеспечения?

Определение основной причины программной ошибки может быть сложной задачей даже для опытных разработчиков. Чтобы найти лежащие в основе программные ошибки, тестировщики должны применять систематический подход. В этот процесс входят различные этапы:

1) Репликация. Первым этапом является воспроизведение ошибки. Это включает в себя попытку воспроизвести тот же набор шагов, в котором возникла ошибка. Это поможет проверить, является ли ошибка реальной или нет.
2) Изоляция. После того, как ошибка воспроизведена, следующим шагом будет попытка ее изоляции. Это включает в себя выяснение того, что именно вызывает ошибку. Для этого тестировщики должны задать себе несколько вопросов, например:
– Какие входные данные вызывают ошибку?
– При каких различных условиях возникает ошибка?
– Каковы различные способы проявления ошибки?
3) Анализ: после Изолируя ошибку, следующим шагом будет ее анализ. Это включает в себя понимание того, почему возникает ошибка. Тестировщики должны задать себе несколько вопросов, таких как:
– Какова основная причина ошибки?
– Какими способами можно исправить ошибку?
– Какое исправление было бы наиболее эффективным? эффективно?
4) Отчет. После анализа ошибки следующим шагом является сообщение о ней. Это включает в себя создание отчета об ошибке, который включает всю соответствующую информацию об ошибке. Отчет должен быть четким и кратким, чтобы разработчики могли его легко понять.
5) Проверка. После сообщения об ошибке следующим шагом является проверка того, была ли она исправлена. Это включает в себя повторное тестирование программного обеспечения, чтобы убедиться, что ошибка все еще существует. Если ошибка исправлена, то тестер может подтвердить это и закрыть отчет об ошибке. Если ошибка все еще существует, тестировщик может повторно открыть отчет об ошибке.

Заключение

В индустрии программного обеспечения дефекты — неизбежная реальность. Однако благодаря тщательному анализу и пониманию их характера, серьезности и приоритета дефектами можно управлять, чтобы свести к минимуму их влияние на конечный продукт.

Задавая правильные вопросы и применяя правильные методы, тестировщики могут помочь обеспечить чтобы дефекты обнаруживались и исправлялись как можно раньше в процессе разработки.
TAG: qa

Источник

Как правильно описывать юзабилити-проблемы

24 октября 2017

24 Октябрь

Определение юзабилити-проблемы

В нашем понимании юзабилити-проблема — это такая особенность дизайна продукта, которая в определенном контексте не дает пользователю эффективно выполнить его задачу, затрудняя его деятельность или вызывая негативные эмоции. Под особенностью дизайна мы понимаем компоновку экранов, расположение и размеры элементов управления, структуру навигации, цветовые решения, тексты и реакцию системы на действия пользователя.

Такое определение хорошо тем, что позволяет отделить юзабилити-проблему от других видов проблем. Например, если респондент сказал, что не стал бы покупать определенный товар в этом интернет-магазине, потому что цены слишком высокие, то это не юзабилити-проблема, а проблема бизнеса. Как правило, мы не даем рекомендации по устранению подобных проблем, но все равно включаем их в дополнение к отчету.

Описание проблемы

Хорошее описание проблемы содержит две составляющие: описание поведения респондента, свидетельствующего о наличии проблемы (негативное событие), и описание особенности дизайна, с которой связаны затруднения. В плохом описании проблемы не хватает одной из этих составляющих, а иногда и обеих сразу.

Плохо Хорошо
Респонденты испытывают трудности с поиском истории операций, потому что надпись «История операций» плохо заметна. Почему: Не указано, как это проявляется в поведении пользователей. Невнятно описана особенность интерфейса, из-за которой возникает проблема. Ссылка на историю операций расположена в нетипичном месте: около левого края экрана, в отрыве от главного меню. Надпись «История операций» сделана мелким белым шрифтом, который трудно читается на сером фоне. Поэтому респонденты испытывают трудности с поиском истории операций: они ищут ее в главном меню и в правой колонке, но не замечают ее слева.
При выборе некоторых курсов всплывающее окно с курсом оказывается не полностью развернутым, при этом возможность развернуть его отсутствует. Почему: Из описания проблемы непонятно, чем это мешает пользователям. При выборе некоторых курсов всплывающее окно с курсом оказывается не полностью развернуто, при этом возможность развернуть его отсутствует. Часть контента, размещенного на странице курса, не умещается в окно. Чтобы прочитать расположенный на странице текст, респонденты вынуждены использовать горизонтальную прокрутку. После выполнения задания респонденты снижали оценку удовлетворенности и отмечали неудобство, связанное с горизонтальной прокруткой.
Респонденты не читают раздел о медицинской и юридической поддержке держателей премиальных карт. Почему: Если, не ознакомившись с информацией из этих разделов, пользователь все же смог достичь своей цели (выбрать нужную карту), то это не юзабилити-проблема. В противном случае нужно указать, чем плохо то, что пользователь не получил эту информацию. Респонденты не находят информацию о преимуществах премиальной карты, которая должна дать информацию, достаточную для принятия решения о покупке. Описание преимуществ находится в разделе под названием «Медицинская и юридическая поддержка», куда 5 из 8 респондентов решили не заходить, а 3 из 8 зашли и сразу вышли.

Хорошее описание проблемы всегда основано на наблюдении за поведением респондента, а не на том, что респондент говорит. Комментарии респондента могут сигнализировать о проблеме, но считать юзабилити-проблемой несоответствие продукта любым пожеланиям пользователя нельзя.

Плохо Хорошо
Один из пользователей хотел бы иметь возможность вводить старый пароль наряду с новым. Почему: Это не юзабилити-проблема. Не писать в отчете о субъективных высказываниях респондента, если они не иллюстрируют какую-то реально существующую проблему. Некоторые пожелания респондентов можно включать в отчет, если они представляют потенциальную ценность для заказчика.

Хорошее описание проблемы всегда конкретно. Даже если в нем используются общие слова вроде «непонятно», «неинформативно», «незаметно» и т.п., вслед за ними идет пояснение, раскрывающее их суть. Плохое описание проблемы сформулировано общими фразами без пояснений.

Плохо Хорошо
Название ссылки «Виртуальная карта MasterCard» непонятно для пользователей. Почему: Не указано, по каким признакам аналитик определил, что название ссылки непонятно; не указано, к каким последствиям это приводит. Неопытные респонденты, никогда не совершавшие покупки через Интернет, не знают, что такое «виртуальная карта». Пытаясь найти способ безопасно оплачивать покупки через интернет, они ищут ссылки с названием «Безопасные покупки», «Безопасная оплата через интернет», и, не найдя их, решают, что такой возможности у них нет. Название ссылки «Виртуальная карта MasterCard Virtual» непонятно для респондентов и не помогает им сделать правильный выбор.

Хорошее описание проблемы всегда объективно. Оно содержит только факты, которые наблюдал аналитик. В плохом описании проблемы есть субъективные оценки и ничем не подкрепленные эмоционально окрашенные слова.

Плохо Хорошо
Окно чата с консультантом раздражает пользователей. Почему: «Раздражает» — эмоционально окрашенное слово. Из описания проблемы непонятны признаки, по которым аналитик определил, что окно чата действительно раздражает пользователей и причина, по которой пользователи чувствуют раздражение. 5 респондентов из 8 отказались читать текст на странице, сказав, что им мешает окно чата с консультантом. Окно чата с консультантом мигает, издает звуки и закрывает часть текста, делая чтение практически невозможным.
Цветовое оформление системы мрачное и не нравится респондентам. Почему: «Мрачное» — ничем не подкрепленная оценка автора отчета. Все экраны системы имеют черный фон. Впервые увидев систему, 6 из 12 респондентов сообщили, что черный цвет их «напрягает». Неприятие черного цвета сохраняется на протяжении всего тестирования.

Главное правило: из хорошего описания проблемы читатель отчета должен понять, в чем ее суть и на каких основаниях аналитик сделал вывод о ее существовании.

Критичность и встречаемость

Список проблем, обнаруженных в ходе тестирования или экспертной оценки, может быть очень большим. Чтобы помочь клиенту понять, какие из них исправлять в первую очередь, наши аналитики присваивают им высокую, среднюю или низкую степень критичности. Высокая степень критичности назначается тем проблемам, из-за которых пользователь не может выполнить задачу или выполняет ее неверно. Проблемы средней критичности приводят к тому, что пользователь тратит на выполнение задачи много времени и сил, а его удовлетворенность от работы с сервисом падает. Наконец, проблемы низкой критичности не влияют на успешность выполнения задачи, но снижают удовлетворенность от работы с сервисом. Чтобы у аналитика и клиента было одинаковое понимание критичности проблем, его стоит согласовывать перед началом проекта.

Примеры проблем разной степени критичности:

Высокая Средняя Низкая
Респонденты не могли найти раздел «Счета». 3 из 8 респондентов сделали вывод, что у них нет счетов, а есть только карты. Респонденты не нашли раздел «Счета» и-за того, что он находится за линией прокрутки. Не найдя раздел, пользователи пытались взаимодействовать с картой, однако и там информацию не находили. Респондентам приходилось прицеливаться, вводя сумму оплаты телефона. При вводе суммы оплаты мобильной связи открывается стандартная символьная клавиатура, а кнопки с цифрами на ней мелкие, поэтому респондентам приходилось прилагать значительные усилия, чтобы не ошибиться: респонденты щурились, наклонялись ближе к экрану, а в некоторых случаях делали ошибки. 1 респондент из 8 принял пиктограмму «галочка в кружочке» на экране со статусом завершения операции за кнопку, закрывающую окно, и несколько раз пытался нажать на нее вместо кнопки «ОК». Пиктограмма крупная, обведена в кружок, выделена тенью, поэтому выглядит как интерактивный элемент. Кнопка «ОК», напротив, мелкая и сливается с фоном. Это спровоцировало пользователя совершить ошибку.

Для проблем, обнаруженных в ходе юзабилити-тестирования, мы указываем их встречаемость, то есть количество столкнувшихся с ней пользователей. Этот показатель дает основания для того, чтобы предположить, насколько проблема распространена среди пользователей в целом. Однако его нельзя переносить на всю целевую аудиторию продукта. Если на тестировании с проблемой столкнулись 2 респондента из 8, это не значит, что в жизни с ней столкнется 25% всех пользователей. Дело в том, что выборка участников тестирования очень маленькая. Восьми-десяти человек достаточно для того, чтобы найти почти все юзабилити-проблемы в интерфейсе, но недостаточно, чтобы делать статистически значимые выводы об их встречаемости. По этой же причине мы не указываем в процентах количество респондентов, столкнувшихся с проблемой или справившихся с задачей: для группы из 8-10 человек это будет некорректно.

Встречаемость не связана с критичностью. Например, если респондент не смог выполнить задание, потому что из-за технических ограничений системы не смог ввести двойную фамилию в соответствующее поле, то это проблема высокой степени критичности, хотя с ней столкнулся всего один человек из восьми участников тестирования.

Главное правило: ранжировать проблемы по критичности нужно, чтобы читатель отчета понимал, в какой последовательности их исправлять. Критичность проблемы указывает, насколько проблема мешает респонденту выполнять задачу, а не то, насколько часто она встречается.

Иллюстрации

Описание любой проблемы будет понятнее, если сопроводить его иллюстрацией того элемента интерфейса, о котором идет речь. Иллюстрации должны иметь короткую подпись, объясняющую, что на них изображено.

                        Скриншот проблемного элемента интерфейса с его описанием

Иногда бывает полезно показать проблемный элемент в контексте всего экрана. В таком случае его надо как-то выделить на скриншоте, например, обвести в рамку, чтобы читатель отчета понимал, куда смотреть. Особенно актуально это для иконок, кнопок, подсказок к полям и других мелких элементов интерфейса.

Проблемная область, о которой идет речь в описании проблемы обведена в рамку

Главное правило: иллюстрации нужны не для украшения отчета, а для того, чтобы облегчить читателю его понимание. Хорошая иллюстрация отображает ровно то, о чем идет речь в описании проблемы.

Рекомендации

Для того, чтобы отчет имел ценность, одного описания проблем недостаточно. Читатель отчета должен иметь представление о том, как их можно исправить. Поэтому UX-аналитики предлагают рекомендации по устранению найденных проблем.

Как правило, одной проблеме соответствует одна рекомендация. Чтобы читатель отчета принял ее, он должен понимать, как она устранит причину описанной проблемы. Поэтому рекомендацию необходимо делать максимально конкретной и не допускать абстракций вроде «улучшить расположение кнопки» или «исправить текст подсказки». Важно учитывать специфику заказчика: не стоит, например, предлагать банку решение, которое нарушит меры безопасности, вроде отказа от авторизации операций с помощью одноразового пароля. В случае, если наиболее очевидную рекомендацию, которая полностью устранила бы юзабилити-проблему, внедрить невозможно из-за технических, экономических или идеологических ограничений, аналитик должен уметь предложить альтернативу.

Плохо Хорошо
Сделать вход в интернет-банк более заметным. Почему: Непонятно, как именно это сделать. Сделать вход в интернет-банк более заметным. Например, вынести вход в Интернет-банк в отдельную панель в верхней правой части главной страницы. Панель должна называться «Вход в Интернет-банк» и иметь фон, отличающийся от общего фона страницы.

Многие клиенты отмечают, что для них в контексте рекомендаций очень полезными являются примеры удачных решений, реализованных в других интерфейсах (best practices). Это могут быть похожие интерфейсы прямых конкурентов, а могут быть продукты совсем из другой области с похожими элементами. Все это позволяет посмотреть на удачные способы решения существующих проблем.

Пример удачного решения к проблеме, описывающей затруднения пользователя при вводе номера мобильного. Слайд из индивидуального отчета для одного из участников нашего ежегодного отраслевого исследования удобства банковских мобильных приложений

Главное правило: из формулировки рекомендации читатель отчета должен понять, что конкретно он должен сделать, чтобы исправить проблему.

Заключение

Описание юзабилити-проблемы — навык, который приходит с опытом. Начинающие аналитики могут не заметить проблему или неправильно определить ее причину. Также они часто оказываются не в состоянии проработать пространство решений и сформулировать лучшее из них в виде рекомендации. Иногда специалисты делают описание проблемы слишком бедным, если считают, что суть проблемы очевидна. В нашей компании работу аналитиков контролируют ведущие специалисты и руководители проектов. Их задача — убедиться, что каждое описание проблемы в отчете корректно, объективно и понятно.

Хорошее описание юзабилити-проблемы содержит:

  1. описание поведения пользователя, сигнализирующего о проблеме (негативного события);
  2. описание особенностей интерфейса, из-за которых возникла проблема;
  3. указание на критичность и встречаемость проблемы;
  4. подписанную иллюстрацию с выделенной проблемной областью;
  5. рекомендацию по ее устранению.

1) описание проблемы пользователя;
2) описание особенностей интерфейса, из-за которых возникла проблема;
3) критичность и встречаемость проблемы;
4) подписанная иллюстрация с выделенной проблемной областью;
5) рекомендация. Слайд из индивидуального отчета для одного из участников нашего ежегодного отраслевого исследования удобства банковских мобильных приложений

Если описание проблемы неубедительно, то неважно, сколько человек приняло участие в тестировании или насколько опытный аналитик проводил оценку. Читатель отчета не поверит в объективность автора и не станет внедрять изложенные в нем рекомендации. Мы хотим, чтобы наши рекомендации шли в работу, а не в стол, поэтому во всех своих отчетах описываем проблемы так, как рассказали в этой статье.

Контакты

Источник

Артём Кузнецов разработал авторскую методику оценки эффективности взаимодействия пользователей с веб-сайтами, основанную на мировом опыте проектирования пользовательских интерфейсов и особенностях человеческого восприятия. Эта методика – удобный инструмент для бизнеса, позволяющий организациям оптимизировать собственные веб-сайты и проводить конкурентный анализ.

EPAK.059

Оценка эффективности взаимодействия

В процессе создания методики были проанализированы эвристики и руководства, предлагаемые всемирно известными экспертами в области юзабилити (Usability) и взаимодействия между человеком и компьютером (Human-Computer Interaction), материалы из области когнитивной психологии, связанные с особенностями человеческого восприятия и поведения. При этом мы обнаружили, что до настоящего момента не существовало как таковой исчерпывающей классификации правил проектирования пользовательских интерфейсов (либо ошибок проектирования). Каждый специалист предлагал свои перечни требований, носящие субъективный авторский характер и не поддающиеся систематизации и классификации.

В предлагаемом нами подходе оценка эффективности взаимодействия пользователей с веб-сайтами производится на основе разработанной нами системы классификации ошибок. В результате каждый веб-сайт получает оценку в баллах по каждой рассматриваемой категории, что удобно как для детального анализа отдельного веб-сайта, так и для сравнения веб-сайтов между собой.

Система классификации ошибок

Ошибки классифицируются по четырем основным категориям:

  • Элемент пользовательского интерфейса веб-сайта: (текст, графика, навигация, форма ввода или элемент управления);
  • Правило проектирования: (информационная ясность, визуальная ясность, корректность, единообразие, минимализм и обоснованность);
  • Аспект взаимодействия пользователей с веб-сайтом, на который влияет ошибка: (поддержка задач пользователя, ощущение контроля и свободы действий, обратная связь, предотвращение и обработка ошибок);
  • Уровень критичности выявленной ошибки (высокий, средний, низкий).

Элементы пользовательского интерфейса

Элементы интерфейса Описание
Тексты Любые словесные заголовки, пояснения, описания, контекстная справка.
Графика Картинки, флэш-ролики, видео-ролики, фон и другие элементы дизайна.
Навигация Меню навигации, навигационная панель, ссылки, “хлебные крошки”*, карта сайта и другие элементы навигации.
Формы Поля для текстового ввода, списки выбора (раскрывающиеся списки, радиогруппы, флажки), кнопки и другие элементы управления.

Правила проектирования

Правила проектирования Описание
Информационная ясность Пользователи должны ясно понимать смысл и предназначение всех текстов, графических элементов и элементов управления.
Визуальная ясность Создайте ясную структуру и иерархию всех визуальных элементов.
Поддерживайте визуальное сканирование интерфейса.
Минимизируйте визуальный шум.
Корректность Добейтесь корректности, работоспособности, правильности использования всех элементов пользовательского интерфейса.
Используйте все элементы по назначению.
Единообразие Соблюдайте единообразие терминов, концепций, визуального стиля.
Минимализм и обоснованность Каждый элемент интерфейса, который видит пользователь, должен доказать своё право на существование.

Аспекты взаимодействия пользователей с веб-сайтом

Аспекты взаимодействия Описание
Поддержка задач пользователя Фокусируйтесь на пользователях и их задачах.
Рассматривайте решение задач с точки зрения пользователей.
Обеспечьте решение наиболее важных задач в первую очередь.
Контроль и свобода Создайте и поддерживайте у пользователя ощущение контроля за ситуацией и свободы выбора способа решения задач
Обратная связь Обеспечьте своевременную информативную обратную связь.
Обработка ошибок Максимально содействуйте предотвращению и исправлению ошибок пользователя

Уровни критичности ошибок

Уровни Описание
Высокий С обнаруженной проблемой столкнутся все пользователи веб-сайта;
Эта проблема мешает выполнению основных задач пользователей;
В результате этой ошибки высок риск потерять клиента – пользователь уйдет с веб-сайта.
Средний С этой проблемой столкнутся многие пользователи;
Есть риск потерять часть клиентов.
Низкий Выявленная проблема возникает редко и/или не у всех пользователей,
Эта проблема не блокирует выполнение задач пользователей, но ухудшает потребительские качества веб-сайта.

Об экспертной оценке

Экспертная оценка – это удобный инструмент, который позволяет быстро и недорого оценить качество взаимодействия пользователей с веб-сайтом, выявить ошибки проектирования и наметить план по их устранению.

В качестве иллюстрации для отчета эксперт выбирает один персонаж (пользователя, обладающего определенными характеристиками, находящегося в определенных условиях), выполняющий один сценарий (определенную задачу) при взаимодействии с веб-сайтом.

По ходу выполнения сценария эксперт оценивает визуальные элементы структуры веб-сайта, с которыми пользователь сталкивается при выполнении задачи (все тексты, графику, формы ввода данных, навигацию) на соответствие правилам проектирования, а также качество взаимодействия (степень содействия в выполнении задачи пользователя, ощущение контроля за ситуацией и свободы выбора способа решения задач, информативность и своевременность обратной связи, предотвращение ошибок и помощь в их исправлении).

Каждая ошибка оценивается по уровню ее критичности, что можно взять за основу плана по их устранению (ошибки высокого уровня критичности необходимо устранить в первую очередь).

Кроме того в подробном отчёте эсперт приводит описание каждой ошибки, восприятие ее пользователем, классификацию ошибки по 4 категориям.

По ходу выполнения сценария эксперт также обращает внимание на следующие вопросы: 

  • Вызывает ли взаимодействие с веб-сайтом у пользователя ощущение доверия к компании, ее товарам и услугам?
  • Вызывает ли взаимодействие с веб-сайтом у пользователя ощущение надёжности и предсказуемости?
  • Вызывает ли взаимодействие с веб-сайтом у пользователя позитивные эмоции, ощущение своей успешности, которым он готов будет поделиться с друзьями, рекомендуя им воспользоваться данным веб-сайтом, либо негативные эмоции и ощущение собственной некомпетентности, неспособности быстро разобраться в том, как выполнить свою задачу, и желание поскорее покинуть этот веб-сайт.

Примечания

*«Хлебные крошки» (англ. Breadcrumbs) — элемент навигации по сайту, представляющий собой путь по сайту от его «корня» до текущей страницы, на которой находится пользователь.

Обычно представляет собой полосу в верхней части страницы примерно такого вида: “Главная страница → Раздел → Подраздел → Текущая страница” Все элементы, кроме последнего, обычно являются внутренними гиперссылками.
 

Источник

Время на прочтение
15 мин

Количество просмотров 30K

Привет, Хабр! Это Наталия Спрогис из UX-лаборатории Mail.Ru Group. Сегодня я расскажу о планировании и подготовке такого вида исследований, как юзабилити-тестирование. Статья рассчитана в первую очередь на неопытных исследователей и тех, кто собирается впервые проводить юзабилити-тестирование.

План тестирования — это с одной стороны набор заданий, вопросов и опросников, которые вы даете каждому респонденту, а с другой — методологическая база исследования: метрики и гипотезы, которые вы проверяете и фиксируете, выбранный инструментарий. Первая часть статьи посвящена как раз методологическим вопросам, лежащим в основе любого плана.

Точно ли нужно тестирование?

Для начала вы должны быть уверены, что на данном этапе проекту нужно именно юзабилити-тестирование. Поэтому уточняйте реальные цели обращения к вам проектной команды. Юзабилити-тестирования не всемогущи, и уже на старте нужно понимать, что подобное исследование реально может принести продукту. Сразу подготовьте проектную команду к тому, на какие вопросы вы сможете дать ответы, а на какие нет. У нас бывали случаи, когда мы либо предлагали заказчикам другой метод (например, сейчас лучше подойдут глубинные интервью или дневниковые исследования) или даже вообще рекомендовали отказаться от исследования, а вместо этого сделать сплит-тест.

Например, мы никогда не беремся в качественных исследованиях проверять «привлекательность» какой-то функции или варианта дизайна. Мы можем собрать с пользователей отзывы, но слишком велик риск, что на их ответы повлияет социальная желательность. Люди всегда склонны сказать, что стали бы пользоваться даже тем, чем пользоваться не будут. Да и маленький размер выборки не позволяет доверять таким ответам. Так, например, у нас был неудачный опыт тестирования игровых лендингов. Когда лендинг, который выбирали как наиболее привлекательный на тесте, при A/B тестировании отработал гораздо хуже.

Ряд ограничений есть и у тестирований прототипов и концепций. При планировании вы должны понимать, что реально можно «выжать» из этого теста. Очень здорово, когда у проекта есть возможность протестировать прототипы или дизайн до внедрения. Однако, чем менее детальный и рабочий прототип, чем выше уровень абстракции для респондента, тем меньше данных можно потенциально получить из данного теста. Лучше всего на тестировании прототипов выявляются проблемы нейминга и метафор иконок, т.е. все вопросы понятности. Возможность проверки чего-то сверх этого сильно зависит от сути проекта и детальности проработки прототипа.

Основа для составления сценария юзабилити-теста

Планирование тестирования начинается не с составления текста заданий, а с детальной проработки целей и вопросов исследования совместно с проектной командой. Основной для составления плана являются:

  • Важные сценарии. Это те пользовательские сценарии (или задачи, или юзкейсы), которые влияют на бизнес или связаны с целью тестирования. Даже если команда подозревает проблемы в конкретных местах, часто стоит проверить основные кейсы. При этом важными для теста могут считаться следующие сценарии:
    • наиболее частотные (например, отправка сообщения в мессенджере);
    • влияющие на бизнес-цели (например, работа с платежной формой);
    • связанные с обновлением (те, которые затронул редизайн или внедрение нового функционала).
  • Известные проблемы. Часто исследование должно дать ответ на причины бизнес-проблем сервиса. Например, продюсера беспокоит большой отток игроков после первого часа игры. А иногда проблемные места интерфейса уже известны команде, и вам необходимо собрать подробности и конкретику. Например, в службу поддержки часто обращаются с вопросами по форме оплаты.
  • Вопросы. У команды также могут быть вопросы для исследования. Например, замечают ли пользователи баннер, рекламирующий дополнительные услуги, или понятно ли назван определенный раздел.
  • Гипотезы. Это то, во что преобразуются известные проблемы и вопросы команды. Хорошо, если заказчик приходит к вам с готовыми гипотезами. Например, «Наши клиенты платят только с телефона с комиссией. Возможно, пользователи не видят выбора более выгодного способа оплаты». Если же гипотез нет, а есть только желание проверить проект абстрактно «на юзабилити», то ваша задача эти гипотезы сформулировать.

Подумайте совместно с проектной командой о тех местах, где пользователи ведут себя не так, как ожидается (если такая информация есть). Выясните, нет ли элементов дизайна, над которыми много спорили, и они могут оказаться проблемными. А также сделайте собственный аудит продукта в поисках потенциальных сложностей для пользователей, которые важно проверить на тесте. Все это поможет вам составить список тех элементов (заданий, вопросов, проверок), которые должны войти в итоговый сценарий.

Метод сбора данных

Вам важно продумать, каким образом вы будете собирать данные о происходящем во время теста для последующего анализа. Традиционно используются следующие варианты:

  • Наблюдение. Во время выполнения заданий респондент оставлен наедине с продуктом и ведет себя так, как считает нужным. Комментарии респондента собираются посредством опросников и общения с модератором после теста. Это наиболее «чистый» метод, обеспечивающий более естественное поведение респондента и возможность корректно измерить ряд метрик (например, время выполнения задания). Однако за кадром остается много полезных качественных данных. Видя то или иное поведение респондента, вы не можете понять, почему он так действует. Конечно, можно спросить об этом в конце теста, но, скорее всего, респондент будет хорошо помнить только последнее задание. Кроме того, за время выполнения заданий его мнение о системе может меняться, и вы получите только итоговую картину, а не первые впечатления.
  • Think Aloud (Мысли вслух). Долгое время этот метод использовался в юзабилити-тестированиях чаще всего. Якоб Нильсен в свое время называл его главным инструментом оценки юзабилити. Суть его в том, что вы просите респондента озвучивать все мысли, которые возникают у него при работе с интерфейсом и комментировать все свои действия. Это выглядит примерно так: «Сейчас я собираюсь добавить этот товар в корзину. А где же кнопка? А, вот она. Ой, я забыл посмотреть, какой там был цвет». Метод помогает вам понимать, почему пользователь ведет себя тем или иным образом, и какие эмоции вызывает у него текущее взаимодействие. Он дешев и прост, с ним справится даже неопытный исследователь. Однако у него есть свои недостатки. Во-первых, для людей не слишком естественно все время «думать вслух». Они будут часто замолкать, и вам придется им постоянно напоминать о том, что надо продолжать говорить. Во-вторых, задания при таком методе выполняются несколько дольше, чем в реальной жизни. Кроме того, часть респондентов начинает более вдумчиво пользоваться продуктом. Проговаривая причины своих действий, они стараются действовать более рационально, да и просто не хотят выглядеть идиотами. И вы можете не поймать какие-то интуитивные моменты поведения.
  • Активное вмешательство модератора. Данный метод идеален для тестирования концепций и прототипов. В этом случае модератор активно взаимодействует с пользователем во время выполнения заданий, выясняя в нужные моменты причины его поведения и задавая уточняющие вопросы. В некоторых случаях модератор даже может выдавать незапланированные задания, вытекающие из диалога. Данный метод позволяет собрать максимальное количество качественных данных. Однако его можно применять, только если вы доверяете профессионализму своего модератора. Некорректно сформулированные или не вовремя заданные вопросы могут очень сильно повлиять на поведение и впечатления респондента, и даже сделать результаты теста невалидными. Также при использовании этого метода невозможен замер практически никаких метрик.
  • Retrospective think aloud (Ретроспектива). Это комбинация первых двух методов. Пользователь сначала выполняет все задания без вмешательства, а потом перед ним проигрывается видеозапись его работы, и он комментирует свое поведение и отвечает на вопросы модератора. Главный недостаток метода — сильное увеличение времени тестирования. Однако бывают случаи, когда он оптимален. Например, один раз перед нами встала задача протестировать несколько видов мобов (игровых монстров) в одной RPG-игре. Естественно, мы не могли ни отвлекать респондентов вопросами, ни заставлять их комментировать свои действия во время боя. Это бы сделало невозможным игру, где нужна концентрация для победы. С другой стороны, вспомнить после серии схваток, заметил ли он загоревшуюся красным секиру у первой крысы, пользователь вряд ли смог бы. Поэтому в этом тесте мы воспользовались RTA. С каждым пользователем мы пересматривали их бои и обсуждали, какие эффекты монстров они заметили, и как их поняли.

Вам решать, какой метод вам больше подойдет. Однако мой совет: старайтесь продумать, как вы можете получить достаточно данных, сохранив максимальную естественность поведения респондента. Несмотря на простоту и универсальность метода «мысли вслух», который долгое время был самым популярным в юзабилити-тестированиях, мы стараемся все чаще заменять его на наблюдение. Если модератор видит интересное поведение респондента, он подождет, пока тот выполнит задачу и задаст вопрос после. Сразу после задания больше вероятность, что респондент помнит, почему он так сделал. Очень помогает в этом вопросе ай-трекер. Видя фокус текущего внимания респондента, вы можете, не задавая лишних вопросов, гораздо лучше понять его поведение. Ай-трекер вообще значительно улучшает качество модерирования, и эта его роль, на мой взгляд, не менее важна, чем возможность построения хитмапов.

Метрики

Метрики — это количественные показатели юзабилити. В результате тестирования вы всегда получаете набор найденных в интерфейсе проблем. Метрики же позволяют понять, насколько всё хорошо или плохо, а также сравнить с другим проектом или предыдущими версиями дизайна.

Какие бывают метрики

Все мы, конечно, помним, что по ISO 9241-11 основными характеристиками юзабилити являются эффективность, продуктивность и удовлетворенность. Для разных проектов могут быть актуальны разные метрики, но все они, так или иначе, завязаны на эти три характеристики. Я напишу о наиболее часто используемых показателях:

  • Успешность выполнения заданий. Можно использовать бинарный код: справился, не справился с заданием. Мы чаще придерживаемся подхода Нильсена и выделяем три вида оценок успешности:
    • справился с заданием практически без проблем — 100%;
    • столкнулся с проблемами, но выполнил задание самостоятельно — 50%;
    • не справился с заданием — 0%.

    То есть, если из 12 респондентов 4 справились с заданием легко, 6 с проблемами, а 2 потерпели фиаско, то средняя успешность по этому заданию будет 58%. Иногда вы будете сталкиваться с ситуацией, когда в среднюю группу попадают очень разные по степени «проблемности» респонденты. Например, один респондент мог мучиться над каждым полем формы, а второй лишь немного ошибиться в самом конце. Вы можете давать оценку на собственное усмотрение, в зависимости от того, что произошло на тесте. Например, 25%, если респондент только начал выполнять задание или 80%, если допустил незначительную ошибку. Однако, чтобы избежать слишком большой субъективности, продумайте шкалы оценок заранее, а не решайте для каждого респондента после теста. Также вам стоит подумать, что делать с ошибками. Например, вы дали задание, купить билеты в кино на проекте Кино Mail.Ru. Один из респондентов случайно купил билет не на завтра, а на сегодня, и не заметил этого. Он уверен, что справился с заданием и действительно имеет билет на руках. Однако его ошибка настолько критична, что приведет к тому, что он не попадет в кино, поэтому я бы поставила «0%», несмотря на то, что билет куплен. Процент успешности — это очень простая и наглядная метрика. И я рекомендую ее использовать, если у ваших заданий есть четкие цели. Взгляд на график успешности по заданиям позволяет быстро понять, где самые проблемные места интерфейса.

  • Время выполнения заданий. Эта метрика показательна только в сравнении. Как вы поймете, плохо или хорошо то, что пользователь выполняет задачу за 30 секунд? А вот то, что время сократилось по сравнению с предыдущей версией дизайна, уже хорошо. Или то, что регистрация на нашем проекте занимает меньше времени, чем у конкурентов. Есть интерфейсы, где сокращение времени на выполнение задач критично. Например, рабочий интерфейс сотрудника колл-центра. Однако не для всех задач эта метрика в принципе применима. Возьмем, к примеру, задачу подбора товара в интернет-магазине. Пользователи должны быстро находить фильтры и другие элементы интерфейса, связанные с поиском товаров, но сам процесс выбора будет занимать у них разное время. И это совершенно нормально. Женщины при выборе туфель бывают готовы отсмотреть 20 страниц выдачи. И это необязательно значит, что на первых страницах не было подходящих товаров или что они не видят фильтры. Часто им просто хочется увидеть все варианты.
  • Частотность проблем. Любой отчет о юзабилити-тестировании содержит список проблем, с которыми столкнулись респонденты. То, сколько респондентов столкнулось с проблемой, является показателем частотности данной проблемы в рамках теста. Данную метрику можно применять только в том случае, если ваши пользователи выполняли абсолютно одинаковые задания. Если же в тесте были вариации или задания были не четко сформулированы, а составлены на основании интервью, то посчитать частотность будет сложно. Нужно будет считать не только столкнувшихся, но и оценивать то, сколько респондентов могло бы столкнуться с проблемой (выполняли схожую задачу, заходили в тот же раздел). Тем не менее, это достаточно полезная характеристика для команды, позволяющая понять, какие проблемы стоит исправлять в первую очередь.
  • Субъективная удовлетворенность. Это субъективная оценка пользователем удобства/комфорта работы с системой. Выявляется она при помощи различных опросников, которые респонденты заполняют в процессе или после тестирования. Есть стандартные опросники. Например, System Usability Scale (SUS), Post-Study Usability Questionnaire (PSSUQ) или Game Experience Questionnaire (GEQ) для игр. Или вы можете составить собственный опросник. Подробнее о способах оценки удовлетворенности во второй части статьи.

Это далеко не единственные возможные метрики. Вот, например, список из 10 UX-метрик, которые выделяет Джеф Сауро. Но для вашего продукта метрики могут быть другими. Например, с какого уровня респонденты разбираются в правилах игры, сколько ошибок допускают при заполнении длинных форм и прочее.

Помните также о том, что решение использовать многие метрики накладывает на тестирование ряд ограничений. Респонденты должны действовать максимально естественно и быть поставлены в одинаковые условия. Поэтому хорошо бы обеспечить:

  • Единые точки старта. Одни и те же задания для разных респондентов должны начинаться с одной и той же точки интерфейса. Вы, например, можете после каждого задания просить респондентов вернуться на главную страницу.
  • Отсутствие вмешательств. Любое общение с модератором может, как повлиять на метрики эффективности, если модератор невольно подскажет что-то респонденту, так и увеличивает время выполнения задания.
  • Порядок заданий. Чтобы компенсировать влияние эффекта обучения в сравнительном тестировании, обязательно меняйте порядок знакомства со сравниваемыми продуктами для разных респондентов. Пусть половина начинает с вашего проекта, а половина — с конкурентного.
  • Критерии успешности. Заранее продумайте, какое именно поведение вы считаете успешным для данного задания. Допустимо ли, например, что при подборе товара в интернет магазине респондент не пользовался фильтрами.

Трактовка метрик

Используя метрики, помните, что классическое юзабилити-тестирование — это качественное исследование. И полученные вами метрики в первую очередь иллюстративны. Они дают общий взгляд на разные сценарии в продукте, позволяя увидеть болевые точки. Например, что настройки аккаунта вызывают больше сложностей, чем регистрация в системе. Они могут показать вам динамику изменений, если вы измеряете их регулярно. Т.е. метрики позволяют понять, что в новом дизайне выполнять задачу стали быстрее. Именно эти отношения гораздо более показательны и надежны, чем найденные абсолютные значения метрик.

Джеф Сауро, эксперт по статистике в UX-исследованиях, советует представлять метрики не средними значениями, а всегда считать доверительные интервалы. Это гораздо правильнее, особенно если в результатах респондентов присутствует разброс. Для этого можно воспользоваться его бесплатными онлайн-калькуляторами: для успешностей и для времени выполнения заданий. Также не обойтись без статистической обработки и при сравнении результатов.

Когда нужны метрики

Далеко не каждый отчет о юзабилити-тестировании содержит метрики. Их сбор и анализ требует времени и накладывает ряд ограничений на методы проведения теста. В каких же случаях они действительно нужны:

  • Доказать. Часто, особенно в крупных компаниях, необходимость внесения в продукт изменений необходимо доказать. Цифры наглядны, понятны и привычны для лиц, принимающих решения. Поэтому когда вы показываете, что 10 из 12 респондентов не смогли оплатить товар, или что регистрация в системе в среднем занимает в два раза больше, чем у конкурентов, это придает результатам исследования больший вес.
  • Сравнить. Если вы сравниваете свой продукт с другими на рынке, вам также не обойтись без метрик. Иначе вы сможете увидеть достоинства и недостатки разных проектов, но не сможете оценить, какое место ваш продукт занимает среди них.
  • Увидеть изменения. Метрики хороши для регулярных тестов одного и того же продукта после внесения изменений. Они позволяют увидеть прогресс после редизайна, обратить внимание на те места, которые остались без улучшений. Использовать эти цифры вы можете опять же, как доказательную базу для руководства, показывающую вес вложений в редизайн. Или просто для понимания того, что вы достигли результатов и двигаетесь в нужном направлении.
  • Иллюстрировать, сделать акцент. Цифры хорошо помогают иллюстрировать важные проблемы. Иногда даже если мы не используем метрики во всех заданиях, мы считаем их для наиболее ярких и важных моментов теста.

Тем не менее, мы используем метрики далеко не в каждом тесте. Можно обойтись без них, если исследователь плотно работает с командой проекта, есть внутреннее доверие и команда достаточно зрелая, чтобы грамотно расставить приоритеты решения проблем.

Способ фиксации данных

Казалось бы, чем плох блокнотик и ручка или просто открытый документ Word? В современном Agile мире разработки UX-исследователи должны стараться максимально быстро выдавать команде результаты своих наблюдений. Чтобы оптимизировать время на анализ, хорошо заранее заготовить шаблон для ввода ваших заметок в процессе теста. Мы пробовали делать это в специализированном ПО (например, Noldus Observer или Morae Manager), но на практике наиболее гибкими и универсальными оказались таблицы. Заранее разметьте в таблице вопросы, которые точно планируете задавать, места под ввод проблем, обнаруженных в различных заданиях, а также гипотезы (вы будете помечать, подтвердилась она или нет на каждом респонденте). Наши таблички выглядят подобным образом:

Респондент 1 Респондент 2 Респондент 3 Респондент 4
Задание 1
Заметил ли функцию А?
В каком месте искал возможность Б?
Проблемы и наблюдения по заданию
…

Вы также можете воспользоваться:

  • Usability Test Data Logger от Userfocus. Кастомизируемый шаблон Excel для ввода наблюдений по каждому респонденту. Есть встроенный таймер для измерения времени выполнения заданий и автоматически генерируемые графики времени и успешности.
  • Rainbow Spreadsheet от Томера Шерона из Google. Наглядная таблица для совместной работы исследователя и команды. По ссылке статья с описанием метода, там же есть ссылка на Google-таблицу с шаблоном.

С опытом большинство записей можно сделать прямо во время теста. Если не успели вовремя, лучше записать все что помните сразу после теста. Потому что если будете возвращаться к анализу через несколько дней, скорее всего, придется пересмотреть видео и потратить гораздо больше времени.

Подготовка к тестированию

Помимо метода, метрик и непосредственно протокола тестирования, вам необходимо определиться со следующим:

  • Формат общения с модератором. Модератор может находиться в одной комнате с участником тестирования, в этом случае ему будет легко вовремя задавать вопросы. Однако присутствие модератора может влиять на респондента. Он может начать задавать вопросы модератору, провоцируя того явно или неявно подсказать ему. По возможности, мы стараемся хотя бы на часть теста оставлять респондента наедине с продуктом. Так его поведение становится более раскованным и естественным. А чтобы не бегать туда-сюда, если что-то пойдет не так, вы можете оставить включенным любой мессенджер с аудиосвязью, чтобы модератор имел возможность связаться с респондентом из наблюдательной комнаты.
  • Способ постановки заданий. Задания может озвучивать модератор. Но в этом случае, несмотря на единый протокол тестирования, каждый раз текст задания может произноситься немного по-разному. Особенно это актуально, если тест ведет несколько модераторов. Иногда, даже небольшие различия в формулировках могут поставить респондентов в разные начальные условия. Чтобы избежать этой проблемы, можно либо «надрессировать» модераторов всегда читать тексты задания, либо выдавать задания респондентам на листочках или на экране. Различие формулировок не проблема для вас, если вы используете гибкий сценарий, при котором задания формулируются в процессе теста, на основании интервью с модератором.

    Кроме того, интересным может быть вариант использования средств продукта для постановки заданий. Так, например, при тестировании ICQ задания респонденты получали через окно чата с модератором, а при тестировании Почты Mail.Ru они приходили в письмах. Такой способ постановки заданий был максимально естественен для этих проектов, а еще мы многократно обкатывали базовые сценарии переписки.

  • Создание естественного контекста. Даже если мы говорим о лабораторных исследованиях, подумайте, как вы можете приблизить использование продукта на тесте к реальным условиям. Например, если вы тестируете мобильные устройства, как респонденты будут держать их? Для хорошего изображения на видеозаписи лучше, когда телефон или планшет фиксированы на стенде или лежат на столе. Однако это не дает понять, все ли зоны доступны и удобны для нажатия. Ведь телефоны часто держат одной рукой, а с планшетами лежат на диване. Также стоит подумать об обстановке, в которой будет использоваться продукт: есть ли отвлечения, шумно ли, хороший ли интернет. Все это можно пытаться имитировать в лаборатории.
  • План теста для заказчика. Это также важный этап подготовки, так как он вовлекает проектную команду. Вы можете не посвящать заказчика во все методологические особенности теста (как будете общаться с респондентом, фиксировать данные и прочее). Но обязательно покажите ему, какие будут задания, и что вы на них собираетесь проверять. Возможно, вы не учли какие-то особенности проекта, а может быть, у команды проекта появятся какие-то дополнительные идеи и гипотезы. У нас обычно получается подобная табличка:
    Текст задания Что проверяем
    «Вспомните, какую бытовую технику вы недавно покупали. Какие были критерии выбора? Давайте попробуем при помощи этого сайта подобрать вам что-то по этим же критериям»
    • Находят ли правильную категорию
    • Заметность фильтров
    • Есть ли сложности с фильтром по цене
    • Достаточность фильтров
    • И т.д.
  • План отчёта. Естественно, отчет пишется по результатам исследования. Но очень хорошая практика — составлять план отчёта еще до проведения тестов, основываясь на целях и задачах исследования. Имея такой план перед глазами, вы сможете проверить свой сценарий на полноту, а также подготовить наиболее удобные формы для фиксации данных для последующего анализа. А возможно, вы решите, что вам не нужен отчёт, а достаточно общего файла с наблюдениями для вас и команды. А если вы мотивируете команду заполнять его вместе с вами, будет совсем здорово.

Заключение

Конечно, вы можете просто «дать попользоваться продуктом» своему другу и наблюдать за тем, какие сложности у него возникнут. Но грамотно составленный сценарий позволит вам не упустить важные проблемы и не натолкнуть случайно респондента на нужные вам ответы. Ведь юзабилити-тестирование — это упрощенный эксперимент, а у любого эксперимента важна предварительная подготовка. В следующей части статьи я расскажу о составлении протокола тестирования: с чего начать тест, какие вопросы задать респонденту, как сформулировать задания и как собрать итоговые впечатления.

Источник

Возможно, вам также будет интересно:

  • Очень большой текст с ошибками
  • Оцени упражнение сообщить об ошибке далее пропустить
  • Очень большие ошибки в русском языке
  • Оцени свою работу сколько заданий выполнено какие допущены ошибки
  • Очевидный вопрос это ошибка или нет

    • Понравилась статья? Поделить с друзьями:
    0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии