Программное обеспечение вычислительной техники и автоматизированных систем - РГР и ЛР (Дергачёв) / Тестирование интерфейсов

Методики тестирования

В настоящее время меньшее внимание уделяется результатам, основанным на фактических данных, акцент делается на интерпретации этих результатов; можно видеть что в сравнении с сухими цифрами большую важность приобретают другие моменты, наблюдаемые в процессе тестирования. В частности, очень многие тестирования проводятся на базе записи «мыслей вслух» в сочетании с какой-либо разновидностью измерения производительности. Измерения производительности до сих пор обладают определенной полезностью для исследований, однако информация, получаемая при записи «мыслей вслух», способна гораздо быстрее отражаться на изменениях в продукте, поскольку она не нуждается в предварительном обобщении и статистическом анализе. Метод фокусных групп Проверка посредством наблюдения за пользователем Мыслим вслух Проверка качества восприятия Измерение производительности Карточная сортировка Метод фокусных групп Метод фокусных групп заключается в опросе специально отобранной группы пользователей. В исследование, которое обычно продолжается около 2 часов, вовлекается от 6 до 9 пользователей. Основное достоинство фокусных групп состоит в том, что они позволяют выявлять спонтанные реакции и идеи и оценивать отношение к этим идеям группы в целом. Как правило, участники группы воспринимают происходящее как относительно свободный неструктурированный процесс, но ведущий группы должен иметь предварительный сценарий работы, вытекающий из целей исследования, и следить, чтобы групповая дискуссия не выходила из русла обсуждаемой проблемы. Кроме того, необходимо добиваться равного участия в дискуссии всех членов группы. Достаточно часто бывает, что в группе выделяется лидер, доминирующий над остальными участниками. Такие ситуации мешают свободному выражению мыслей и идей остальных членов группы и также нуждаются в коррекции. Результаты работы фокусной группы заносятся в специальный протокол для дальнейшей обработки. Сбор детальной информации при этом методе затруднен из-за относительной стихийности группового процесса, поэтому рекомендуется проводить несколько фокусных групп, состоящих из репрезентативных пользователей. Метод фокусных групп подходит для того, чтобы быстро поучить диапазон мнений и оценок пользователей по поводу тех или иных вещей. Он очень полезен для определения, в самом общем виде, потребностей и предпочтений вашей аудитории. Он подходит для проверки того, насколько актуальна и востребована программа и насколько его «ценное предложение» привлекательно для пользователей. Кроме того, это хороший способ для подбора названий функции и опций, а также выяснения, что люди думают о ваших конкурентах. Однако метод фокусных групп не позволяет определить, как работает ваша программа и самое главное как ее можно улучшить. С помощью этого метода вы можете узнавать те вещи, которые нужно знать на ранних этапах, еще до начала непосредственной разработки. Конечно, этот метод можно применять и позже, например, для уточнения деталей или при пользовательском тестировании. Но метод фокусных групп не может вам показать, насколько людям удобно и легко пользоваться вашей программой, поэтому нельзя путать этот метод с другим – юзабилити-тестирование. Проверка посредством наблюдения за пользователем Один из самых простых видов тестирования. Пользователю дается задание, он его выполняет, его действия фиксируются для дальнейшего анализа на камеру, либо какой-нибудь программой записи состояния экрана (например, Lotus ScreenCam). Метод исключительно полезен для выявления неоднозначности элементов интерфейса. Поскольку каждая неоднозначность приводит к пользовательской ошибке, а каждая такая ошибка фиксируется, обнаружить их при просмотре записанного материала очень легко. В последствии можно посчитать количество ошибок и сделать соответствующие выводы. Кроме того, если замерять время выполнения задания (секундомером), можно оценить производительность работы пользователей. Мыслим вслух Запись или протоколирование «мыслей вслух» – очень распространённая методика, применяемая при юзабилити-тестированиях. В течение теста, пока участник выполняет то или иное задание в рамках своего сценария, экспериментатор просит участника вербализовать его мысли, чувства и мнения, возникающие в процессе взаимодействия с продуктом. Комментарии записываются на диктофон или камеру, а затем анализируются. Как производится протоколирование В первую очередь необходимо предоставить участнику сам тестируемый продукт (или прототип его интерфейса) и сценарий – список заданий, которые ему необходимо выполнить. Попросите участников в процессе выполнения заданий подробно сообщать всё, что возникает у них в голове, пока они работают с интерфейсом продукта. «Мысли вслух» позволяют вам понять, как пользователь подходит к интерфейсу и какими соображениями он руководствуется, используя этот интерфейс. Если последовательность шагов, которую пользователю потребуется пройти для выполнения задания, оказывается отличной от той, что он себе представлял, возможно, интерфейс излишне вычурный. Основную выгоду из использования данной методики вы извлекаете, получая лучшее понимание ментальной модели пользователя и его взаимодействия с продуктом (понимая, что в действительности происходит у него в голове), однако, вы можете обнаружить ещё некоторые полезные моменты. К примеру, терминология, которой участник пользуется для объяснения идеи или функции, может быть внедрена в дизайн продукта и использована при проектировании, или, по меньшей мере, при написании документации. Когда стоит использовать данную методику Используйте этот метод на любой стадии разработки. «Мысли вслух» – недорогой путь получения хорошей качественной ответной реакции в течение тестирования. Проверка качества восприятия Тест позволяет определить, насколько легко интерфейсу обучиться. Поскольку существует разница между понятиями видеть и смотреть, а запоминается только то, что увидено, необходимо обладать уверенностью в том, что пользователь увидит если не всё, то уж хотя бы всё необходимое. А значит – запомнит, благодаря чему в будущем ему не придется обшаривать меню в поисках «чего-то такого, что, я точно знаю, где-то здесь есть». Сама по себе методика проста. Пользователю даётся задание, связанное с каким-либо отдельным диалоговым окном. Пользователь его выполняет. Через несколько минут пользователя просят нарисовать (пускай даже грубо и некрасиво) только что виденное им окно. После чего рисунок сравнивается с оригиналом. Разумеется, пользователь запоминает только то, что ему кажется актуальным в процессе работы с окном (плюс еще что-нибудь за того, что ему показалось интересным, да и то не всегда). Это один из тех редких случаев, когда срабатывает ограничение на объем кратковременной памяти, так что количество запомнившихся элементов управления не может быть выше порога. Пример проверки качества восприятия. Пользователь, которому нужно сменить шрифт абзаца на Arial из всего диалогового окна выбора шрифта в MS Word запоминает только часть элементов управления. Разумеется, он помнит, что помимо них были и другие, но точно вспомнить остальные элементы он, как правило, не может. Измерение производительности Некоторые юзабилити-тестирования ориентированы на получение чётких, количественных данных. В большинстве случаев эти данные представлены в форме метрик производительности, – сколько времени занимает выделение блока текста с помощью клавиатуры, мыши или трекбола? Как расположение клавиши Backspace влияет на частоту появления ошибок? Часто в процессе проектирования продукта ориентируются на достижение подобных целей. Цели в таком случае могут формулироваться в виде условий, например: «пользователь должен иметь возможность установить соединение с Интернет без ошибок или по бесплатной линии» или «Основная задача должна выполняться за время не превышающее часа 75 процентами пользователей». Эти условия устанавливаются на базе изначального тестирования предыдущей версии или продуктов-конкурентов. Должна быть поставлена цель, определены задачи, спроектированы тесты и непосредственно поставлен эксперимент. При измерениях производительности необходимо учитывать следующие моменты: Критерий выполнения задачи должен быть количественно определён Как оговаривалось ранее, задачи должны быть выражены в величинах, подлежащих определению, однако, для измерений производительности необходимо, чтобы они имели чёткий критерий в виде численно-выраженой величины. К примеру, вы можете задаться вопросом: «что более эффективно, кнопки на управляющей панели или «горячие клавиши». Ответ на сформулированный таким образом вопрос можно получить при помощи тестирования двух интерфейсов, одного, ориентированного на «горячие клавиши», и второго, основанного на панелях с кнопками. Производительность каждого пользователя определяется при помощи замеров времени, потраченного им на выполнение каждого задания и при помощи журнала допущенных пользователем ошибок. Структура эксперимента действительно важна Поскольку задачей тестов с измерением производительности является получение корректных количественных данных, структура эксперимента также должна быть корректной. Количественные тесты предполагают, что изменения в независимых переменных (таких, как наличие кнопок на панели или доступность «горячих клавиш») отразятся на зависимых (в нашем случае, на времени, затрачиваемом на запуск команд, использующих одну или две опции). Это влияние называется экспериментальным эффектом. Тем не менее, если дополнительные факторы будут внесены в структуру теста, этот эффект может быть искажен и эксперимент окажется статистически недостоверен, поскольку будет испорчен влиянием неучтенных факторов. Эксперимент должен быть спроектирован с учётом возникновения возможных искажающих факторов, чтобы устранить всё, что может повлиять на экспериментальный эффект. Данные не сообщают всех подробностей По некоторым причинам тестирования, исключительно ориентированные на сбор данных, касающихся измерения производительности, не так распространены, как это могло бы показаться. Такие тестирования требуют очень скрупулезно спроектированных тестов и значительных ресурсов. У большинства компаний на такие тестирования нет ни времени, ни денег. Кроме этого, масштаб получаемых с их помощью результатов зачастую очень невелик. Действительно ли так важно, что использование «горячих клавиш» вместо панелей с кнопками даёт выигрыш в полсекунды? Возможно важно, если вы разрабатываете программное обеспечение для центров обработки заказов, и экономия половины секунды на каждом звонке, помноженная на тысячи операторов по всей стране, может сократить годовые расходы на миллионы долларов. Но для большинства офисных приложений экономия в половину секунды не представляет реальной важности. Когда стоит использовать данную методику Измерение производительности используется на начальных этапах для задания контрольных замеров для процесса проектирования. Также оно используется на протяжении всего проектирования для измерения того, насколько далеко удалось продвинуться относительно этих контрольных замеров. Карточная сортировка Карточная сортировка — это классификационный метод, при котором пользователи сортируют различные элементы разрабатываемого ПП по нескольким категориям. Для проведения карточной сортировки создается список параметров, которые предполагается подвергнуть классификации, после чего каждый из указанных параметров выписывается на отдельной карточке. Карточки предъявляются пользователям, которых инструктируют сгруппировать наиболее логичным, по их мнению, образом. Полученную в результате карточной сортировки информацию используют для организации пользовательского интерфейса.

Контрольные списки

Контрольные листы помогают удостовериться в том, что веб-сайт выполнен с учетом принципов функциональности дизайна. Обычно их используют на заключительной стадии работы в дополнение к экспертным методам для того, чтобы структурировать экспертные оценки по каким-то определенным признакам. Нельзя получить хороший результат, если не определены критерии качества и завершенности проекта. Контрольный список (или «чеклист») это документ с перечнем требований к выполняемой работе. Каждому свойству готовой работы присваивается весовой коэффициент (например, "отсутствие грамматических ошибок — 4%"), а работа считается выполненной, если сумма коэффициентов больше близкого к сотне числа (например, 97%). Благодаря этому исполнителю не требуется волноваться по поводу качества работы — от него требуется только соблюдать все изложенные в списке требования, а заказчик может быстро проверить качество выполнения, выборочно проверив отдельные параграфы. Наличие контрольного списка увеличивает производительность работы, так как не нужно тратить время на размышления двух тематик — что нужно вообще сделать и что нужно ещё сделать. Ответ на оба вопроса уже содержится в контрольном списке. Использование контрольных списков является эффективным и экономичным средством повышения уровня качества программных продуктов. Он позволяет глобально оценить состояние проекта, тратя на это очень мало времени. Естественно, что в каждом конкретном случае необходимо разрабатывать свой собственный контрольный список, поскольку он должен учитывать специфику разрабатываемого программного средства и возможности средств разработки. Поэтому контрольные списки представленные ниже является скорее шаблоном, в котором представлены основные разделы. Контрольный список интерфейса ПО Окна При проектировании было учтено, при каком разрешении, а так же размере монитора и шрифтов будут работать пользователи. Заголовки Заголовки короткие и адекватные содержимому окна. Заголовки соответствуют названиям элементов, при помощи которых окна были вызваны. Если окно вызывается элементом, не имеющим явного названия, в заголовке окна отражается название экранной формы. Дизайн окна Тип окна (модальное, немодальное, возможность минимизации/максимизации) был выбран осознанно, в соответствии с задачами пользователей. Управляющие и информационные элементы расположены достаточно далеко друг от друга (не менее 7 DLU). Информация в окне адекватно сгруппирована (связанные элементы объединены в группы). Кнопки находятся в секции, на которую они оказывают непосредственное воздействие. Терминационные кнопки (управляющие окном) расположены либо снизу в ряд либо справа в колонку. Переход от элемента к элементу внутри окна, осуществляется сверху вниз слева направо. Диалоговые окна В диалоговых окнах отсутствуют меню или инструментальные панели. Диалоговые окна открываются не в центре экрана, а в центре текущего действия пользователя. Меню Пункты главного меню Пункты меню имеют адекватные названия. Первая буква в названии пунктов заглавная. Все пункты первого уровня активизируют выпадающее меню. Каждому пункту меню назначены общепринятые горячие клавиши (выделены подчеркиванием). Раскрывающиеся меню и элементы основного меню второго уровня Все элементы начинаются с заглавной буквы. Если в меню используются пиктограммы, они расположены слева от названия пункта меню. Все списки содержат более одного элемента. Высота меню не превышает размер экрана (меню не нужно прокручивать). Пункты меню адекватно сгруппированы. Осмысленно использованы разделители в меню. Пункты меню расположены в порядке связанности выполняемых функций, частоте использования, важности. Используются не более двух подуровней меню. Каждый пункт меню имеет соответствующую горячую клавишу. Название пункта меню соответствует названию вызываемого окна. Пункты меню, открывающие диалоговые окна, обозначены в конце многоточием (…). Недоступные пункты меню обозначены серым цветом шрифта. Всплывающие меню Каждому пункту всплывающего меню соответствует аналогичный пункт в основном меню. Инструментальные панели Каждому элементу инструментальной панели соответствует всплывающая подсказка. Элементы упорядочены и сгруппированы в соответствии с задачами пользователей. Для стандартных действий используются общепринятые графические элементы.  Управляющие элементы Переключатели (Check boxes) В одном окне используется не более 10 переключателей. Переключатели сгруппированы и каждой группе присвоено название. Внутри группы переключатели расположены строго вертикально. Переключатели не применяются для частого, оперативного использования. В названиях используется только позитивная, утвердительная форма. Командные кнопки Кнопки имеют краткие и ясные названия. В каждом диалоге используется не более 6 кнопок. Кнопки, выполняющие в разных диалогах идентичные функции, имеют одинаковые названия. Типовые кнопки имеют общепринятые названия и общепринятые горячие клавиши. Кнопки, вызывающие продолжение диалога в вложенных формах, обозначены многоточием (…). Недоступные кнопки имеют соответствующие атрибуты (серый цвет шрифта и т.п.). Опасные для пользователя кнопки не являются кнопками по умолчанию Редактируемые поля со списком (Сombo Box) Имеют функцию авто-выбора. Раскрывающиеся списки Высота выводимого на экран списка ограничена 3-8 элементами. Если список содержит более 50 элементов, используется фильтр или режим поиска. Если все элементы не умещаются в одном фрагменте списка, автоматически появляется полоса прокрутки. Группы элементов Каждая группа имеет осмысленное название, помимо рамки отделена от других групп и элементов свободным пространством. Подписи (Labels) Все элементы имеют подписи. Учтена возможность увеличения (уменьшения) длины подписей при использовании large fonts (small fonts). Подписи выровнены по левому краю поля (если они находятся над полем). Подписи расположены по середине высоты поля (если название находится с боку). Если элемент недоступен, подпись отображается серым шрифтом. Списки Если список содержит более 50 элементов, используется фильтр или режим поиска. Высота ограничена 3-8 элементами. Если все элементы не умещаются, автоматически появляется полоса прокрутки. Кнопки выбора (Option Buttons или Radio Buttons) В одной группе используется не более 6 кнопок. В пределах группы кнопки расположены по вертикали. Нет состояния, когда ни одна кнопка не выбрана. Последовательность расположения кнопок в группе учитывает частоту использования. Вкладки (Tabs) Названия вкладок выровнены по центру. Каждой вкладке присвоено осмысленное название. Количество рядов закладок не превышает двух. Все связанные между собой данные находятся внутри одной закладки. Кнопки, относящиеся ко всему блоку закладок, расположены за пределами блока закладок. Текстовые поля ввода (Text Box or Edit Field) Для недоступных полей используются серый цвет (название, текст и фон поля). Высота всех текстовых полей в окне одинакова. Содержимое полей выровнено по левому краю, за исключением полей с числовыми значением (напр., для вывода денежных сумм). Длина поля не меньше длины вводимых в него данных. Если в поле вводится численное значение границы диапазона выводятся во всплывающей подсказке. Порядок табуляции фокуса ввода При открытии окна фокус попадает на элемент внутри окна. Схема табуляции соответствует очередности заполнения полей (слева направо, сверху вниз). Командные кнопки включены в табуляцию. Невидимые и недоступные элементы исключены из схемы табуляции. Пиктограммы Направление теней во всех пиктограммах одинаково: слева сверху. Взаимодействие с пользователем Система, завершив какую-либо длительную операцию, пищит через встроенный динамик компьютера. Цифры, предназначенные для сравнения либо для копирования в буфер обмена, выводятся непропорциональным шрифтом. Контрольный список Веб-интерфейса Показывает ли ваш сайт возможность воспринять действия пользователя? По преимуществу это касается активных (изменяющих свой вид в зависимости от положения курсора) кнопок. Всегда ли вы предупреждаете пользователя о неприятных последствиях его действий? В основном вопрос касается апплетов, но также затрагивает необходимость предупреждать пользователя о длительном ожидании загрузки станицы (если она богата графикой). Постоянно ли доступны пользователю все управляющие элементы сайта? К примеру, постоянно ли доступна пользователю вся необходимая система навигации? Вопрос относительный, т.к. единственный на данное время способ сделать что-нибудь постоянно видимым — это кадры, которые сами по себе нехороши. Корректно ли сайт печатается? Очень важный вопрос для страниц, объёмом больших, нежели 2Kb (их чаще печатают). Надо проверить, как печатаются страницы на монохромных и цветных принтерах. Если вы режете большие тексты на множество отдельных страниц, вы должны предоставить пользователю возможность открыть и напечатать весь текст одной страницей (причём без красот экранного дизайна). Если глубина вашего сайта больше 5 страниц, предоставляете ли вы возможность текстового поиска? Отсутствуют ли страницы с дизайном, отличающимся от актуального в настоящее время? Есть ли страницы с содержанием, стилистически отличающегося от обычного? Вопрос, по преимуществу, об оставшихся от прежних версий сайта страницах, которые не были переделаны в отношении дизайна либо стилистики текста. Всегда ли корректно работает кнопка Back браузера? Некоторые страницы, переданные по шифрующему протоколу, не могут быть взяты браузером из кэша и их требуется загружать заново (в лучшем случае пользователю нужно самому нажать кнопку Refresh, в худшем — производить более сложные и неочевидные действия). При повторной загрузке таких страниц может также слететь установленная в браузере кодировка (и весь русский текст превратится в тарабарщину). Избегайте делать такие страницы. Также, если у вас есть страницы с формами ввода, добейтесь того, чтобы вернувшийся на эту страницу пользователь (не важно, копкой ли Back, либо благодаря гиперссылке) нашел её со всеми своими установками (это очень экономит время, если нужно вернуться и что-нибудь поправить). Частично этот вопрос перекликается с последующим. Видимы ли все изменения в содержании и дизайне, произошедшие из-за действий пользователя? Например, если пользователь установил какой-нибудь переключатель, то во всех страницах, демонстрирующих результаты его действий, должно быть показано, что этот переключатель установлен в соответственное положение. Принципом, послужившим основой этого вопроса, является утверждение, гласящее, что любое действие пользователя должно быть отражено интерфейсом. Хорошо ли выглядит ваш сайт на низкокачественных мониторах? Хорошо ли он выглядит на монохромных мониторах, шестнадцатицветных или показывающих только оттенки серого? Если вы используете какое-либо цветовое кодирование информации, то имеются ли иные способы индикации (текст, графическое воплощение и т.д.)? Всегда ли вы используете изображения для иллюстрации (индикации) команд, возможностей либо параметров вашего сайта (если это вообще возможно)? Использует ли графика метафоры, известные пользователю по обычной жизни? Лишаете ли вы её несущественных подробностей, без пользы усложняющих её восприятие? Вообще говоря, нет никакого смысла как в абстрактных пиктограммах, так и в пиктограммах, инспирированных компьютером. Место хранения файлов можно обозначить изображением жёсткого диска, но при этом от пользователя будет требоваться знание того, как этот диск выглядит. Что неправильно, т.к. от пользователя вообще нельзя ничего требовать. Лучше нарисовать шкаф. Если вы используете более или менее трёхмерные изображения, то все ли они обладают одинаково направленной тенью? Это одна из самых распространённых дизайнерских ошибок. Так как сайт представляет собой единое пространство, множество разных источников света сбивает с толку (и смешно выглядит). Избегаете ли вы использовать цвет в значимых областях страницы, если этого не требует необходимость выделять важную информацию? Этот вопрос не относится к общему фону страницы. Используете ли вы яркие (насыщенные) цвета только в небольших областях и только при необходимости? Используете ли вы только нейтральные фоновые цвета? Если вы используете тёмный или чёрный фон, установлено ли жирное начертание текста по умолчанию (на большинстве низкокачественных мониторов, которые и составляют большинство, тонкий светлый текст на тёмном фоне проявляет несведение лучей и от этого выглядит сильно размытым)? Уверены ли вы, что ваш сайт приемлемо выглядит с любым размером системного шрифта? Многие пользователи устанавливают его размер на максимальный, отчего практически любой дизайн разваливается (лишить их такой возможности можно с помощью стилевых листов). Организована ли информация так, чтобы наиболее важные данные находились в начале страницы (чтобы их можно было прочесть в первую очередь)? Используете ли вы только командно ориентированные фразы в текстовых сообщениях любой природы (либо фразы, ориентированные на прямые действия)? Например, "Нажмите кнопку Абв, чтобы узнать результаты забегов" вместо "При нажатии кнопки Абв откроется страница с результатами забегов" или вместо "Не нажимайте кнопку Абв, если не хотите узнать результаты забегов". Сохраняется ли смысловая последовательность текста при его верстке (очень часто последовательность портится при использовании таблиц). Правильная последовательность важна для индексирующих машин, причем её значение будет возрастать в будущем (например, это важно для воспроизведения страниц синтезирующими речь системами). Стараетесь ли вы использовать кнопки с глаголами, нежели иными частями речи, например "Показать" вместо "Готово"? Установлен ли соответствующий альтернативный текст на все значимые графические изображения? Отвечает ли этот текст на один из трёх (или больше) вопросов: "Что это?", "Что это делает?" и "Что произойдет, если по этому щелкнуть?" Обладает ли ваш сайт своей справочной системой? В идеале каждый тип страницы должен обладать страницей со справочной информацией (вроде "Нажмите на эту кнопку, чтобы перейти к следующему разделу"). Различаются ли цвета у пройденных и непройденных гиперссылок? Проверили ли вы грамматику и орфографию? Убедились ли вы, что все страницы имеют корректный заголовок (title)? Отражают ли заголовки страниц (title) путь пользователя к этим страницам?