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

Глава 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»). Существуют билд – серверы как с открытым исходным кодом, так и с предоставлением коммерческих опций. Большинство крупных продуктов поддерживает множество различных систем управления версиями, а также множество различных вариантов того, когда и как инициировать сборку, что делать в рамках сборки (например, запускать тесты, развертывать на промежуточном сервере) и способы уведомления членов команды о результатах.

Для примера рассмотрим сборку на билд-сервере TeamCity.

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

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

Тестирование сборок бывает быстрое и полное. Рассмотрим каждый тип отдельно.

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

Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз^[17]. Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку. Затем из системы отслеживания ошибок выгружаются все выполненные задачи и исправленные за текущую итерацию ошибки и проверяется соответствие результата описанию задания. Если при этом задача также включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами^[18]. Некорректно выполненные задачи переоткрываются. Все ошибки заносятся в систему отслеживания ошибок. Ко всем ошибкам обязательно прикладываются логи со смартфона, а к ошибкам отображения или, как их еще называют, UI багам (от англ. «User Interface») - скриншоты с пометками и комментариями. После этого выполняются функциональные тесты текущей итерации. Если были найдены ошибки, не покрытые тест-кейсами, создается новый тест-кейс.

Для андроид приложений выполняются monkey тесты^[19] - тестирование, при котором команда тестировщиков вводит в приложение случайные произвольные данные и наблюдает за поведением приложения.

Для этого выполняются следующие скрипты:

adb shell monkey -p ru.stream.droid --throttle 50 --pct-syskeys 0 --pct-ap

pswitch 0 -v 5000

По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере^[20].