UX- и UI-тестирование — это не одно и то же

UX- и UI-тестирование задают два разных вопроса

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

Что автоматизация честно может взять на себя

• Функциональная корректность каждого сценария. Весь первый столбец.

• Механические проверки доступности. Пропущенные подписи, контраст, порядок фокуса. Реальная польза — и при этом не вся доступность.

• Проверки единообразия. Ведёт ли себя одно и то же действие одинаково в трёх разных местах — это UX-проблема, у которой есть проверяемая форма.

Что она не может

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

Пересечение, которое стоит автоматизировать

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

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

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

Ловушка

Команды сокращают UX-исследования, потому что покрытие UI-тестами высокое. Логика кажется здравой, но это подмена понятий: покрытие говорит, что продукт делает то, для чего его построили, и ничего не говорит о том, то ли вообще стоило строить.

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

Ничего из этого не требует терминала. Создайте проект в панели TestSprite, опишите проверку обычным языком и направьте её на своё приложение. Разработчики в вашей команде могут делать то же самое из командной строки, если им так привычнее, — это описано в репозитории CLI.

Триггер важнее механизма. Если привязать запуск к событию деплоя, каждое изменение проверяется без чьего-либо отдельного решения; GitHub App делает это из панели управления, а шаг GitHub Actions — изнутри вашего рабочего процесса.

Что автоматизирует TestSprite и что оставляет вам

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

Он также покрывает проверки единообразия, которые лежат в зоне пересечения: например, ведёт ли себя одно и то же действие одинаково везде, где оно встречается, — это UX-претензия с проверяемой формой.

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