Большинство IT-компаний не делают версии своих продуктов под Windows Phone, потому что доля мобильной операционной системы от Microsoft меньше, чем у iOS и Android. Тем не менее, это третья крупнейшая мобильная операционная система на рынке, и в Badoo Windows Phone приложение уже давно существует.
Изначально оно было написано аутсорсным разработчиком на Silverlight и долгое время не обновлялось, и несколько лет у продукта не было выделенного отдела. В 2014 году в компанию пришел разработчик Windows Phone и стал поддерживать это приложение, а я стал получать на тестирование некоторые его задачи.
Через пару месяцев было решено написать полностью новое приложение, забросив почти все старые наработки во многом потому, что код был далек от идеала, а на его поддержку тратилось очень много времени. Первым новым приложением для Windows Phone стал экспериментальный проект Badoo Hot or Not. По концепции он очень похож на Badoo, но в нем гораздо меньше функционала и он несколько отличается. Всего за 3 месяца мы вдвоем сделали приложение Hot or Not с нуля в одной ветке Git-репозитория, которую в итоге замержили в Master. А приложение TeamCity было настроено так, что каждый коммит разработчика собирался как отдельное приложение, что позволяло мне, как тестировщику, видеть историю изменений клиента.
Спустя несколько релизов Hot or Not мы вернулись к разработке Badoo, решив сделать оба приложения с общим ядром. Это значило, что у Hot or Not и Badoo будут общий Git-репозиторий и общий проект Visual Studio. В то время, помимо Windows Phone 8, мы все еще поддерживали Windows Phone 7. А из-за специфики Visual Studio получалось, что это два совершенно разных приложения, и на мне было 2 проекта, каждый из которых состоял из двух приложений. Для одного тестировщика это достаточно много и, скорее всего, мы бы сделали большое количество ошибок при использовании старой схемы разработки, когда на один релиз у нас была одна ветка в Git. И мы начали думать, как улучшить процесс разработки.
В ходе размышлений мы выдвинули два главных требования к рабочему процессу:
- во-первых, тестировщики и разработчики не должны блокировать друг друга. Нас было всего двое, и если бы один блокировал работу другого, то половина команды не работала бы;
- во-вторых, каждая задача должна проверяться несколько раз на разных этапах (лучше разными людьми).
Мы обратили внимание, что наши команды мобильной разработки для iOS и Android используют Git Flow. Это достаточно большая система, в которой тестирование делится на три этапа.
Изначально есть две Git-ветки: Master и Dev. Первый этап тестирования — это фича ветки. Разработчик создает новую Git-ветку из ветки Dev, делает в ней клевую функциональность и отдает ее на тестирование. Когда задача проверена и с ней все хорошо, она мержится обратно в ветку Dev.
Когда таким образом в Dev мержится некоторое количество задач, к примеру, 10, то приходит время для второго этапа тестирования — интеграции. Тут задачи тестируются на наличие багов, которые появляются из-за интеграции нескольких веток между собой. Проблемы, найденные на этом этапе, исправляются в первом приоритете прямо в интеграционной ветке.
Последний этап тестрования проходит перед тем, как вы хотите опубликовать вашу новую версию приложения в магазин. Это релизное тестирование. Он похож на интеграционное тестирование. Баги, найденные в релизе, тоже имеют самый высокий приоритет. Когда проверены все задачи этого релиза, проведено релизное тестирование и приложение опубликовано, релизная ветка мержится в Dev и Master.
Git Flow очень интересная и хорошая система, которая подходит для больших команд разработки iOS и Android (у нас в каждой более 15 человек). Но одному тестировщику и одному разработчику работать с ней было бы слишком сложно, и мы решили убрать первый этап тестирования, а получившуюся систему назвали “Windows Phone Team Flow”.
Благодаря этому мы успешно зарелизили новое приложение Badoo всего через 3 месяца после начала разработки.
2015
В 2015 году наша команда увеличилась в 2 раза — мы наняли еще разработчика и тестировщика, что достаточно странно, ведь классическое соотношение тестировщиков к разработчикам это 1/3. Но у нас были на это причины:
- У нас почти нет автоматизации. Сейчас она находится на начальном этапе развития и фактически все проверки мы делаем вручную.
- У разработчиков есть отличные стандартные библиотеки от Microsoft, которые вкупе с библиотеками Telerik позволяют разрабатывать новые UI-интерфейсы очень быстро. Дизайн Windows Phone очень простой, и мы стараемся избегать сложной анимации. Все это позволяет нашим разработчикам делать больше за меньшее время.
- Из-за большого количества экспериментов мы создаем больше новых функций в приложении, чем наши большие команды разработки, хотя нас и меньше.
Эксперименты
Благодаря быстрой скорости доставки новых версий пользователям лучшая в нашей компании платформа для экспериментов — это веб. У нас настоящий continuous integration: 2 раза в день мы выкладываем новый билд на продакшн, и каждая выкладка занимает меньше минуты. Но сегодня мобильная индустрия развивается семимильными шагами, и все большее количество пользователей предпочитают мобильные приложения. Поэтому приоритет компании сместился на мобильные платформы. И появилась большая проблема. Результаты экспериментов, запущенных на веб, в большинстве случаев оказываются непригодными в реалиях мобильных клиентов, поэтому для экспериментов нужна специальная мобильная платформа.
Чем Windows Phone хорош для экспериментов?
Пусть количество пользователей нашего мобильного ресурса на Windows Phone всего 3% от общего числа, в день их все равно сотни тысяч. Такое количество позволяет запускать A/B тесты или даже A/B/C/D тесты, где они поделены на 4 группы, включая контрольную. С другой стороны, пользователей не так много, чтобы, в случае ошибки, они могли повлиять на активность большого числа пользователей. Снижение активности же на большой платформе повлечет за собой заметное снижение активности всего ресурса.
В отличии от iOS, где время ревью в AppStore состовляет неделю или даже две, по нашему опыту, ревью в Windows Phone Store занимает всего лишь 20 минут. Согласно Microsoft, через 16 часов приложение будет доступно для загрузки по всему миру. А по нашему опыту, всего через 2 часа его можно будет скачать на всех значимых для нас рынках. Это означает, что Windows Phone обладает быстрой скоростью доставки новых версий приложений. 60% пользователей обновятся в течении 24-х часов.
У Android очень большая фрагментация аппаратного обеспечения, устанавливаемого в мобильные телефоны. Плюс каждый вендор создает свою версию этой операционной системы, при этом изменяя ее основы. Microsoft же задали жесткие ограничения для железа, используемого в телефонах, а сторонние версии Windows Phone ОС отсутствуют. Поэтому у нас почти нет багов, зависимых от операционной системы или аппаратного обеспечения.
Windows Phone ОС была разработана уже после запуска iOS и Android. И имеет одно большое отличие — это графический интерфейс. Metro-дизайн сильно упрощен, в отличие от iOS и Android ОС. То, что было округлым, становится квадратным. В ней почти отсутствует сложная анимация. С другой стороны, это все та же мобильная операционная система с многозадачностью и сенсорным экраном. И приложения для всех этих операционных систем могут выглядеть абсолютно одинаково.
Благодаря всем вышеописанным плюсам Windows Phone мы стали мобильной экспериментальной платформой. Наша команда быстро реализует идеи продакт-менеджеров и, собрав статистику, мы определяем, успешен ли этот функционал. Если все хорошо, эта идея отдается на разработку в команды iOS и Android, которые реализуют этот функционал по обычному «флоу». Если же статистика говорит, что у идеи есть какие-то проблемы, наш продакт-менеджер думает, как ее доработать. Придумывает, мы дорабатываем и запускаем снова. Если же ничего не помогает, то мы просто убираем этот функционал из клиента. За 2015 год, благодаря экспериментам, мы реализовали 55 новых фич, что позволило существенно увеличить доход от мобильных платформ.
Что помогло нам достичь таких результатов?
В каждой из команд переводчиков, дизайнеров, разработки мобильного сервера и разработки биллинга есть люди, которые занимаются задачами наших экспериментов в первую очередь. Это позволяет нам создавать новый функционал быстрее.
Мы все еще остаемся маленькой командой, у которой нет проблем с общением. У нас почти нет «митингов», ведь обсудить задачу мы можем сразу, не покидая рабочего места. Специально мы собираемся только раз в неделю, чтобы вместе с продакт-менеджером обсудить недельный релизный цикл.
В нашей компании тест-кейсов нет совсем. Потому что на их разработку и поддержание тратится колоссальное количество времени. Кроме того, работа человека по инструкции уменьшает желание проводить какие-либо исследования и эксперименты, а ведь тестирование — это творческий процесс. Тем более в экспериментальной команде, где каждую неделю мы создаем по несколько новых фич. Вместо тест-кейсов мы используем заметки, разделенные по фичам, в которых можно найти все что угодно, к некоторым из них прикреплены майнд карты, которые позволяют увидить взаимосвязь между компонентами приложения и их входные параметры.
Утилиты
В Badoo было создано очень большое количество различных утилит, которые помогают тестировать и разрабатывать быстрее, далее мы рассмотрим основные из них.
Интерфейс просмотра серверных логов
Я уверен, что почти каждый тестировщик сталкивался с ситуацией, когда нужно определить, на чьей стороне баг — клиентской или серверной. И для упрощения этой задачи мы создали очень удобный интерфейс просмотра серверных логов, который позволяет увидеть их отфильтрованными по ID пользователя или устройства, а также логи в реальном времени или историю. Дополнительно можно добавлять разделители, скрывать или показывать различные его части.
QаAPI
Иногда бывает сложно подготовить тестовый аккаунт или тестовое окружение для воспроизведения проблемы. К примеру, вам нужно проверить, как выглядит и работает письмо, приходящее на почту пользователя через неделю после регистрации. Реальный тест-кейс выглядит так: зарегистрировать новый аккаунт, подождать неделю, получить письмо и наконец-то его проверить. Но это слишком долго, и первой мыслью тестировщика будет пойти к серверному разработчику и попросить изменить что-нибудь в базе данных, чтобы он мог получить письмо побыстрее. Но отвлекать разработчиков по таким мелочам неэффективно, К тому же, подобных «мелочей» может быть очень много. И для того чтобы все были счастливы, мы создали QaAPI. Это собрание API-методов, которые позволяют быстро подготовить тестовое окружение или аккаунт. В случае с письмом, которое отсылается через неделю после регистрации, достаточно было бы запустить один QaAPI-метод, чтобы получить письмо в течении секунды. Подробнее про QaAPI вы можете узнать из доклада Дмитрия Марущенко.
Server Mock
В нашей компании сервер разрабатывается обычно быстрее, чем мобильные клиенты. Но, из-за быстрой скорости разработки в Windows Phone, у нашей команды есть проблема — нельзя тестировать и разрабатывать новый функционал, потому что сервер не готов. Для того чтобы избавиться от такой проблемы, был создан интерфейс под названием Server Mock. Он позволяет создавать специальное тестовое окружение, в котором на заданные клиентские запросы сервер возвращает заранее определенные ответы. Это стало возможно благодаря протоколу, который разрабатывается при обязательном участии всех серверных и клиентских команд.
Про разработку веба, мобильных клиентов в общем и протокола в частности Вы можете узнать в докладе Павла Довбуша.
Badoo Internal App Store
Помимо приложений, публикующихся в магазины приложений, у каждой нашей мобильной команды разработки есть еще по одному приложению, которые мы называем «внутренними магазинами приложений». Они позволяют устанавливать тестовые билды клиентов без установки xCode для iOS, Visual Studio для Windows Phone OS и Android SDK для Android OS. В ситуациях, когда ваш продакт-менеджер хочет изучить работу нового функционала, который в скором времени будет «зарелизен», или дизайнер хочет посмотреть, как выглядит этот новый функционал, или же переводчик хочет узнать, как выглядит только что переведенный текст на настоящем телефоне, достаточно просто выбрать и установить нужную сборку приложения.
Debug_menu
В каждой тестовой версии наших приложений есть большой раздел Debug_menu. К примеру, в Windows Phone Debug_Menu можно посмотреть клиентский лог, отправить его по имейлу, очистить кэш фотографий или же общий кэш, при желании можно даже закрашить приложение. В общем, возможностей, облегчающих тестирование и разработку, масса.
Статистика
Как я уже писал ранее, на Windows Phone в нашей компании ставят много экспериментов, а для того чтобы понимать результаты этих экспериментов, мы собираем много статистики.
HotPanel
У нас есть собственная утилита для статистики, которая разрабатывается отдельной командой с названием BI-team (business intelligence team). Наличие такой команды позволяет создавать полностью конфигурируемую статистику, которая будет удовлетворять нуждам наших продакт-менеджеров.
AppAnnie
Для быстрой реакции на проблемы, о которых сообщают пользователи, оставляя отзывы в мобильных магазинах приложений, мы используем AppAnnie. Это сервис, который собирает и обрабатывает оценки и отзывы в AppStore, Google Play и Windows Phone Store.
HockeyApp
Одной из главных метрик успешности новой версии приложения является «крашрейт». И для сборов краш-логов от реальных пользователей мы используем HockeyApp.
Ключевые графики
Также у нас есть большое количество графиков, показывающих ключевые метрики нашего ресурса, например, активность голосования пользователей, авторизации, количество активных пользователей и прочее.
Пару месяцев назад мы реализовали новую задачу Double Tap To Like. На одном из наших главных экранов приложения «Люди рядом», где присутствует большое количество профилей пользователей, достаточно два раза «тапнуть» по иконке пользователя, чтобы Badoo автоматически засчитал позитивный голос за него. Запустив эту фичу, мы ожидали, что многие пользователи начнут активно голосовать. Собрав статистику, мы узнали, что у большинства пользователей активность голосования действительно увеличилась, у женской аудитории ресурса возросла даже общая активность, при этом у мужской части ресурса общая активность упала. Поэтому мы решили оставить Double Tap to Like только для девушек и отдали ее на реализацию командам iOS и Android. Этот пример в очередной раз доказывает, что статистика очень важна для принятия решений об успешности экспериментов.
Это, пожалуй, все методы и утилиты, про которые нам хотелось вам рассказать. Все вместе и каждая в отдельности, они способны значительно ускорить процессы разработки и тестирования мобильных приложений. Проверено на Badoo. Теперь ваша очередь!
Вячеслав Локтик
Senior Mobile QA Engineer (Windows Phone)
Автор: Badoo
