Custom Debug Menu: как сберечь время и нервы команде разработки
Я — Адина Шарипова, mobile QA-инженер Kolesa Group. Расскажу о том, как ускорить и упростить процесс разработки. И поделюсь тем, как частично получить независимость от постоянного дебага приложения через добавление персональных инструментов разработчика в свои приложения.
На реальных кейсах рассмотрим, что было сделано для оптимизации работы тестировщиков и разработчиков.
Но для начала давайте представим упрощенный процесс разработки продукта: разработка и тестирование. В отдельных случаях обходятся и без тестирования. Но если вы работаете по классической схеме «разработка → тестирование», то наверняка знаете, что в процессе разработки приходится настраивать окружение, подготавливать необходимые данные и инструменты для тестирования. И почти всегда этот процесс занимает много времени, сокращая тем самым время на само тестирование.
Мы можем оптимизировать этот процесс. Например, некоторые инструменты можно вынести и дать к ним быстрый доступ в Debug Menu (другие названия: Dev Options, режим разработчика) — это панель инструментов, доступных для разработчиков, которая скрыта от пользователей на продакшн.
Мы добавили модули Debug в наши приложения и в iOS, и в Android.
Они немного различаются внешне, но по функционалу схожи. Есть небольшие исключения, но это больше из-за особенностей платформ. Главное, что к модулю есть быстрый доступ.
Наверное, у вас уже возникли такие вопросы и возражения, как:
- Зачем тратить время команды на добавление не продуктового кода в приложения?
- У нас не хватает ресурсов!
- У нас совсем другие процессы и продукт, и эти инструменты нам не подойдут.
- На это нужно выделять время, а сроки итак горят!
Постоянные рутинные действия никуда не денутся, если их не оптимизировать. А cроки горят всегда, потому что бизнес требует как можно быстрее доставить фичу на продакшн.
На примере 6 ситуаций, с которыми каждый день приходится сталкиваться при разработке продуктов Kolesa Group, я покажу примеры рутины и как мы ее сократили с добавлением debug menu.
Мои цели:
- Сократить время на подготовку к тестированию и разработке;
- Упростить получение тестовых данных;
- Ускорить кастомную настройку сборки.
Ситуация №1
Тестируем backend и frontend
Наши приложения обращаются во множество endpoint-ов. Тут представлена лишь малая часть того, куда обращается за данными приложение Krisha.kz.
При установке приложение по умолчанию ходит в мастер-хосты на тестовом окружении и продакшн-хосты в продакшн-окружении, и получает необходимые данные.
Когда возникает необходимость проверить как изменения, сделанные на backend, отражаются на приложении, мы собираем кастомные веточки приложения с нужными хостами.
Раньше
Было два варианта, оба приносили немало боли и разработчику, и тестировщику. Рассмотрим их:
Вариант 1
- разработчик собирает приложение с нужными endpoint-ами;
- передает на тестирование;
- после тестирования надо вернуть эти изменения обратно разработчику;
- вернуть endpoint-ы на мастер;
- только после этого можно замержить изменения.
Вариант 2
- у тестировщика должны быть установлены Xcode и Android Studio;
- нужен доступ к проекту;
- собираем проект;
- меняем endpoint-ы в проекте;
- ждем пока соберется;
- тестируем;
- после этого можно замержить изменения.
Сейчас
Мы облегчили эти пути и вывели в Debug menu список всех url, в которые обращается приложение и получает необходимые данные.
Теперь у нас есть возможность изменять url с мастер веток на кастомные ветки разработчиков прямо в приложении.
После перезапуска приложение начинает ходить по указанным нами хостам. И мы можем проверить изменения на нужных ветках.
Результат
- теперь не нужно никаких доступов к коду, чтобы прописать нужную ветку;
- не нужны инструменты разработчика;
- не нужно возвращать ветку разработчику для сброса хостов в мастер после тестирования, можно сразу мержить изменения.
Если раньше мы тратили 60 минут, то теперь переключение между ветками занимает 5 минут.
Ситуация №2
Разобраться на чьей стороне ошибка?
Теперь разберем ситуацию, когда все также нет доступа к коду, и при работе с приложением появляется ошибка.
Скорее всего человек, столкнувшийся с проблемой, пойдет мучить первого попавшегося разработчика.
Раньше
Путь к локализации ошибки раньше был примерно таким:
Все эти действия отнимали от 15 минут до нескольких часов.
Сейчас
Мы добавили журнал сетевых логов в наши приложения. Журнал состоит из списка запросов приложения на backend-ы.
Помимо списка запросов можно отслеживать время, метод, статус запросов, какие заголовки содержатся в запросе.
Для удобства мы также добавили возможность поиска нужных логов через поисковую строку, очищать и шэрить через кнопку «поделиться».
Результат
Таким образом мы:
- сократили время на локализацию ошибки от нескольких часов до нескольких минут;
- лучше разбираемся в запросах: какой код и текст ошибки мы получили по определенному запросу;
- заводим понятные задачи на исправление багов со всей необходимой информацией.
Если раньше мы тратили 70 минут на локализацию ошибки, то теперь этот процесс вместе с заведением задачи, занимает 10 минут.
Как настроить логи?
Для получения быстрого доступа к логам сети мы использовали готовые библиотеки Wormholy для IOS и Chucker для Android.
Считаю, что этот инструмент будет полезен всем, вне зависимости от функций вашего приложения. Подробнее про интеграцию можно узнать, перейдя по ссылкам выше.
Ситуация №3
Нужно изменить хэдеры в запросах
Хэдеры (заголовки) — основная часть этих HTTP-запросов и ответов. Они помогают отправлять дополнительную информацию о клиенте, сервере, запрошенной странице и многом другом.
Рассмотрим на примере проверки актуальности версии приложения:
Раньше
Сейчас
Мы снова упростили этот путь и вынесли возможность добавлять, менять ключи и значения хэдеров в Debug Menu.
Заданные хэдеры сохраняются между запусками приложения. И будут отправляться со всеми запросами из приложения во все endpoint-ы.
Так мы:
- не тратим свое время на ожидание сборки;
- не создаем лишнюю очередь в CI/CD для других.
Результат
Если раньше на изменение хэдеров в запросах мы тратили около 40 минут, то теперь процесс занимает всего 5 минут.
Ситуация №4
Нужно отправить push-уведомление
Наверняка все хоть раз в жизни получал маркетинговый push от какого-нибудь приложения с текстом «Тест пуш» или «123».
Чтобы НЕ отправить рассылку на всех пользователей в продакшн, при создании push-рассылки в AppMetrica есть возможность отправлять push на тестовое устройство. Для этого нужно знать рекламные идентификаторы вашего устройства.
Для определения идентификатора на iOS, потребуется установить сторонние приложения. Получается целое приложение на всех тестовых устройствах для получения рекламного идентификатора.
На Android полегче: рекламный идентификатор можно получить в настройках телефона, перейдя в Google>Реклама.
Или еще один пример — тестирование персональной рассылки.
Для отправки рассылки одному пользователю, а не всем, необходимо знать токен авторизации юзера.
Узнать свой токен авторизации можно несколькими способами. И сейчас я не буду рассказывать о том как это сделать. Так как об этом есть много информации и документации. Просто подытожу.
Раньше
Для отправки push-уведомления приходилось каждый раз искать способ и софт для определения необходимого идентификатора. Это отнимало 15–40 минут.
Сейчас
Мы вынесли нужные нам идентификаторы на отдельный экран в Debug Menu.
Теперь добраться до необходимых идентификаторов можно легко и быстро, и отправить тестовый push, ведущий на нужный экран из appmetrica, firebase или postman.
Результат
Время на поиск идентификаторов сократилось с 30 минут до 1 минуты (даже до секунд).
Ситуация №5
Нужно проверить отправку событий аналитики
Для чего нужны события? События помогают узнать, как пользователи взаимодействуют с приложениями. Такие действия, как:
- отслеживание загрузок;
- клики по ссылкам;
- отправки форм;
- количество просмотров;
- деление пользователей на сегменты и эффективное взаимодействие с каждым сегментом.
На основе этих данных формируется дальнейшее развитие продукта. Стоит ли говорить о том, что если какие-то события дублируются или не отправляются, то это плохо скажется на продукте в целом.
Проверка в Firebase Debug View
Есть действующий DebugView в firebase, который позволяет видеть данные о событиях с вашего приложения на устройствах разработки почти в режиме реального времени.
Это полезно на этапе разработки и может помочь обнаружить ошибки в реализации аналитики, и подтвердить, что все события и свойства пользователей регистрируются правильно или уведомить, что не работает.
На iOS включить режим отладки на своем устройстве можно через добавление аргумента в Xcode при перед сборкой приложения, затем установить само приложение.
На Android потребуется установленный ADB, терминал и следующая команда с названием проекта. И это тоже занимает время.
У Appmetrica нет просмотра событий в реальном времени. События отображаются спустя определенное количество времени, поэтому сложно сегментировать конкретный тестовый девайс.
Если мы работаем с большим количеством данных, проверять доставку во все сервисы аналитики важно и нужно.
Но что если нужно проверить всего одно или несколько событий или измененный параметр?
Мы добавили просмотр логов событий кросс-продуктовой аналитики, отправляемых из приложения, находясь в самом приложении.
Теперь, чтобы проверить аналитику, не нужны никакие лишние доступы в сторонние сервисы и к коду.
Результат
Время на подготовку к проверке аналитики сократилось с 60 минут до 1 минуты.
Ситуация №6
Нужно проверить значения A/B-теста
В компании почти все новые фичи запускаются через A/B-тестирование.
Для конфигурации значений A/B-тестов используется инструмент Remote Config в Firebase.
Раньше
Есть свои особенности при проверке. Например:
- Нельзя определить какое значение получил ваш девайс, если A/B-тест уже запущен;
- При тестировании на iOS обновления данных нужно ждать 1 час. Либо переустановить приложение — этот вариант не всегда подходит.
Сейчас
Мы выгружаем все ключи и их значения из Remote Config на момент установки приложения.
Теперь легко определить какое Remote-значение получило именно наше устройство в данный момент. Также можем принудительно обновить значения на iOS.
Результат
Время на определение значения сократилось с 40 минут до 1 минуты.
Хочу обратить внимание на одну маленькую, но топовую доработку — это отображение текущей сборки и коммита в установленном приложении.
Теперь не возникают таких вопросов, как «А ты точно на моей ветке проверяешь?». Это дает уверенность и позволяет не тратить время на переустановку и перепроверку.
Итог
Весь этот список улучшений делался не за 1 день, а нарабатывался по мере необходимости и возникновения проблем. Но что мы получили?
- Тестировщики перестали быть зависимыми от разработчиков;
- Не нужен доступ к коду для сборок;
- Обезопасили себя от тестовых push-уведомлений на продакшн;
- Можем проверить аналитику событий, значение ключей Remote Config.
А главное — сэкономили время на различные подготовки с 300 минут до 23 минут! И это только в разрезе разового выполнения задач.
Теперь представьте, что получится, если умножить это на количество таких задач и количество сотрудников, которые работают над их реализацией.
Советы перед тем, как начать внедрять Debug Menu в свои приложения:
1. Подумайте, на подготовку к каким проверкам уходит много времени.
2. Выносите настройки конкретно для вашего приложения.
3. Если вы тестировщик, попросите разработчика помочь вам 1 раз, чтобы потом не отвлекать его каждый день.
4. Наглядно покажите бизнесу сколько времени вы сэкономите.
5. Не забудьте ограничить любой доступ к панели от ваших пользователей исключить Debug Menu из релизных сборок.
