Тестирование UI вручную изначально возникло как необходимость, поскольку автоматические средства плохо улавливают ошибки, связанные с визуальным восприятием и удобством использования интерфейса (история). Все элементы должны быть доступны, отображаться корректно и взаимодействовать согласно ожиданиям пользователя.
Основная проблема ручного UI-тестирования — субъективная оценка: разные люди могут по-разному воспринимать один и тот же интерфейс. Кроме того, часты ситуации, когда визуальные дефекты не документируются или игнорируются (‘проблема’). Чтобы избежать субъективности, нужно разработать чёткие критерии приемки визуальных элементов, использовать изометрические и гайдлайны, а найденные проблемы фиксировать с помощью скриншотов, четких описаний и сравнения с исходными макетами (‘решение’).
Ключевые особенности:
Достаточно ли проверить UI только в одном браузере или на одном устройстве?
Нет, элементы могут отображаться по-разному из-за различий в движках браузеров и разрешениях устройств.
Если тестировщик не видит дефект, может ли он считать, что баг отсутствует?
Нет, необходимо сравнивать интерфейс с гайдлайнами и макетами, а не только полагаться на свой субъективный взгляд.
Можно ли игнорировать требования к доступности (accessibility) при тестировании UI?
Нет, требования к доступности важны для конечных пользователей, в том числе для людей с ограниченными возможностями.
Тестировщик проверил UI только на своем компьютере и в одном браузере, а также только сравнил визуально с предыдущей версией, без опоры на макет. В итоге пользователи с мобильных устройств увидели сломанный интерфейс.
Плюсы:
Минусы:
Тестировщик проверил UI на разных устройствах и браузерах, сравнил с макетом, учитывал accessibility-гайды. Использовал чек-листы по визуальным критериям.
Плюсы:
Минусы: