Тестирование поля выбора страны почти никогда не сводится к нажатию на пункт списка. Проверить, что значение выбирается, — это десятая часть работы; остальное составляют поиск по разным написаниям, правильный порядок пунктов, работа с клавиатуры и последствия смены значения для остальных полей формы. Именно на этих частях обнаруживается большинство дефектов, а вовсе не на самой возможности что-то выбрать.
Разберём по порядку: какие формы поля встречаются, как проверить поиск, почему порядок зависит от языка и что происходит после смены страны.
Какие формы поля выбора страны встречаются чаще всего?
Форма поля определяет, что именно нужно проверять, поэтому список тестовых случаев для длинного списка и для поля с автодополнением почти не пересекается.
| Форма поля | На что обращать внимание при проверке |
|---|---|
| Длинный раскрывающийся список | прокрутка, доступность пункта с клавиатуры, восстановление позиции |
| Список с поиском по вводу | совпадения по разным написаниям, отсутствие результата, очистка строки |
| Список, разбитый на группы | доступность каждой группы, поведение при сворачивании |
| Список только поддерживаемых стран | что показывается для остальных, есть ли явное сообщение |
| Поле со свободным вводом и подсказками | выбор из подсказки против произвольного текста |
Отдельно стоит проверять комбинацию двух последних форм. Если список ограничен поддерживаемыми странами, но поле допускает ручной ввод, почти неизбежно появляется значение, которого нет в списке. Поведение в этом случае должно быть задано осознанно: либо ввод отклоняется с понятным сообщением, либо принимается и помечается отдельно.
Как проверить, что поиск находит нужную страну
Поиск должен находить страну при нескольких разных написаниях, и это главный источник дефектов. Пользователи пишут по-разному, и почти каждый вариант встречается в реальности.
Проверять стоит как минимум четыре вида ввода:
- Название на языке интерфейса, включая форму с диакритическими знаками и без них.
- Название на другом языке, распространённом среди пользователей продукта.
- Короткий код страны, состоящий из двух букв.
- Устоявшееся краткое название или обиходное написание, которое не совпадает с официальным.
Если поиск срабатывает только по одному виду, поле работает для тех, кто угадал написание, и не работает для остальных. Особенно обидна ситуация, когда поиск по коду не находит ничего: код — это самое устойчивое представление страны, и его отсутствие в индексе поиска выглядит как недоделка.
Отдельный случай — поиск по части слова. Он должен вести себя предсказуемо: либо находить совпадения с начала, либо по любому месту строки, но одинаково для всех стран. Когда для одних стран совпадение ищется с начала, а для других по любому месту, поведение кажется случайным.
Проверьте также поведение при отсутствии результатов. Пустой список без сообщения выглядит как сбой загрузки, и пользователь повторит ввод вместо того, чтобы изменить запрос.
Почему порядок пунктов зависит от языка?
Сортировка по коду символа выглядит простой и предсказуемой, но для человеческого глаза она почти всегда неверна. В разных языках свои правила сравнения строк, и порядок, правильный для одного языка, ошибочен для другого.
Практическое следствие: пункты, начинающиеся с букв с диакритическими знаками, при сортировке по коду оказываются в стороне от своих соседей без знака. Для пользователя это выглядит как беспорядок, а не как порядок.
Что стоит проверить:
- что порядок соответствует правилам языка интерфейса, а не коду символа;
- что смена языка меняет порядок, если правила языков различаются;
- что при разбивке по группам порядок внутри группы сохраняется;
- что группа «прочие» доступна и не исчезает при сворачивании.
Последний пункт — отдельная ловушка. Когда список разбит по группам и группы можно сворачивать, часть реализаций считает свёрнутую группу отфильтрованной, и страна, попавшая в неё, становится недостижимой. Формально она есть, фактически выбрать её нельзя.
Как проверить клавиатуру и чтение с экрана
Длинный список стран — тяжёлый случай для клавиатуры, и проверять его нужно отдельно от мыши. Основные сценарии такие:
- переход к списку клавишей табуляции и выход из него без застревания;
- перемещение по пунктам стрелками, включая переход через границы видимой области;
- переход по первым буквам названия;
- закрытие списка клавишей отмены без изменения значения;
- возврат фокуса к полю после закрытия.
С чтением с экрана отдельно проверяется, что озвучивается выбранное значение, а не внутренний код, и что при разбивке по группам название группы читается до первого пункта. Длинные списки часто требуют виртуальной прокрутки, и тогда важно, чтобы озвучивание не теряло текущий пункт при прокрутке.
Проверка с клавиатуры часто обнаруживает дефекты, невидимые при работе мышью: невозможность покинуть список, прыжок фокуса в начало страницы, потерю уже выбранного значения.
Что происходит после смены страны в форме
Смена страны — это не изолированное действие, а точка, из которой расходятся последствия. Значения, зависевшие от прежней страны, становятся неверными, и с ними нужно что-то сделать.
Возможных вариантов три, и каждый должен быть выбран осознанно:
- очистить зависимые поля полностью;
- пересчитать их по правилам новой страны;
- оставить как есть и запросить подтверждение у пользователя.
Худший вариант — оставить значение молча. В форме остаётся город от прежней страны, а ошибка обнаруживается только при обработке. Особенно легко это заметить на значениях, которые выглядят правдоподобно.
Проверять стоит и обратный порядок действий: выбрать страну, заполнить зависимые поля, вернуться и сменить страну на исходную. Повторный выбор не должен терять уже введённые значения, если правила совпадают.
Что важно разработчику
Первое: разделяйте хранение кода и показ названия. Код остаётся неизменным идентификатором, название меняется вместе с языком интерфейса. Если хранить название, то при смене языка или при переименовании записи данные придётся переписывать, а это почти всегда заканчивается расхождениями.
Второе: один источник значений для всех мест, где страна выбирается или отображается. Форма, выгрузка, печатный документ и внешний обмен должны брать значения оттуда же, откуда берёт их список, иначе коды и названия разойдутся.
Третье: индексируйте для поиска все варианты написания, а не только основной. Состав такого индекса стоит держать рядом с данными о стране, а не в логике поиска.
Четвёртое: задайте поведение для значений, которых нет в списке. Явное решение лучше, чем случайное: форма либо отклоняет такое значение с понятным сообщением, либо принимает его и помечает.
Что делать дальше
Прогоните поле по списку сценариев выше и отметьте, какие из них никто не проверял. Обычно обнаруживается, что поиск по коду и поведение свёрнутой группы не проверялись ни разу.
Дальше стоит разобрать, что происходит, когда в одной заявке участвует больше одной страны: как выбирается, по чьим правилам проверять значения и какие поля появляются только в этом случае. Об этом — материал про сценарии адреса через границу. А если непонятно, почему поиск должен находить несколько написаний одной и той же страны, поможет статья про сопоставление названий стран и синонимы.
Проверить состав значений, которые вообще должны попадать в список, удобно по каталогу стран и регионов: он показывает страны и регионы сгруппированными, и по нему легко заметить, что в поле не хватает целой группы. И держите в голове разделение измерений из материала про страну и язык: язык интерфейса меняет подписи, но не состав значений.
Пункты списка, варианты написания и примеры ввода в этой статье приведены как вымышленные иллюстрации. Они не являются выдержкой из журналов обращений или из настоящих отправленных форм и не описывают поведение какого-либо конкретного продукта.