Разработка информационной системы накопительной программы лояльности для мобильных устройств

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

 

                       Рис. 6                                                             Рис. 7

 

Разработка и внедрение  процесса контроля качества

Задача контроля качества является одной из ключевых, когда речь идет о разработке приложений для retail.

Стоит выделить два этапа контроля качества:

1. Во время разработки мобильных приложений
2. Во время эксплуатации системы

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

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

Процесс контроля качества в момент разработки

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

Тестирование делалось на основе спецификации. Спецификация представляет собой список функциональностей приложения (например "Отображение купона"). Каждая функциональность содержит набор правил, которые должны выполняться, чтобы считалось что функциональность на клиенте «принята». Пример правила - "На купоне показывается количество монеток, соответствующее полю "price" в протоколе".

Спецификация утверждается, ей присваивается версия и она сохраняется в PDF файле. Для каждого правила спецификации придумываются тест-кейсы, позволяющие как проверить как можно больше различных ситуаций, в которых правило должно выполняться. Любой тест-кейс имеет 3 пункта: начальные условия, действия и ожидаемый результат.

При этом, «начальные условия» - это условия, которые должны быть созданы до непосредственно старта процесса проверки правильности. Другими словами, не ставится цель тестировать возможность создать эти условия в данном тест-кейсе. Предполагается, что такое условие уже создано. Например, если речь идет о показе нужного количества монет на купоне, то процесс синхронизации тут скорее всего не при чем. Ведь реально необходимо по сути проверить что клиент правильно отобразит монеты. Таким образом, синхронизация выносится в начальные условия и предполагается что она уже работает корректно.

В разделе «действия» непосредственно описываются действия, которые вовлекают тестируемый компонент/функцию/кнопку.

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

Вот пример правильного тест-кейса, созданного в рамках разработанного процесса контроля качества: 
================================= 
Проверяем что 0 монеток правильно отобразиться на купоне: 
начальные условия: 
  - На сервер закачан купон с price=0, купон выдается 
  - Проведена синхронизация 
действия: 
  - Найти обозначенный выше купон 
ожидаемый результат: 
  - Купон будет отображаться и на нем будет 5 изображений монеток. 
=================================

Стоит отметить, что тест-кейсами невозможно покрыть абсолютно все случаи. Например, если значение price может быть от 0 до 100, то создавалось как минимум 3 тест-кейса: на 0 price, на 100 и на 66.

Когда для функциональности все правила расписаны и по ним написаны тест-кейсы – создавался ТЕСТ для приемки функциональности. Тест - это некая последовательность действий, совершаемая для проверки функционала на всех перечисленных тест-кейсах. По сути для создания теста, нужно взять все  тест-кейсы, которые были выписаны для данной функциональности и объединить их в нечто единое. Действия могут быть 2х вариантов: "сделать что-то" и "проверить что что-то выполняется"

В случае если в процессе прохождения теста, хотя бы какой-то из этапов теста "сделать" невозможно сделать - тест считается проваленным, выполнение теста прекращается, пишется причина почему тест провален. Тесту присваивается результат "ERROR".

В случае если в процессе прохождения теста, хотя бы какой-то из этапов теста "проверить" дал ответ что проверка выявила некорректный результат - тест считается заваленным, выполнение теста прекращается, пишется причина почему тест завален. Тесту присваивается результат "FAILED"

В случае если в процессе прохождения теста, все этапы теста выполнены, тест объявляется пройденным и ему присваивается результат "PASSED".

Пример теста: 
================================= 
ТЕСТ: 
1. Сбросить клиент и базу данных. 
2. Добавить в базу 5 купонов: price=0, price=3, price=5, price=6, price=-1, 
3. Запустить синхронизацию 
4. Проверить что первый купон - с 0 монетами на купоне, второй - с тремя, третий с пятью, четвертый монеты не отобразил, пятый купон не показался на клиенте. 
=================================

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

На Рис. 8 представлен результат работы тестовой системы для одного из тестов:

Рис. 8

Для автоматизации процесса тестирования была создана система, схема которой изображена на Рис. 9.

Рис. 9

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

В итоге, разработанная система позволила значительно сократить время на тестирование одного клиентского приложения – с 5 часов до 20 минут.

 

Процесс контроля качества во время эксплуатации системы

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

 

Рис. 10

Как видно из Рис. 10, процесс контроля качества здесь начинался с этапа регулярных инспекций кода. На этом этапе, каждый «опасный» участок кода программы оборачивался в try/catch блок, и при возникновении исключения в таком месте, создавалась запись в логах с тегом ERROR. При этом каждому try/catch блоку присваивается уникальный идентификатор.

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

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

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

 

 

Заключение

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

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

На момент написания диплома, разработанная  информационная система функционирует в режиме 24/7, продуктом можно воспользоваться.

 

Список литературы

 

1. Lessons Learned in Software Testing,  Cem Kaner, James Bach, Bret Pettichord. Wiley; 1 edition (December 15, 2001)
2. The Mythical Man-Month: Essays on Software Engineering,  Frederick Brooks, Addison-Wesley, 1995
3. Testing Extreme Programming, Lisa Crispin, Addison-Wesley Professional; 1 edition (November 4, 2002)
4. Succeeding with Agile: Software Development Using Scrum, Mike Cohn, Addison-Wesley Professional; 1 edition (November 5, 2009)
5. Information Systems Today: Managing the Digital World (4th Edition), Joseph Valacich, Prentice Hall; 4 edition (March 13, 2009)
6. Mobile Application Security, Chris Clark, McGraw-Hill Osborne Media; 1 edition (January 15, 2010)

 

 

 

¹ http://internet2go.net/news/data-and-forecasts/global-survey-offers-more-data-shopping-and-smartphones

² http://stepandstep.ru/catalog/your-news/119330/v-sankt-peterburge-testiruetsya-sistema-oplaty-metro-s-pomoschyu-mobilnogo-telefona.html

³ http://kuban.kp.ru/daily/25693/896779/

⁴ http://www.adme.ru/research/romir-monitoring-bolee-poloviny-rossiyan-starayutsya-poseschat-tolko-te-magaziny-diskontnye-karty-kotoryh-u-nih-est-romir-monitoring-14672/

⁵ http://www.cityspb.ru/goto/153393/

⁶ http://smartkupon.ru

⁷ http://www.mdsrussia.com/card.html

⁸ http://www.cardmobili.com/

⁹ http://www.cellfire.com/whatiscf.php

¹⁰ http://www.mycardstar.com/

¹¹ http://www.youtube.com/watch?v=ML2Vd3zPHKk

¹² http://www.starbucks.com/coffeehouse/mobile-apps/starbucks-card-mobile

¹³ http://www.pcworld.idg.com.au/review/mobile_phones/dominos-pizza/iphone_app_v1_1/326167

¹⁴ http://www.marketingweek.co.uk/subway-launches-mobile-device-loyalty-scheme/3014085.article

¹⁵ http://www.crunchgear.com/2010/12/27/carls-jr-and-hardees-lead-the-way-in-interactive-iphone-check-in-social-rewards/

¹⁶ http://www.pcworld.idg.com.au/article/339382/ipizza_pizza_hut_launches_iphone_app/

¹⁷ http://goo.gl/ygRGJ

¹⁸ http://malina.ru/promo/mobilecardnew

¹⁹ http://smr.newswire.ca/en/air-miles/new-air-miles-mobile-application

²⁰ http://en.wikipedia.org/wiki/Loyalty_program

²¹ http://en.wikipedia.org/wiki/Mind_map

²² http://comapping.com

²³ http://jakarta.apache.org/jmeter/