Файл: Этапы разработки, тестирования и ввода в эксплуатацию мобильных приложений ( Основные этапы разработки мобильных приложений).pdf

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

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

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

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

Полное тестирование проводится непосредственно перед релизом. Оно включает себя в себя быстрое тестирование, регрессионное тестирование, monkey-тестирование на большом числе устройств (сто устройств или больше) и тестирование обновлений^[23].

Регрессионное тестирование подразумевает прохождение всех тест-кейсов по проекту^[24], не только за последнюю итерацию, но и за все предыдущие, и общие тест кейсы по требованиям. Обычно этот процесс занимает несколько дней на одно устройство, в зависимости от размера проекта.

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

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

Релизный monkey-тест проводятся как на iOS, так и на Android устройствах (есть в техническом задании была заложена работоспособность на обеих ОС) при помощи сервисов тестирования мобильных приложений, например Appthwack^[27]. В конце полного тестирования, кроме письма, вручную составляется подробный отчет.

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

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

Тестировать интеграцию с системами сбора статистики, такими как Google Analytics или Flurry, как и с системой статистики заказчика непросто. Высока вероятность того, что в итоговый релиз уйдет сборка с нерабочим Google Analytics, и данный акт останется незамеченный вплоть до того момента, как данный функционал понадобится заказчику ^[28].
Поэтому в обязательном порядке для внешних сервисов создается тестовый аккаунт, который проверяется при полном тестировании. Кроме того, отправка статистики фиксируется в логах, которые проверяются тестировщиками. При релизе тестовый аккаунт подменяется основным^[29].

Учет времени

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

1.3. Планирование работ по тестированию

После определения границ тестирования можно приступать к планированию самих работ^[31]. Необходимо отметить, что тестирование мобильного приложения занимает значительно больше времени, чем, например, веб-сайта или десктопного приложения, т.к. требуется учесть некоторые особенности и заложить время на следующие дополнительные проверки^[32]:

тестирование требований на полноту и внутреннюю непротиворечивость;
тестирование совместимости версий АПИ;
тестирование работы приложения на разных физических устройствах;
юзабилити-тестирование.

Подробнее рассмотрим каждый из этих пунктов.

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

При проведении тестирования мобильного приложения может возникнуть необходимостью тестирования требований. Обычно данное тестирование не включается в обязательный набор проверок при тестировании доработок, но в процессе написания чек-листов может быть выявлено то, что техническое задание оказалось неполным (не учитывает специфику мобильных приложений, противоречит спецификациям для веб-приложения, etc.)^[33], что по тем или иным причинам не было выявлено на этапе выработки согласованного решения. Также разработчики могут не обратить внимания на этот факт при реализации требований и сделать так, как им кажется удобнее. В итоге на тестирование выйдет такая версия приложения, которая может по-разному вести себя на разных платформах или вообще выпадать в системные ошибки при неучтенных в техническом задании комбинациях действий пользователя. Исправление уже реализованного функционала и его повторное тестирование требуют дополнительного времени. Поэтому оптимальным решением является проведение оценки требований к проекту еще до их передачи в разработку с составлением перечня указаний на возможные трудности и неучтенные моменты^[34].

Тестирование совместимости API

Еще один фактор, увеличивающий время тестирования, – это постоянно меняющаяся функциональность тех веб-приложений, по аналогии с которым реализовывалось мобильное приложение. Релизы программы не успевают за изменениями веб-версии, структура данных меняется, и веб-сервисы перестают возвращать нужные для мобильного приложения данные^[35]. В связи с этим неотъемлемой частью процесса стало тестирование API (от англ. – «Application Programming Interface» - набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах). Проверка состава и формата передаваемых и возвращаемых через REST-сервисы данных позволяет своевременно обнаруживать и исправлять те места, где мобильное приложение отстает от веб-версии^[36].

Тестирование на физических устройствах

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

переход в фоновый режим при поступлении звонков и sms, срабатывании будильника;
работу приложения при подключении к другим устройствам;
работу с разными видами интернет-подключений (Wi-Fi, 4G, 3G);
обработку ситуаций отсутствия связи (вывод сообщений при отключении интернет-соединения и корректное продолжение работы при его восстановлении);
процесс переустановки и обновления приложения до новой версии^[37].

Поскольку эти проверки очень сильно зависят от различных технических условий и специфических ситуаций, при их проведении не обойтись без реальных устройств. Более того, эмуляторы мобильных телефонов не дают реальных показателей скорости работы приложения, производительности и отзывчивости настоящего телефона. Также на эмуляторе трудно оценить и удобство приложения^[38]. Да, большую часть функционального тестирования можно провести с помощью эмуляторов, но проверить поведение приложения в реальных условиях можно лишь с использованием настоящих смартфонов и планшетов.

Юзабилити-тестирование

Еще одним неотъемлемым этапом тестирования мобильного приложения является юзабилити-тестирование^[39]. Здесь очень важно обеспечить для пользователя максимальный комфорт при работе с приложением, который подразумевает выполнение следующих требований^[40]:

быстрота работы;
простота и понятность интерфейса;
минимальный ввод данных с клавиатуры;
наличие индикации (отклика) на действия пользователя.

Также необходимо, чтобы приложение соответствовало общепринятым стандартам (руководствам) по стилю.

Итак, при разработке мобильных приложений, и при их тестировании, следует учитывать ряд моментов^[41]:

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

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

Вывод первой главы

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

Глава 2. Характеристики мобильных приложений

2.1 Проблема безопасности. Угрозы мобильной информационной безопасности и меры защиты

По оценкам отраслевых экспертов, к 2019 году число мобильных работников по всему миру достигнет 1,8 млрд. человек^[42].

Предполагается также, что к этому времени 75% всех работников в США будут мобильными – в том смысле, что они будут использовать мобильные информационные устройства для выполнения по меньшей мере 20% своей работы^[43]. По данным другого исследования, 36% владельцев мобильных телефонов либо теряли свой телефон, либо становились жертвами воров. Если сопоставить эти цифры, получится, что в ближайшем будущем примерно четверть всех работников потеряют свои мобильные устройства (возможно, вместе с конфиденциальной информацией). Так что нет ничего удивительного в том, что проблема безопасности мобильной информационной техники стоит сегодня для организаций на первом плане. Несмотря на все эти тревоги, лишь немногие органы. Многие компании отказались от реализации всесторонней стратегии мобильной информационной безопасности, поскольку считают, что это слишком дорого и трудоемко. В то же время мобильная информационная технология продолжает все шире внедряться в повседневные рабочие процессы, а нарушения безопасности приводят к значительным убыткам. В 2017 году каждый инцидент в среднем обходился в 6,75 млн. долларов^[44].