Тестирование при помощи android

Тестируем Android-приложение правильно

Меня зовут Андрей Рыжкин, я CTO AGIMA.

Сегодня я расскажу о том, как мы тестируем приложения на Android, а также поделюсь нашим чек-листом.

Чек-лист от команды AGIMA

В 2020 году количество приложений для Android вплотную приблизилось к трём миллионам (по данным Appbrain на 28 марта). И это число продолжает расти – каждый день появляются сотни новых программ для этой операционной системы. В том числе благодаря AGIMA. Мы создаем самые разные приложения для Android – простые и сложные, узкоспециализированные и «для всех». И можем немало рассказать о нюансах их разработки.

Конечно, главное в Android-приложении – его функционал. Недочеты вёрстки редко бросаются в глаза, но качество любого продукта – в мелочах. Поэтому мы всегда тщательно тестируем приложения перед запуском. А для того, чтобы тестирование занимало минимум времени и приносило максимум пользы, мы разработали специальный чек-лист, которым рады поделиться с вами!

Но сначала перечислим шесть наиболее распространенных проблем вёрстки, избежать которых поможет наш чек-лист.

1. Сдвиг элемента страницы

При вёрстке страницы можно применить три вида выравнивания по вертикали (Align Top, Align Middle и Align Bottom) и три – по горизонтали (Align Left, Align Center, Align Right). Но если использовать их несогласованно, отдельные элементы страницы начинают «съезжать» со своих мест.

На рисунке слева всё хорошо, но стоит изменить разрешение – и заголовок сдвигается вправо.

2. Обрезка текста

Проблема появляется, когда компоненты GUI пытаются сжать, чтобы «втиснуть» в маленький экран.

Слева всё в порядке, справа часть текста обрезана из-за изменения ориентации устройства.

3. Отсутствие элемента страницы

При снижении разрешения экрана элементы увеличиваются в размере. И при неправильной вёрстке некоторые из них могут просто «исчезнуть».

4. Пересечение элементов

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

5. Выход элементов за границы экрана

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

6. Артефакты адаптивного дизайна

При увеличении разрешения экрана может возникнуть «обратная» ситуация – компоненты GUI и текстовые символы могут уменьшиться до абсолютно нечитабельных размеров.

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

Гайдлайн не дает четких рекомендаций по размеру текста, однако по результатам исследования комфортным считается шрифт в 16 пикселей высотой, а приемлемым для чтения – 12-14 пикселей.

Перечисленные проблемы часто «наслаиваются» друг на друга – как известно, беда не приходит одна. И результаты таких сочетаний могут быть самыми непредсказуемыми. Но это – тема для отдельной статьи.

А теперь – обещанный чек-лист. Используйте его во время тестирования Android-приложения – и от вас не «ускользнет» ни одна ошибка!

Чек-лист

• Установка из дистрибутива происходит без уведомлений об ошибках.

• Успешно выполняется установка из магазина приложений.

• Установка обновлений не вызывает ошибок.

• Отмена установки происходит корректно, с удалением всех следов приложения.

• Повторная установка после отмены возможна и выполняется успешно.

• При попытке установки на неподдерживаемое устройство/версию ОС появляется предупреждение о несовместимости, и установка корректно завершается.

Запуск и выход из приложения:

• Приложение запускается при клике по его иконке.

• Приложение запускается в режиме разделенного экрана.

• Приложение запускается при клике по уведомлению от него.

• Приложение запускается по ссылкам из других приложений.

• Приложение запускается по голосовой команде.

• Приложение запускается при автозагрузке.

• Приложение запускается при управлении жестами.

• Приложение запускается при открытии ассоциированных файлов.

• Приложение возобновляет работу после перевода в фоновый режим.

• Время запуска приложения не слишком велико.

• Возможен выход из приложения штатным способом.

• Возможен выход из приложения при нажатии на кнопку «домой» (приложение переходит в фоновый режим).

• Управление приложением интуитивно понятно.

• Навигация в приложении соответствует требованиям, предъявленным заказчиком

• Приложение корректно обрабатывает смену ориентации экрана.

• Приложение корректно обрабатывает изменение масштаба отображения.

• Приложение корректно обрабатывает жесты multitouch.

• Вызов клавиатуры происходит корректно, клавиатура не скрывает элемент страницы, в который вводится текст.

• Элементы управления соответствуют выполняемым функции.

• Расход заряда батареи соответствует нагрузке, создаваемой приложением.

• Задержки переходов и/или открытия не критичны.

• Приложение соответствует требованиям удобства использования для платформы

• Нет «вылетов» приложения и/или неожиданно возникающих всплывающих окон.

• (если заявлено в ТЗ) В приложении присутствует помощь для новых пользователей

Вёрстка (на всех заявленных в ограничениях устройствах и разрешениях):

• Отсутствуют сдвиги элементов страницы (расположение элементов соответствует заявленному в макете).

• На страницах нет обрезки текста.

• На страницах присутствуют все заявленные элементы.

• Элементы не пересекаются и не «наслаиваются» друг на друга.

• Ни один элемент не выходит за границы экрана.

• Отсутствуют артефакты адаптивного дизайна.

• Обновления устанавливаются корректно.

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

• Появляются уведомления при нескольких пропущенных обновлениях.

• Появляются уведомления при пропущенных критических обновлениях, препятствующих эксплуатации приложения.

• Приложение работает после обновления ОС.

• Приложение работает после прерванной или отмененной установки обновления.

• Прерывание работы приложения телефонным звонком обрабатывается корректно.

• Прерывание работы приложения получением СМС обрабатывается корректно.

• Прерывание работы приложения сменой ориентации экрана обрабатывается корректно

• Прерывание работы приложения блокировкой/разблокировкой экрана обрабатывается корректно.

• Прерывание работы приложения системными уведомлениями обрабатывается корректно.

• Прерывание работы приложения разрывом соединения с интернетом обрабатывается корректно.

• Возможна работа приложения при слабом/нестабильном соединении (в зависимости от требований).

• Возможна работа приложения в режиме энергосбережения.

• При смене сети работа приложения не прерывается.

• Работа приложения не зависит от процессов передачи данных в фоновом режиме.

• В магазине приложений нет алертов на безопасность приложения.

• При запуске приложения на устройстве не возникает коллизий (при использовании наиболее популярных антивирусных систем).

• При установке и использовании приложение запрашивает и может использовать нужные разрешения.

• Приложение корректно работает с пользовательской сессией (согласно требованиям.

И напоследок важный вопрос для всех читателей. Какие пункты вы добавили бы к нашему чек-листу? Будем рады вашим идеям!

Статья написана с ex-head QA AGIMA Рамилем Усмановым.

Источник

А/В-тесты на Android от А до Я

Большая часть статей об A/B-тестах посвящена веб-разработке, и несмотря на актуальность этого инструмента и для других платформ, мобильная разработка несправедливо остаётся в стороне. Мы попытаемся эту несправедливость устранить, описав основные шаги и раскрыв особенности реализации и проведения A/B-тестов на мобильных платформах.

Концепция A/B-тестирования

A/B-тест нужен для проверки гипотез, направленных на улучшение ключевых метрик приложения. В простейшем случае пользователи делятся на 2 группы контрольную (A) и экспериментальную (B). Фича, реализующая гипотезу, раскатывается только на экспериментальную группу. Далее на основе сравнительного анализа показателей метрики для каждой из групп делается вывод о релевантности фичи.

Реализация

1. Делим пользователей на группы

Для начала нам необходимо понять, как мы будем делить пользователей на группы в нужном процентном соотношении с возможностью динамически его менять. Такая возможность будет особенно полезна, если вдруг выяснится, что новая фича повышает конверсию на 146%, а раскатана, например, всего на 5% пользователей! Наверняка нам захочется выкатить её на всех пользователей и прямо сейчас — без обновления приложений в сторе и сопутствующих временных издержек.

Конечно, можно организовать разбивку на сервере и каждый раз при необходимости что-то менять дёргать backend-разработчиков. Но в реальной жизни бэк зачастую разрабатывается на стороне заказчика или третьей компанией, и у серверных разработчиков и так хватает дел, поэтому оперативно регулировать разбивку, работая с третьими лицами, удаётся не всегда, а точнее, почти никогда, поэтому такой вариант нам не подходит. И тут на помощь приходит Firebase Remote Config!

В Firebase Console, в группе Grow есть вкладка Remote Config, где вы можете создать свой конфиг, который Firebase доставит пользователям вашего приложения.

Конфиг представляет собой мапу с возможностью присваивать значение параметра по условию. Например, пользователям с конкретной версией приложения значение X, всем остальным — Y. Более подробно о конфиге можно узнать в соответствующем разделе документации.

Также в группе Grow есть вкладка A/B Testing. Здесь мы можем запускать тесты со всеми вышеописанными плюшками. В качестве параметров используются ключи из нашего Remote Config. В теории можно прямо в A/B-тесте создать новые параметры, но это только внесёт лишнюю путаницу, поэтому делать так не стоит, проще добавить соответствующий параметр в конфиг. Значение в нем традиционно является значением по умолчанию и соответствует контрольной группе, а экспериментальное значение параметра, отличное от дефолтного — экспериментальной.

Прим. Контрольная группа обычно называется группой A, экспериментальная — группой B. Как видно на скрине, в Firebase по умолчанию экспериментальная группа называется “Variant A”, что вносит некоторую путаницу. Но ничто не мешает изменить её название.

Далее запускаем A/B-тест, Firebase разбивает пользователей на группы, которым соответствуют разные значения параметра, получив конфиг на клиенте, мы достаём из него нужный параметр и на основе значения применяем новую фичу. Традиционно параметр имеет имя соответствующее названию фичи, и 2 значения: True — фича применяется, False — не применяется. Подробнее о настройках A/B-тестов в соответствующем разделе документации.

2. Кодим

Не будем останавливаться непосредственно на интеграции с Firebase Remote Config — она подробно описана здесь.

Разберём способ организации кода для проведения A/B-тестирования. Если мы просто меняем цвет кнопки, то говорить об организации нет смысла, ибо организовывать особенно нечего. Мы рассмотрим вариант, в котором в зависимости от параметра из Remote Config показывается текущий (для контрольной группы) или новый (для экспериментальной) экран.

Нужно понимать, что по истечению A/B-теста один из вариантов экрана надо будет удалить, в связи с этим организовать код необходимо таким образом, чтобы минимизировать изменения в текущей реализации. Все файлы связанные с новым экраном стоит называть с префиксом AB и помещать в папки с таким же префиксом.

Если мы говорим об MVP в Presentation слое, выглядеть это будет примерно так:

Наиболее гибкой и прозрачной представляется следующая иерархия классов:

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

AbOrderStatusFragment будет переопределять методы, различающиеся в реализации, и иметь необходимые дополнительные. Таким образом, в текущей реализации изменится лишь разбивка одного класса на два и некоторые методы в базовом классе станут protected open вместо private.

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

В рамках такой организации скорее всего придётся отступить от принятого CodeStyle, что в данном случае допустимо, ибо соответствующий код будет удалён или отрефакторен по завершению A/B-теста (но, конечно, в местах нарушения CodeStyle стоит оставить коммент)

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

Для получения конфига стоит создать отдельный репозиторий и заинжектить его на уровень приложения, чтобы он был везде доступен, так как мы не знаем, какие части приложения затронут будущие A/B-тесты. По этим же причинам запрашивать его стоит как можно раньше, например, вместе с основной информацией, необходимой для работы приложения (обычно такие запросы происходят во время показа сплеша, хотя это холиварная тема, но важно что где-то они есть).

Ну, и, естественно, важно не забыть прокинуть значение параметра из конфига в параметры событий аналитики, чтобы была возможность сравнить метрики

Анализ результатов

Есть немало статей, подробно рассказывающих про способы анализа результатов A/B-тестов, например. Чтобы не повторяться, просто укажем суть. Нужно понимать, что разница метрик на контрольной и экспериментальной группе — случайная величина, и мы не можем сделать вывод о релевантности фичи только на основе того, что на экспериментальной группе показатель метрики лучше. Необходимо построить доверительный интервал (выбор уровня надёжности стоит доверить аналитикам) для вышеописанной случайной величины и проводить эксперимент до тех пор, пока интервал полностью не окажется в положительной или отрицательной полуплоскости — тогда можно будет сделать статистически достоверный вывод.

Подводные камни

1. Ошибка при получении Remote Config

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

Рассмотрим следующий кейс: у нас есть пользователь, которого Firebase отнёс к экспериментальной группе. Пользователь первый раз запускает приложение и запрос Remote Config возвращает ошибку — пользователь видит старый экран. При следующем запуске запрос Remote Config отрабатывает корректно и пользователь видит новый экран. Важно понимать, что такой пользователь не является релевантным для эксперимента, поэтому нужно придумать, как отсеивать такого пользователя на стороне системы аналитики, либо доказать, что число таких пользователей пренебрежимо мало.

На самом деле такие ошибки действительно возникают нечасто, и скорее всего вам подойдёт последний вариант, но есть по сути аналогичная, но куда более насущная проблема — время получения конфига. Как было сказано выше, лучше засунуть запрос Remote Config в начало сессии, но если запрос будет идти слишком долго, пользователю надоест ждать, и он выйдет из приложения. Поэтому нужно решить нетривиальную задачу — выбрать тайм-аут, по которому сбрасывается запрос Remote Config. Если он будет слишком мал, то большой процент пользователей может оказаться в списке нерелевантных для теста, если слишком большим — мы рискуем вызвать гнев пользователей. Мы собрали статистику по времени получения конфига:

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

Источник