Способы тестирования мобильных приложений

Тестируем 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 Рамилем Усмановым.

Источник

Процесс тестирования мобильных приложений

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

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

Тестирование требований

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

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

Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций, вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам.

В основном на этом этапе используется basecamp.

Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.

Например, для проекта Trava на этом этапе было написано 1856 тестов.

Первый шаг тестирования закончен. Проект уходит в разработку.

Билд-сервер

Все наши проекты собираются на TeamCity билд-сервере.

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

Без «волшебного монитора» (кстати, работает на андроиде) часто тестировали старые билды. А новый билд с багами попадал заказчику. Теперь перед прогоном тест-кейсов достаточно взглянуть на монитор, путаница разрешилась.

Тестирование билдов бывает быстрое и полное.

Быстрое тестирование

Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.

Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.

Затем берутся все выполненные задачи и пофикшенные баги за итерацию из Jira и скурпулезно проверяется соответствие результата описанию таска. Если задача включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами.

Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.

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

Для андроид приложений запускаются monkey тесты.

По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере (да, название галочки не очень правильное :).

Если в процессе тестирования не было найдено blocker, critical и major багов, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами).

Критичность бага определяется по таблице.

После завершения тестирования PM получает подробное письмо-отчет.

Полное тестирование

Полное тестирование проводится перед релизом. Включает себя в себя быстрое тестирование, регресионное тестирование, monkey-тестирование на 100 устройствах и тестирование обновлений.

Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту. Тест-кейсов не только за последнюю итерацию, но и за все предыдущие и общие тест кейсы по требованиям. Это занимает день-три на одно устройство в зависимости от проекта.

Очень важный шаг — тестирование обновлений. Почти все приложения хранят данные локально (даже если это кука логина) и важно удостовериться, что после обновления приложения все данные пользователя сохранятся. Тестировщик скачивает билд из маркета, создает сохраняемые данные (логин, плейлисты, транзации учета финансов), обновляет приложение на тестовую сборку и проверяет, что все на месте. Затем прогоняет smoke-тест. Процесс повторяется на 2-3 устройствах.

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

Релизный monkey-тест мы проводим на 10 iOS и 80 Android устройствах при помощи сервиса Appthwack.

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

Сборка уходит в релиз только при 100% прохождении всех тест-кейсов.

Тестирование внешних сервисов

Тестировать интеграцию с Google Analytics, Flurry или системой статистики заказчика непросто. Бывало, что в релиз уходили сборки с нерабочим Google Analytics и никто не обращал на это внимания.

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

Учет времени

Учет времени тестировщиков производится в отдельном Jira проекте. На составление тест-кейсов, прогон тестов, написание отчетов по проекту заводится отдельная задача и стандартными средствами в ней отмечается затраченное время.

UPD: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика

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

Источник