Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Баги клавиатуры: тестирование в реальной жизни, часть 3
27.12.2019 00:00

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

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

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

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

Контекст

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

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

Баги

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

Это интересный пример регресса – изменение чего-то одного к лучшему повлекло совершенно неожиданные последствия для чего-то другого. Это также демон