Основы тестирования удобства использования: что нужно знать QA-инженерам

Сообщение об ошибке «An error occurred. Please try again.» при регистрации с уже занятым email оставляет пользователя перед тремя неверными путями: сменить email, попробовать другой пароль или нажать кнопку ещё раз. Это растерянность. И это дефект юзабилити в зоне ответственности QA. Статья разбирает пять компонентов юзабилити по Нильсену, четыре метода тестирования от пятиминутных guerrilla-сессий до модерируемых, что может сделать QA-инженер без выделенного UX-процесса и как писать баги по юзабилити чтобы их воспринимали всерьёз.

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

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

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

Пять компонентов юзабилити по Нильсену

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

Обучаемость (Learnability): насколько легко новым пользователям выполнить базовые задачи? Эффективность (Efficiency): после освоения, насколько быстро опытные пользователи справляются с задачами? Запоминаемость (Memorability): когда пользователь возвращается после перерыва, насколько легко он восстанавливает навык работы с продуктом? Ошибки (Errors): сколько ошибок совершают пользователи, насколько они серьёзны и насколько легко их исправить? Удовлетворённость (Satisfaction): насколько приятен опыт использования?

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

Методы: от дешёвых к строгим

Эвристическая оценка (без пользователей)

QA-инженер или UX-специалист оценивает UI по устоявшимся юзабилити-эвристикам. Стандарт: 10 эвристик Нильсена:

1. Видимость статуса системы: пользователь понимает что происходит?

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

3. Свобода и контроль пользователя: можно отменить действие и выйти из ситуации?

4. Последовательность и стандарты: UI следует платформенным конвенциям?

5. Предотвращение ошибок: дизайн не допускает ошибок до того как они произошли?

6. Узнавание вместо припоминания: UI минимизирует нагрузку на память?

7. Гибкость и эффективность: есть шорткаты для опытных пользователей?

8. Минималистичный дизайн: UI свободен от лишней информации?

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

10. Документация и помощь: справка доступна и её легко найти?

Это быстро и не требует пользователей. Один сеанс ревью находит 30–50% проблем с юзабилити.

Guerrilla-тестирование

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

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

Модерируемые юзабилити-сессии

Фасилитатор работает с одним участником. Участник «думает вслух» выполняя задачи. Фасилитатор задаёт уточняющие вопросы.

Удалённое модерируемое тестирование через Zoom и шэринг экрана сделало это доступным. Инструменты вроде UserTesting или Maze предоставляют панели участников.

Немодерируемое юзабилити-тестирование

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

Что QA-инженер может делать без формального UX-процесса

Во время исследовательского тестирования: фиксируй моменты растерянности или неудобства. Вот дефект юзабилити: «Сообщение об ошибке говорит "Invalid input" без указания какое поле некорректно». Применяй 10 эвристик: при тестировании любой новой фичи проходи по списку Нильсена. Проверяй каждый пункт системно. Спрашивай "разберётся ли новый пользователь?": когда тестируешь фичу первый раз (без чтения спецификации), обращай внимание на собственную растерянность. Ты выступаешь прокси для новых пользователей. Тестируй восстановление после ошибок: что происходит когда пользователь делает типичную ошибку? Сообщение об ошибке полезное? Есть понятный путь к исправлению? Тестируй на мобильном: многие проблемы юзабилити специфичны для устройств. Слишком маленькие тач-таргеты. Формы которые требуют скролла вверх-вниз для заполнения. Модалки которые выходят за пределы экрана.

Типичные дефекты юзабилити которые стоит репортить

Сообщения об ошибках без указания что пошло не так и как исправить
Поля формы которые сбрасываются при ошибке (пользователю приходится вводить всё заново)
Обязательные поля не помечены обязательными до момента неудачной отправки
Кнопки или ссылки которые выглядят кликабельными но не кликаются, или наоборот
Диалоги подтверждения без чёткого различия между «подтвердить» и «отмена»
Состояния загрузки без индикации прогресса или ожидаемого времени ожидания
Действия без возможности отмены (особенно деструктивные)
Непоследовательная терминология (одна фича называется по-разному в разных частях UI)
Пагинация без отображения общего числа результатов или текущей позиции

Как писать дефекты юзабилити

Дефекты юзабилити сложнее писать чем функциональные: нет чёткого ожидаемого результата из спецификации. Формулируй через пользовательский impact:

Плохо: «Сообщение об ошибке непонятное.» Хорошо: «Когда пользователь отправляет форму регистрации с уже зарегистрированным email, появляется сообщение "An error occurred. Please try again." Пользователь не может понять: нужно ли сменить email, использовать другой пароль или попробовать войти. Рекомендация: показывать "Этот email уже зарегистрирован. Попробуйте войти." со ссылкой на страницу входа.»

Такой баг-репорт объясняет влияние на пользователя и предлагает конкретное решение. Это позволяет воспринимать проблемы юзабилити всерьёз, а не отмахиваться от них как от «дизайнерских мнений».