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

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

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

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

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

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

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

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

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

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

• Шрифт – их количество и совместимость, то, как они вписываются в концепцию, удобно ли его читать.

• Сочетание цвета иконок и цветов. Помогает ли это в поиске нужного раздела или нет.

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

• Как ведут себя UI–элементы на экранах разных форматов и габаритов: от десктоп версии до мобильной.

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

• Прогресс–бары – отображает ли он процесс загрузки.

• Ключевые кнопки, такие как войти, «Сохранить», «Добавить» и прочие. Их наличие и их удобное расположение.

• Всплывающее меню – реагирует ли оно на запросы, насколько корректно работает.

• Предупреждения, шорткаты и прочие дополнительные функции.

• На этот список можно опираться при проверке UI–дизайна, интерфейса программного продукта. Это основная часть, которая обычно задействуется пользователями в 80% случаев.

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим несколько вариантов.

• Модерированное тестирование.

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

• Немодерированное тестирование.

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

• Удаленное тестирование.

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

• «Герилья».

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

• Интервью по телефону.

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

Запись сценариев поведения в ходе проверки.

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

Анализ результатов и коррекция UI.

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

Сложно назвать отдельно взятые инструменты именно для UI–тестирования, потому что оценивать только дизайн интерфейса достаточно трудно. Можно опереться на какие–то принципы дизайна интерфейса, но часто в этом случае в дело будет вступать субъективная личная оценка.

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

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

GTmetrix.

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

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

Lool11.

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

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

Optimizely.

Инструмент, который используют для Alpha- и Beta–тестирования сайтов. Благодаря ему можно создавать наиболее благоприятные условия для увеличения конверсии. Например, есть возможность менять графический контент или редактировать кнопки.

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

Crazy Egg.

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

BrowserShots.

Доступный инструмент для кросс–тестирования веб–сервисов с открытым кодом. Имеет широкий спектр возможностей, например: проводить перекрестную проверку на совместимость, делает скриншоты разных экранов с разными плагинами и расширениями и многое другое. Поддерживает Android и iOS.

Maze.

Инструмент для тестирования прототипов UI/UX. Имеет поддержку таких программ, как InVision, Adobe XD и Sketch. Результаты проверки визуализирует в формате презентации, которую сразу же можно использовать для проведения встречи с заказчиком. Можно проводить тестирование на уже действующем сайте, а в платной версии записывать весь этот процесс на видео.

Автоматизация UI/UX.

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

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

Ниже рассмотрим, по каким принципам можно формировать задание.

Фокусированное задание.

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

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

Задача с контекстом.

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

Например, вместо того, чтобы дать типичную формулировку: «Зайдите в приложение и оформите заказ цветов с сладостями с доставкой на дом на 5000 рублей», можно указать: «Представьте, что вы выбираете подарок своей жене на годовщину свадьбы и у вас бюджет 5000 рублей". Оформите заказ с доставкой на дом». Каждый пользователь оформит разные заказы, применяя разные способы поиска товаров.

Задача на основе пользовательского опыта.

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

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

Задание без задания.

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

В заключение можно сформировать короткий чек–лист, на который можно опираться при создании заданий:

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

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

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

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

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

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