UI-тестирование – не просто галочка в чек–листе перед запуском проекта, а надежный щит от дополнительных затрат, ведь исправление ошибки после релиза обходится в десятки раз дороже самой разработки. Представьте ситуацию: стартап создал приложение для доставки еды, потратив 300 000 рублей. Однако после релиза выяснилось, что кнопка «Оформить заказ» в Safari не работает. В результате компания потеряла 40% клиентов, а с ними – выручку, инвесторов и репутацию.

Чтобы страшный сон разработчиков, описанный выше, не воплотился в реальности, необходимо проводить проверку пользовательского интерфейса. По данным исследования Baymard Institute, 88% процентов пользователей не вернутся на сайт после плохого UX. Если не хотите, чтобы львиная доля потенциальных клиентов вашего бизнеса ушла к конкурентам, тестирование пользовательского интерфейса должно стать обязательным этапом разработки любых программных продуктов. Давайте разберемся, что позволяют выявить проверки, какие элементы необходимо тестировать и какие методы для этого применять.

Для чего нужны UI–тесты?

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

• Кроссплатформенная совместимость. Сайт должен одинаково хорошо работать во всех браузерах и корректно отображаться на любых типах устройств;
• Соблюдение стандартов доступности (WCAG). Интерфейс должен быть удобен для людей с ограниченными возможностями;
• Корректность работы. Каждая кнопка, форма или пункт меню должны выполнять заявленные функции. Простыми словами, пользователь не должен попадать на страницу с ошибкой 500 после заполнения и отправки формы;
• Улучшение пользовательского опыта. Даже мелкие баги вроде нерабочей кнопки «Назад» могут отпугнуть потенциальных клиентов.

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

Виды UI-тестов

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

Ручное тестирование

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

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

Автоматизированное тестирование

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

Тестирование повторяющихся сценариев может проводиться с помощью скриптов на Selenium/Cypress, Galen Framework поможет проверить верстку, а Lighthouse – замерить скорость загрузки сайта.

Тестирование доступности

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

Тестирование доступности включает в себя анализ контрастности цветов, наличие альтернативного текста и проверку поддержки скринридеров. Оно может быть как ручным, так и автоматическим. Так, инструмент Contrast Checker подскажет, читаем ли текстовый контент на вашем сайте, а проверка навигации с клавиатуры с использованием команд Tab, Shift+Tab, Enter продемонстрирует, работает ли все без мыши.

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

Как тестировать интерфейс? Пошаговый план для перфекционистов

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

Шаг 1. Сбор требований

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

Профессиональные дизайнеры рекомендуют использовать для разработки кейса Jira и его знаменитые User Stories. Здесь можно кратко описать функционал каждого элемента с точки зрения конечного пользователя и контролировать ход выполнения задачи. Пригодится даже макет сайта из Figma с комментариями дизайнера.

Шаг 2. Определение элементов тестирования

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

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

Шаг 3. Разработка тестовых сценариев

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

1. Ввести e-mail без символа @ или www перед адресом
2. Нажать отправить
3. Ожидание: пользователь увидит сообщение «Неверный e-mail»
4. Реальность: отправка данных на сервер, появление ошибки 500

Шаг 4. Выбор методов тестирования пользовательского интерфейса

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

Шаг 5. Документирование процесса проверки

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

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

1. Шаги пользователя. Опишите весь процесс, который привел к ошибке (открыл карточку товара, кликнул «Добавить в корзину», перешел в раздел «Корзина»).
2. Ожидание. Здесь нужно отобразить, какой результат ожидался от действий (после открытия раздела «Корзина» в нем отображается выбранный ранее товар).
3. Реальность. В этой части подробно описывается ошибка (товар не отображается в «Корзине»).
4. Ссылки. Добавьте ссылку на скриншоты или видео с записью бага.

Шаг 6. Баг–репорты

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

• Тема: Кнопка «Оплатить» не реагирует на клик в Safari 16.1.
• Серьезность: Critical.
• Шаги:

1. Открыть сайт в Safari 16.1.
2. Добавить товар в корзину.
3. Нажать «Оплатить».

• Ожидание: Открывается форма оплаты.
• Реальность: Кнопка не кликабельна (JS-ошибка в консоли: «Uncaught TypeError»).
• Среда: macOS Ventura, iPhone 14 (iOS 16.5).

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

Чек–лист проверки: моменты, о которых важно помнить

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

• Формы: проверяем валидацию e-mail, пароля, номера телефона и других данных. Контролируем, что при отправке заполненной формы владелец сайта получает сообщение. Следим, чтобы сообщения об ошибках не закрывали важные кнопки.
• Адаптивность: тестируем, как сайт открывается на разных устройствах и экранах. Проверяем, не выходит ли текст за границы контейнеров, контролируем, что все элементы остаются кликабельными.
• Производительность: Проверяем скорость загрузки страниц с помощью Google PageSpeed. Контролируем скорость загрузки изображений и Lazy Load.
• Доступность: Тестируем функции для пользователей с ограниченными возможностями. Проверяем критические моменты – наличие субтитров в видео, контрастность, читаемость, размер шрифтов.
• Безопасность: Проверяем, скрыт ли звездочками пароль. Контролируем наличие утечек данных пользователей в URl.

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

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

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