Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

В этой статьей я опишу интересные баги, которые я нашла, тестируя довольно скучную штуку – экранную клавиатуру.

Часто ли вы задумываетесь о тестировании методов ввода? Клавиатура, мышь, тач-скрин, загрузка, камера, или что угодно иное – все это методы ввода, а ввод - важная часть практически всех приложений. Так как экранная клавиатура обычно рассматривается как часть устройства (к примеру, смартфона или планшета), или даже как отдельное приложение – вы, возможно, не планируете тестировать ее в ходе проверки использующего такую клавиатуру приложения. Однако я неоднократно обнаруживала, что тестировать экранную клавиатуру в приложении надо так, как будто бы она неотъемлемая часть вашего продукта. Неважно, как вы это назовете – интеграционным тестированием или каким-то иным. Важно, что пользователи заметят, если клавиатура криво работает с вашим приложением, и все нежелательные варианты поведения могут повлиять на их решение пользоваться приложением впредь.

Контекст

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

Когда я тестировала приложение, пользователь мог вводить данные с клавиатуры только в двух местах – на экране авторизации/регистрации, и в поле количества или веса. Я также нашла проблемы на экране авторизации (и у меня были идеи, как тестировать его далее), но речь в статье не об этом. Если вы хотите узнать о тестировании авторизации больше – посмотрите тему на форуме Министерства тестирования о тестировании окна логина.

Баги

Перейдем сразу к делу: вот баги, которые я нашла в экранных клавиатурах, а также немного о том, почему это важно.

Исчезает опция менеджера паролей

Название говорит само за себя – возможность использования менеджера паролей не всегда была доступна на экране авторизации/регистрации.

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

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

Менеджер паролей не может заполнить поле почты

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

На скриншоте выше можно также заметить выпадающее поле почтовых доменов. Я хотела проверить, как это повлияет на менеджер паролей – не появится ли домен дважды (в текстовом поле и в выпадающем меню). Сделать это я не смогла, так как поле почты не заполнялось вообще. Я задумалась, связаны ли две эти проблемы – возможно, поле логина почты закодировано так, что не определяется как поле почты/логина, и поэтому менеджер паролей не может получить к нему доступ.

Отображается другая клавиатура

На устройстве, которым я пользовалась для тестирования, в дополнение к системным были установлены кастомные клавиатуры и менеджеры паролей. Если кастомная клавиатура была установлена по умолчанию, приложение использовало ее лишь иногда, в прочих случаях отображая системную.

Я неоднократно сталкивалась с тем, что приложения настаивают на использовании системной клавиатуры. Это раздражает и сильно ограничивает возможности и простоту ввода, однако смесь кастомной и системной клавиатур – это что-то новенькое. Пользователи, безусловно, устанавливают и настраивают кастомные клавиатуры не просто так, поэтому приложение должно разрешать им использовать эти клавиатуры везде и всюду, где это возможно.

Я подумала о других мобильных приложениях и задумалась – возможно, опция менеджера паролей спрятана, если отображается кастомная клавиатура? Но иногда она была спрятана, даже если срабатывала системная. Кажется, что это все-таки две разных проблемы, несмотря на то, что опция менеджера паролей может в принципе быть доступна только с системной клавиатуры.

Только темная тема

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

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

Клавиатуру тяжело спрятать

Это особенно заметно на скриншоте ниже. Когда клавиатура отображена, то спрятать ее очень сложно: пустого места, куда можно для этого нажать, не задев что-то еще, очень мало (нажатие на заголовок с надписью "Login" тоже не сработало).

Я завела это как баг, а не улучшение: это не только раздражает пользователя, но и повышает риск навязанных ошибок. Представьте, что вы раздраженный пользователь, который постоянно тапает не туда по случайности, потому что пытается спрятать клавиатуру и увидеть то, что под ней.

Кстати говоря, такая же проблема как-то раз заставила меня думать, что что-то не так с моим телефоном: я не сообразила, что дополнительные настройки были спрятаны за клавиатурой. Я не могла проскроллить экран к ним, когда клавиатура была отображена, и я не могла легко ее спрятать (пробовала неоднократно). Контракт на мой телефон нуждался в обновлении, и я получила новое устройство, но с раздражением обнаружила позднее, что и со старым было все в порядке – нужно было просто изменить настройки, которые я не могла увидеть из-за этой клавиатуры.

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

Источник: https://github.com/APSL/react-native-keyboard-aware-scroll-view

Улучшения

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

Текст на кнопке Enter

Тестируя экран авторизации/регистрации, я заметила, что текст на клавиатурном Enter (или клавише возврата) был не особенно полезным или неполно отражал, что эта кнопка собственно делает. В оригинале там было написано "Завершить" или "Готово", даже если это было не последним действием перед тем, как двигаться дальше. Эти надписи не имели смысла в контексте моего продукта.

При нажатии энтера в поле почты курсор перемещался в поле пароля. Я предложила поменять текст кнопки на "Далее". При нажатии энтера в поле пароля действие было аналогично кнопке "Войти". Я предложила так и назвать кнопку Enter.

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

Показывать цифровую панель для численных полей

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

Прочее

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

• Плюсы и минусы использования стандартной библиотеки клавиатур VS создание кастомизированной клавиатуры с нуля.
• Влияние местоположения и выбранного языка на раскладку клавиатуры и доступные символы.
• Множество основанных на языке раскладок VS единственная раскладка в алфавитном порядке.
• Скрытие или блокировка невалидных символов на клавиатуре VS вывод сообщения об ошибке
• Тестирование на нескольких уровнях VS надежда на недоступность символов на клавиатуре (речь о тестироавнии безопасности, спасибо, Бен Хайнрих, что помог мне в этом разобраться!)
• И так далее…

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

Обсудить в форуме