Специфика мобильного тестирования

Свои источники багов

Первое отличие от веба - приложение не живёт непрерывно. Система выгружает его из памяти, когда та нужна другим, и при возврате оно поднимается заново. Значит, всё, что человек ввёл и не отправил, должно быть где-то сохранено, иначе он вернётся к пустой форме.

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

// Третье - сам продукт бывает разного устройства, и от этого зависят баги. Нативное написано под платформу и имеет полный доступ к ней. Кроссплатформенное собирается из одного кода под обе системы - и приносит свои артефакты на стыке с платформой. Отдельный случай - встроенный браузер внутри приложения (WebView): экран выглядит как часть приложения, а на деле это веб-страница со своими правилами хранения данных и возврата назад.

выгрузка системой

приложение убито ради памяти; при возврате поднимается с нуля

встроенный браузер

веб-страница внутри приложения; ведёт себя как веб, а не как экран

Фрагментация: замер матрицы

Фрагментация - это разнообразие устройств, на которых крутится ваше приложение. Посчитаем скромный набор осей: 6 версий системы, 5 размеров экрана, 4 производителя, 3 плотности экрана. Перемножаем: 360 сочетаний. По полчаса на короткий прогон - 180 часов на один круг. Ни один человек этого не сделает.

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

// Две системы ведут себя по-разному, и это не вкусовщина. У Apple железо однообразное и поведение предсказуемое. На Android сверх версий системы наслаиваются прошивки производителей - это версии системы, доработанные под свои телефоны, - и часть из них агрессивно выгружает фоновые приложения, чтобы экономить батарею - то есть ваш сценарий с фоновой загрузкой на одном телефоне работает, а на другом обрывается. Отсюда практика: один и тот же сценарий на двух системах часто становится двумя разными тестами.

фрагментация

разнообразие версий, экранов и прошивок; полная матрица нереальна

матрица устройств

срез, покрывающий основную долю вашей аудитории

Прерывания, сеть, обновление

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

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

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

прерывание

внешнее событие поверх экрана: звонок, уведомление, будильник

обновление поверх

установка новой версии на старые данные - частая причина падений после релиза

Как отвечать: «Чем мобильное тестирование отличается от веба?»

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

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

На чём валят

• −Проверять оплату только в открытом приложении: из пятнадцати сочетаний с прерываниями закрыто одно.
• −Тестировать на флагмане из офиса, когда аудитория сидит на бюджетниках трёхлетней давности.
• −Забыть переключение сетей: форма теряет введённое при переходе с беспроводной на мобильную.
• −Проверять только «разрешил»: отказ и отзыв разрешения посреди сценария роняют приложение.
• −Тестировать чистую установку и не тестировать обновление поверх старой версии с данными.