Статья подготовлена на основании доклада Юлии Горловой на конференции SQA Days-15.
Презентация: www.slideshare.net/VLDCORP/ss-33705537
Задача — необходимо поддержать как можно больше различных конфигураций: в тестировании несколько платформ, для каждой платформы несколько версий операционной системы, для каждой платформы несколько размеров экрана и разрешений. Девайсов получается очень много, а тестирование только ручное.
В данной статье я расскажу про несколько приёмов, которые позволяют прозрачно и просто решить эту задачу.
Исходные данные: только ручное тестирование, без автоматизации.
Проблема: хотим качественно тестировать продукт, при этом укладываться в сроки.
Почему это является проблемой? 2ГИС – это подробный и актуальный справочник организаций с детальной картой города
Во-первых, в мобильном приложении очень много функционала. Во-вторых, большое количество пользователей (8,5 млн.) В-третьих, мы поддерживаем основные четыре платформы (iOS, Android, Blackberry, MeeGo). Последние две поддерживаются частично (это портирование версий с Android’a). В основном, в статье будет идти речь об iOS и Android.
Мы стремимся обеспечить максимальный комфорт пользователям, стараемся, чтобы все работало на всех версиях операционных систем, конечно, с определенными разумными ограничениями.
Проблема усугубляется малым количеством тестировщиков: тестированием внешних продуктов занимается два специалиста. Применяется только ручное тестирование.Так исторически сложилось, потому что изначально приложение создавали под Symbian, потом расширили на WinCE, и позже добавили Android. После этого отказались от WinCEи Symbian, и добавили iOS. Мы отказались от активной поддержки WinCE и Symbia, но как приложения они существуют. Все приложения имеют общие внутренние части; там огромная сложная и витиеватая архитектура, которую когда писали, не закладывали под автоматическое тестирование. Поэтому есть части приложения, которые невозможно автоматизировать, либо они повлекут огромные затраты по реализации. Нам это не нужно и не выгодно. Поэтому продолжаем тестировать вручную.
И поскольку мы — мобильное приложение, мы должны быть динамичными, быстро реагировать на все происходящее вокруг, давать людям постоянно новые фичи; мы стараемся придерживаться минимальных сроков релиза. Это примерно один месяц. Быстрее мы не можем, к сожалению, именно из-за того, что у нас достаточно сложная внутренняя часть, и фичи — довольно большая штука, которую надо тщательно протестировать. Быстрее не можем, но дольше тоже не хотим. Мы стараемся укладываться в месяц, но иногда это бывает достаточно сложно.
В итоге, у нас стандартная проблема, с которой сталкиваются очень многие люди: мы хотим уложиться в сроки и не пожертвовать при этом качеством.
Что для нас качество? Это — очень широкое понятие, и все его трактуют по-своему. Мы, когда думаем о качестве, представляем такую картину: что в сторах (store) люди жалуются только на то, что в 2ГИС еще нет их города. Никаких других проблем с продуктом у них не возникает. Это — то, к чему мы стремимся.
5 решений, которые мы используем в своем продукте.
Администрирование
Как взаимодействовать с девайсами, чтобы в итоге все было хорошо?
Например, мы придерживаемся простого правила: когда тестировщик идет домой, он должен все девайсы, с которыми он работает, поставить на зарядку. Потому что иначе утром: Android разрядился, не с чем работать. Надо избегать таких ситуаций. Казалось бы, это — элементарно, но данная вещь помогает экономить время и облегчает процесс работы.
В тестировании используется больше 30 устройств. Мы стараемся для всех мажорных версий держать свои девайсы, и не обновляем их, т.к. дорожим ими. Поэтому скапливается много девайсов. А так же мы докупаем различные топовые девайсы, чтобы на них убедиться, что все работает. Сейчас уже у нас около 37-40 устройств в активной работе. И среди них надо найти то, что нужно. Это — важная задача.
У нас есть большая стойка с девайсами. Что с ними делать? Перебирать каждый? Мы решили эту проблему созданием электронной таблицы, в который указаны все основными характеристики. В таблицы есть определенные поля. Мы заносим каждый новый девайс сразу в эту таблицу, указываем его характеристики.Некоторые характеристики остались, как наследие еще от прошлых платформ, например, магнитный компас и тачскрин (от Symbian). Некоторые появились недавно, например, поддержка OpenGL.
Среди этих полей, операционная система — самая важная штука, чтобы с точностью до 3 цифры мы могли найти точную версию. Иногда это очень важно.
Синдром вахтера
При этом мы еще практикуем такую вещь, как ведение листочка учета. Например, кто-то из другого отдела берет девайсы, мы хотим чтобы потом нам их вернули. Чтобы девайсы не терялись, мы как настоящие вахтеры, стали это записывать. Что-где-кто-куда, а потом соответственно выписываются. Если девайс забирают надолго, мы ставим определенную пометку в таблице возле названия девайс; тогда сразу видно, что данного девайса сейчас нет.
Стойка для хранения девайсов.
Разработчики пытались ее оптимизировать и заменить на шкаф, но не соглашайтесь. Шкаф хуже, потому что у него есть дверцы, и вам придется их открывать. А это не очень удобно. На стойке с рабочего места видно, где что лежит. Скорей всего, вы всех их знаете в лицо, например, Android’ы достаточно легко отличить, т.к. они все разные. Есть куча зарядок, и ничего лишнего.
iPad’ы.
2й и 3й iPad’ы невозможно отличить. Нет никаких пометок, ничего не написано.Мы пытались запоминать обои, вглядывались в экраны: ретина или не ретина. Но в итоге это все надоело, и мы придумали писать на самом iPad’е на экране блокировки указывать все его характеристики. Ткнул одну кнопку и сразу все узнал про девайс. Почему мы не делаем такого для iPhone’в.Потому что их легко и просто отличить. Например, как отличить 4 от 4s? Элементарно. У 4s есть полосочка на боку корпуса.
Перейдем к процессной части.
Управление билдами
Как мы организуем процессы. Во-первых, у нас не кроссплатформенное приложение. Для каждой платформы мы создаем свое приложение, оно собирается отдельно, и имеет свои отдельные части. Мы так решили, т.к. есть опыт, говорящий о том, что пользователи очень любят нативный дизайн.
Как мы это поняли? У нас раньше был дизайн, который разрабатывался для Symbian’a в первую очередь. Он был универсальным и использовался на Android, WinCEи Symbian, и мы получали очень много отзывов, что он неудобный. Мы сделали полный редизайн, когда добавили iOS. Было понятно что старый дизайн не перенести на iOS. На Android он остался примерно таким же, перенял основные черты, единственное, что мы добавили — это стандартное выпадающее меню. На iOS мы используем привычные пользователям элементы, такие как тачбар, например. Соответственно получается нативный дизайн и там, и там.
Во-вторых, приложение написано на С++. Мы не пишем на Objective-C или Java, только С++. Он взаимодействует с системой на уровне ядра. Мы работаем с ядром и с системными библиотеками, и поскольку системы разные, то и приложения разные.
Для каждой платформы у нас свой билдсервер. Это позволяет нам избегать каких-то простоев в тестировании. Все, наверно, сталкивались с ситуацией, когда вы приходите утром на работу, а билдсервер по неведомым причинам не работает.В этом случае всегда есть запасной вариант: второй билд сервер с другим приложением, которое вы можете брать и тестировать. Это несильно, но оптимизирует процесс нашей работы.
Вот мы собрали приложение на билдсервере, нашли нужный девайс, хотим на него поставить сборку. Для этого есть самый простой вариант: берем телефон, берем сборку, подключаем, закидываем, отключаем, устанавливаем, запускаем, все вроде хорошо, но долго.
Вот если у вас 10 девайсов и одна сборка, и ее надо поставить на все устройства, то что делать? Каждый подключать долго и неудобно. Мы решили, что хотим делать это быстро.
И мы прикрутили ко всем билдсерверам QR-коды. Для каждой сборки генерируется QR-код, который можно скачать любым reader’ом, он у вас появится в трее, вы его ткнете, он установится. Все. Это гораздо быстрее, потому что не нужно ничто никуда подключать. Раньше было только для Android, а теперь и на iOS.
Сбалансированное тестирование
Все настроили, все поставили, готовы к тестированию. Какие еще могут быть подводные камни?
Поскольку приложений два, надо тестировать не одну фичу, а две. Чтобы это сделать, мы обычно распараллеливаем данный процесс, это позволяет нам находить общие баги для всей фичи, чтобы разработчик не тратил время на дублирование своей работы. Если фича общая, ее починят сразу в обоих местах. Если она реализована по-разному, но проявляется одинаково, то разработчик починит сразу в двух местах и ему не придется дважды возвращаться в один и тот же контекст. Также мы находим какие-то специфические проблемы. В итоге получается более тщательно протестированная фича.
Всем известно, что Android’ов много, очень много. Огромное количество девайсов, у каждого свой размер экрана, разрешение и т.п. И все эти миллионы устройств надо как-то протестировать.
Для миллионов экранов Android’a мы сделали пять стандартных тем. Для каждого девайса автоматически выбирается оптимальная тема (по длинной стороне экрана, их 5 штук, и эти 5 штук мы может протестировать). Можно прогнать на самых узких, самых широких экранах и посмотреть, что все корректно отображается.
Важно следить, что мы не разряжаем пользователю телефон. Все, конечно, знают, что Android имеет свойство разряжать телефон. Наша задача не усугубить ситуацию, чтобы телефон не разряжался еще быстрее, потому что люди пользуются 2ГИС-ом.
Мы заранее планируем тестирование расхода заряда батареи с упором на новые фичи и на старые критичные места. Стараемся проводить такое тестирование перед каждым релизом.
iPad. Предыстория: когда мы только выпустили полноценную поддержку iPad’a, она была только вертикальной. Пользователи писали, что неудобно пользоваться и просили включить поворот. Поворот экрана на iPad — это не просто одна галочка в настройках. У нас layout немного нестандартный, было много проблем с версткой, это — узкое место, поэтому закладываем заранее время на тестирование. Стараемся включать в план сессии свободного тестирования на iPad-ах с упором на верстку. Мы применяем свободное тестирование, т.к. код сложный, и часто работает по принципу: “Купил хлеба — перестала открываться балконная дверь по вторникам”. Поэтому просто функционального тестирования не хватает.
Предустановка на Android. Сборка Android’a устанавливается на заводах-производителях на телефон, как дефолтное приложение. Это порядка десяти вендоров. В процессе тестирования помимо сборки для сервера обновлений, сборки для Google Play, необходимо сделать более 10 сборок для вендоров и в идеале все надо проверить.
Мы прикрутили на билдсервер скрипт, который собирает эти сборки одним нажатием. Сборки получаются абсолютно идентичными, различны только те места, которые отличают одну о другой. Мы можем просто запустить сборку, проверить этот ключ, а так как они одинаковые, не надо целиком тестировать каждую. Если они запускаются, значит они корректно собрались. На нескольких сборках делаем полный прогон функционала, чтобы не тестировать на всех.
Когда мы закончили с функциональным тестированием, у нас начинается верификация и регрессия. Есть проблема с App Store’ом, там нельзя просто взять и выложить приложение. Его надо отправить, 4 дня в среднем оно будет в очереди и аппрувиться, чтобы попасть в стор. То есть сперва мы делаем все для iOS-ной сборки. С BlackBerry не так критично, т.к. он может выйти с опозданием, потому что он не флагман. iOS важно выпустить вовремя. Если случилось так, что поджимают сроки, багфиксинг затянулся, мы сначала отправляем сборку в App Store, а потом начинаем регресс. Если мы не находим баги, то все хорошо, а если найдем, то успеем поправить, и не выпадем из очереди.
Если релиз должен был быть вчера, мы пишем письмо в App Store с просьбой заапрувить нас без очереди. Они иногда позволяют так сделать. Но этим способом лучше не пользоваться, он только для экстренных ситуаций.
Бета-тестирование
Иногда нам нужно больше девайсов, чем есть возможность приобрести и держать в офисе. Например, когда мы выпускали поддержку OpenGL на Android, мы столкнулись с проблемой, что мы очень сильно зависим от железа и прошивок.
У нас была грустная ситуация на Android, что на старых и слабых устройствах мы работали быстро, а на больших и топовых мы работали медленно, так как экраны большие и надо обрабатывать очень много пикселей, и из-за этого возникали проблемы. Эти проблемы мы решили подключением аппаратного ускорения.
Было много сложностей, поэтому пришли к бета-тестированию. Мы сделали его двух этапным.
Первый этап проводился внутри компании.Было необходимо собрать самые большие проблемы. Данный этап оправдал свою цель: мы составили черный список девайсов, которые не будут поддерживать OpenGL в нашем приложении. Починили все, что могли, и выпустили внешнюю бету.
Внешнюю бета — сборку в состоянии финальной готовности опубликовали в Google Play. Он предоставил возможность публиковать общедоступные бета-релизы. Для этого надо было создать группу в Google+, разместить приложение, дать ссылку пользователям, и они могли скачать приложение.
Мы разместили статью на хабре о том, что нужна помощь в бета-тестировании. Приняло участие около 3,5 тысячи подписчиков, они принесли много специфических проблем. Мы отладили все, что могли.
Это дало нам дополнительные бонусы, например, когда случаются специфические проблемы, то пользователи возвращаются и говорят нам об этих проблемах.
Текущая поддержка
Наше приложение входит в топ, и мы хотим держать позиции, поэтому необходимо не только быстро тестировать, но и быстро реагировать на проблемы. Если что-то пошло не так, в маркетах видно сразу. У нас очень много пользователей, и 1% людей с проблемой это примерно 85 тысяч пользователей с проблемой.
Типичный отзыв в маркете (обычно не передает суть): “Все сломалось, почините!”.
Реализована связь с техподдержкой через приложение. Можно зайти в “О программе” и написать разработчику, и в письмо вставляет лог с кучей полезной информации. Мы “лечим” даже частные случаи для определенного девайса с конкретной прошивкой. Присылаем пользователю новую сборку, и все начинает работать.
В результате, вся эта информации может вам пригодиться, если вы работаете с ядром, у вас Android, и не только Android, и если нет автоматизации. Соответственно сокращайте сопутствующие расходы времени.
Автор: Polazhenko
