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

ВВЕДЕНИЕ

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

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

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

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

По оценкам экспертов, рынок специалистов по разработке мобильных приложений вырастет к 2018 году до 32,4 млрд долларов.^[1] В совокупности эти факторы делают разработку и, соответственно, последующее тестирование мобильных приложений все более и более актуальными.

Цель исследования - изучить процесс тестирования и убедиться, что взаимодействие приложения с аппаратной и программной платформой смартфонов и планшетов будет именно таким, как предполагалось на этапе прототипирования.

Объектом исследования в данной работе является поэтапное тестирование мобильных приложений.

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

Для достижения поставленной цели необходимо решить следующие задачи:

1. определить основные этапы разработки мобильных приложений;

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

Теоретико-методической основой исследования послужили труды зарубежных и российских программистов, которые посветили свои труды программированию в использовании мобильных приложений: Дейтел П., Дейтел Х., Уолд А., НильсенЯ., БудиуР., Арлоу Дж., Нейштадт А.Бурнет Э.

Глава 1. Основные этапы разработки мобильных приложений

1.1 Основные этапы и их описание

При разработке любого мобильного приложения можно выделить следующие ключевые этапы:

1. Бизнес-анализ целевого рынка.
2. Выработка итогового согласованного решения.
3. Прототипирование.
4. Написание кода и внедрение технологий.
5. Тестирование.
6. Создание предрелизной (тестовой) версии.
7. Добавление приложения в магазин.
8. Последующая техническая поддержка и маркетинговое продвижение.

Рассмотрим данные этапы более подробно.

Бизнес-анализ целевого рынка

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

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

• Каких целей планируется достичь посредством создания и релиза собственного мобильного приложения.
• Планируются ли продажи или конверсия переходов в продажу товаров и услуг в рамках приложения.
• Кто составляет целевую аудиторию и за счет кого она может пополниться.
• Насколько высока конкуренция в сфере, в которой ланируется работать (в том числе – с приложением).
• Какими приложениями пользуется целевая аудитория и аудитория конкурентов, пересекаются ли они между собой.
• Готовы ли они пользоваться разрабатываемым приложением вместо приложений-аналогов.
• Каков бюджет на разработку и продвижение полученного приложения.

Выработка согласованного решения^[4]

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

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

Прототипирование

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

Прототипы разрабатываются дизайнером при помощи инструментов для прототипирования, таких как Framer, Indigo Studio, Mockingbird, etc.

Прототипы могут быть статическими (например, бумажные: схематично нарисованный на листе бумаги процесс работы приложения, его внешнего вида, взаимодействия пользователей с приложением) или интерактивными (созданные при помощи таких программ, как Mockingbird или Simulify). Макеты должны составляться с учетом технической и программной базы, которую планируется использовать для создания приложения.

Написание кода и внедрение технологий

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

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

На различных этапах разработки приложения обязательным является внутреннее тестирование приложения, как на симуляторах, так и на реальных устройствах^[6]. Более подробно этот процесс будет рассмотрен в пункте 1.2 «Процесс тестирования мобильных приложений».

Создание предрелизной версии

В результате серии тестов и доработок приложения, должна быть получена рабочая версия. Именно эту версию и предстоит добавить в магазин приложений: Apple App Store, Google Play, магазин приложений Windows Phone (в зависимости от того, для какой платформы ведется разработка) или любой аналогичный сервис для дистрибуции приложений^[7].

Добавление приложения в магазин

Финальный этап работы студии – добавление приложения на предпросмотр в один из указанных выше магазинов приложений.

Дальнейшая техническая поддержка и маркетинговое продвижение приложения^[8]

Данный этап нельзя однозначно назвать основным, но при желании заказчика возможно предоставление дополнительных услуг, таких как техническая поддержка приложения, дальнейший выпуск новых версий под обновляемые версии мобильных ОС, а также маркетинговое продвижение^[9].

Поскольку эти услуги предоставляются отдельно от основного пакета услуг, то и, как правило, оплачиваются отдельно. Помимо маркетинга и техподдержки возможно также размещение приложения в App Store или Google Play от имени заказчика (услуга White Label) и обеспечение серверной поддержки для приложения.

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

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

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

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

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

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

Тестировщик анализирует требования на полноту и противоречивость. Если в проекте исходные требования содержат противоречивую информацию, такие вопросы решаются еще до начала разработки. Так же часто бывает, что в проекте предоставлены не полные требования: не хватает макетов второстепенных экранов, ограничений на поля ввода, отображения ошибок или есть незадействованные кнопки^[12]. Неочевидны невидимые на макетах вещи: анимации, кеширование картинок и содержимого экранов, работа в нестандартных ситуациях. Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам. На этом этапе используется используются системы управления проектами, например, «Basecamp».

После формирования полных, не противоречащих друг другу требований, тестировщик составляет так называемые smoke-тесты – первичные, самые грубые тестирования, направленные на то, чтобы выявить наиболее очевидные ошибки, и функциональные тесты, покрывающие исходные данные^[13].

Тесты делятся на общие и специфические для разных платформ.

Для хранения и проведения тестирования используются системы управления тестированием, такие как «Sitechсo», «TestLink», «Cradle» и т.д.

Ниже приведен пример использования системы «Sitechсo».

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

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

Билд-сервер

Билд – сервер^[14] – это инструмент для осуществления непрерывной интеграции при разработке программного обеспечения. Билд-серверы также часто называют серверами непрерывной интеграции или просто CI-серверами (от англ. «continuous integration servers»). Существуют билд – серверы как с открытым исходным кодом, так и с предоставлением коммерческих опций. Большинство крупных продуктов поддерживает множество различных систем управления версиями, а также множество различных вариантов того, когда и как инициировать сборку, что делать в рамках сборки (например, запускать тесты, развертывать на промежуточном сервере) и способы уведомления членов команды о результатах.