Автор: Ашутош Мишра (Ashutosh Mishra)
Оригинал статьи
Перевод: Ольга Алифанова

Все больше компаний обзаводится собственными мобильными приложениями, и многие экс-веб-тестировщики переходят в мобильное тестирование. Совершая этот переход, тестировщики иногда полностью игнорируют вроде бы мелкие проблемы вроде нестабильного интернета при использовании мобильного приложения пользователями (ниже я буду называть это «путем потребителя»).

Знаете ли вы, как ваше приложение справляется с ошибками или проблемами задержек, вызванными нестабильным соединением с Интернетом?

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

Оценка влияния проблем связи на ваше приложение

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

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

Вот как можно проанализировать текущее состояние приложения:

Изучение обработки ошибок: вызовы API

1. Перечислите вызовы API вашего приложения при выполнении важных сценариев. Смотрите только на API-запросы. На ответы в интерфейсе мы посмотрим позже.
2. Положите сервер или имитируйте ответ сервера, если выключить сервер нереально. Затем проверьте для каждого запроса, обработало ли приложение серверную ошибку (и если да, как именно). Распространенные ошибки – это падение запроса по таймауту и недоступность сервиса.

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

Изучение обработки ошибок: путь потребителя

1. Перечислите важные пути потребителя (сценарии), которыми конечный пользователь может продвигаться через пользовательский интерфейс.
2. Примите во внимание API-вызовы для каждого пути.
3. Как и в случае выше, положите сервер или имитируйте его отказ. Затем посмотрите, как пользовательский интерфейс обрабатывает ошибки. Вы можете увидеть пустые страницы, бесконечный спиннер или загрузку страницы, или универсальные сообщения «Произошла ошибка».
4. Исследуя приложение, попробуйте отключить Интернет перед отправкой форм, установкой фильтров или выбором чекбоксов и кнопок, ведущих к разным конечным точкам. Если для сброса состояния ошибки нужно перезапустить приложение, это стоит отметить. Это лишь один пример того, что может пойти не так.

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

Сообщение о проблемах, предложение решений

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

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

Вот как можно представить проблемы и предложения по их решению:

В списке проблем с путями пользователя и конечными точками API добавьте колонку «предположительное решение», где опишите, что можно сделать, чтобы улучшить ситуацию. К примеру: таймаут серверной стороны не должен приводить к пустой странице. Вместо этого стоит предложить пользователю отправить форму повторно, а приложение должно сохранять введенные данные, чтобы пользователю не пришлось пропечатывать их заново.

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

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

Примечание: могут быть доступны и иные решения – зависит от нужд продукта и их осуществимости.

Заключение

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

Удачного тестирования!

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