mobilnoe-testirovanie

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

Сегодня мы поговорим о QA с точки зрения мобильного тестирования — чем оно отличается от desktop или web. Давайте представим, что у нас есть мобильное приложение, которое мы выпустили в релиз. Как только наше приложение готово, разработано, протестировано, мы можем отдавать его пользователю. Но на самом деле мы отдаем его на review в App Store. И это одна из ключевых особенностей.

Review в AppStore или Google Play занимает от 1 до 3 дней. То есть, если мы выпустим в релиз нашу сборку с критическим багом, на то, чтобы доставить до пользователей правильную сборку тоже уйдет от 1 до 3 дней. И, более того, не факт, что все пользователи увидят этот фикс — просто потому, что они не будут обновлять приложение. И в этом первое отличие от web — мы не можем откатиться обратно. Кроме того, в мобильном тестировании итерации гораздо короче — обычно от 2 недель до, максимум, 2 месяцев, и это значит, что каждые две недели вам нужно будет тестировать апдейт.

icon-2Апдейт с миграцией всех данных

На web такого нет, а на desktop необходимо мигрировать все данные, которые хранятся в приложении. Более того, нужно тестировать не только апдейт с текущей версией из Store на ту, которую вы собираетесь релизить, нужно брать старую версию, которая уже не доступна пользователям в Store, но которая еще есть у них на телефонах. И тоже смотреть апдейт на версию, которую мы собираемся релизить.

Статистика

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

icon-5Геолокация

Посмотрим внутрь нашего приложения. Для некоторых функций нужен доступ к дополнительным пользовательским данным. Например, геолокация. Если мы запросим геолокацию при первом запуске приложения, скорее всего, нам откажут. Просто потому, что пользователь не понимает, что вообще нам сейчас нужно разрешать. Это значит, что ему придется перейти в настройки, что-то там изменить, вернуться в ваше приложение, чтобы просто воспользоваться какой-то из функций. Здесь достаточно длинный путь, и это значит, что по пути его может перехватить другое приложение, ему могут позвонить, на улице могут остановить — в итоге пользователь может не вернуться в ваше приложение или просто удалить его. Кроме того, некоторые функции требуют интеграции с системными сервисами, такими как Google Now, Siri или с другими приложениями. Эти интеграции нужно тестировать, и эти интеграции могут понадобиться вам еще и для фичеринга.

featuring

Фичеринг — это подборки приложений, которые вы видите на стартовых страницах магазина приложений, таких как Google Play или Apple Store. Чтобы туда попасть, нужно не только создать прекрасное приложение, но и грамотно работать с системными сервисами Google Now или Siri, либо поддерживать носимые устройства: Android Wear или Apple Watch и т.п. И когда мы начинаем с ними работать, то понимаем, что там достаточно «сырые» технологии, поскольку есть большие ограничения по интерфейсу, по тому, что можно показывать пользователю и как с этим взаимодействовать. И к интеграции эти приложения не очень устойчивы. То есть периодически что-нибудь может «отваливаться», например, доступ к той же геолокации. Здесь есть хорошая новость от Android Wear — он недавно начал поддерживать интеграцию с iPhone. Мы без этого страдали довольно продолжительное время, просто пытаясь отправить Google билд с поддержкой часов.

icon-4Дата

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

icon-11Локализации

Приложение, наверняка, будет расти, развиваться, распространяться по разным странам. Можно добавить поддержку разных языков. Тут мы столкнемся с новой трудностью — нестандартные кодировки символов, например, в арабском языке. Либо нестандартные форматы дат — все они должны поддерживаться приложением.

icon-6Миграция

Мы уже говорили про обычную миграцию, но есть еще и миграция, которая использует iCloud. И здесь есть две трудности. Первая — в любой момент из облака к вам могут «прилететь» очень старые данные, например, на пару версий приложения назад. Нужно быть готовыми к этому, правильно обрабатывать такие ситуации, чтобы приложение продолжало работать дальше, чтобы, может быть, даже могло конвертировать эти данные, потому что от версии к версии приложение может меняться: версия баз данных или какая-то структура внутри. Кроме того, у нас какие-то данные могут не синхронизироваться до апдейта приложения. Это значит, что после апдейта пользователь может потерять эти данные и очень расстроиться.

icon-7Интерфейс

Все знают про гайдлайны (guidelines). И у Apple, и у Google есть гайдлайны мобильных приложений. Но если в web и в desktop не обязательно очень хорошо их знать и строго им следовать, то в мобильных приложениях не следование гайдлайнам может привести к тому, что вас отправят обратно на review в Apple Store, то есть придется фиксить какие-то замечания, снова проводить приемку этого приложения, снова отправлять на review в Store, снова надеяться, что «ну, в этот раз, наконец-то примут». Либо приложение могут снова забанить или просто удалить. И там уже будут проблемы другого порядка.

icon-8Выбор девайсов

Ни для кого не секрет, что девайсов очень много. Если на iOs мы можем перечислить всю линейку, то на Android сделать это практически невозможно. Различные производители телефонов, различные диагонали экранов, различные объемы памяти. Имплементация операционной системы Android.

icon-9App Life Cycle

Это правило взаимодействия вашего приложения с операционной системой. Это значит, что когда ваше приложение запускают, когда его сворачивают/разворачивают, загружают из памяти, всегда выполняются какие-то действия — пользователю будет удобно потом просто развернуть приложение и начать работу с того места, где он остановился. О таких правилах нужно помнить и знать, потому что, когда вы сворачиваете приложение на Android, система может выгрузить его из памяти практически сразу, а вам нужно успеть записать все, что вы не успели записать. Это необходимо учитывать. И, вроде бы, мы ко всему готовы, но тут к нам прилетает апдейт самой операционной системы. Раз в год Google и Apple релизят мажорные операционные системы. Это как если бы Windows обновлялся каждый год. Это приносит ряд проблем, поскольку с таким апдейтом перестают работать какие-то маленькие кнопки в приложении, функционал, приложение может перестать запускаться и, чтобы наши пользователи не страдали также, как страдаем мы, нужно участвовать в бета-тестировании мобильных операционных систем. Заранее выпускать фиксы приложений, каких-то функций, которые могут «сломаться» и ждать официального релиза операционной системы.

Операции

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

icon-1Интернет-соединение

Большинство приложений сейчас используют, так или иначе, подключение к Интернету. Это мобильные подключения, wi-fi, отсутствие подключения в авиа режиме.

Прерывания

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

icon-13Быстродействие

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

По материалам доклада Лилии Абдулиной (Mobile QA, Aviasales) на конференции SQA Days-21