Автоматизация отправки-получения событий в сервисах аналитики

О какой аналитике речь

В различные приложения (мобильные, веб и др.) внедряются различные аналитические сервисы — Amplitude, Firebase, AppsFlyer, Qonversion, Facebook, Google Analytics, Yandex и т.п.

Глобально такие сервисы можно разделить на две группы:

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

Общая схема работы у всех сервисов одинаковая —

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

Как вручную проверяется и работает сбор такой статистики

Если максимально всё упростить проверка состоит из трёх этапов — вызов события, его отправка и получение сервисом:

Для вызова события ручной тестировщик (а так же пользователь) выполняет определенное действие через UI приложения (создание папки, переход на экран, покупка подписки и т.п.).
Приложение после совершенного действия должно отправить запрос на сервер статистики. О том, что была попытка отправить событие могут говорить логи на устройстве или запросы на сервис.
О том, что событие точно дошло может говорить лишь информация на стороне самого сервиса. Это или API запросы к самому сервису, или дашборды на сервисе статистики. В нашем случае ручной тестировщик для проверки получения события анализирует чаще всего данные о полученном событии на дашборде сервиса статистики, т.к. это самый быстрый для него способ.

Варианты автоматизации

Подобные проверки не легки со стороны ручного тестирования и приоритетны для бизнеса (т.е. жертвовать ими во благо времени не стоит). Соответственно, идея внедрить автотесты всплывает сама собой и звучит от тестировщиков, разработчиков, продакт менеджеров, ПМов и т.п.

Мы проанализировали варианты автоматизации — рассмотрели привычные описанные выше способы тестирования и возможные их альтернативы.

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

Идея, подход	Суть подхода	Плюсы, недостатки и ограничения подхода	Резолюция по подходу
Варианты реализации вызова событий
Функциональные тесты через UI	Вызов событий статистики при помощи функциональных тестов через интерфейс приложения	Самые реалистичные, т.к. полностью имитируют действия пользователя и тестировщика. Однако: Для покрытия всех событий необходимо покрыть автотестами практически все приложение. Очень трудозатратно и неэффективно, если интерфейс приложения подвержен изменениям. Невозможно автоматизировать события покупок на симуляторах (iOS) и эмуляторах (Android) из-за отсутствия функционала покупок.	реализация возможна, но является трудоемкой задачей и имеет ограничения
Unit тесты	Вызов функции отправки событий статистики из кода приложения	Быстро выполняются, реализуются разработчиком. Однако не используется взаимодействие через интерфейс приложения. Т.е. если “отвалился” код от элемента интерфейса, то такая проверка на уровне кода не гарантирует, что выполнение действия в UI вызовет этот метод.	реализация не гарантирует корректную отправку реальных событий, нецелесообразна
Варианты проверки отправки события
Логи приложения	Поиск форматированного сообщения об отправленном событии в логах приложения	Не все сервисы логируют нужную информацию. Сложно отследить связь между взаимодействием с конкретным элементом на экране и сообщением в логе о событии. Нет гарантии, что стороннее SDK не сломается, не потеряет событие, не изменится.	реализация возможна, но является трудоемкой задачей и имеет ограничения
Проксирование http запросов с событиями статистики	Получение информации о событиях при помощи специального дополнительного сервиса, “перехватывающего” запросы из SDK статистики на сервер статистики	Сложность реализации сервиса, перехватывающего запросы на сервер статистики. Дополнительный, перехватывающий запросы, сервис может влиять на работу запросов самого приложения, тормозить их. Может быть нереализуем для релизных сборок, где как раз таки нужны регрессионные проверки важных событий (именно эту часть нам важно автоматизировать). Не может использоваться в релизной сборке, т.к. является дебаг модулем.	реализация возможна, но является трудоемкой задачей и имеет ограничения
Варианты проверки получения событий сервисом
API запросы на сервис статистики	Получение информации о событиях через API сервиса по id пользователя	Далеко не все сервисы статистики имеют общедоступный, бесплатный API для выгрузки данных о событиях (например, Amplitude имеет, а Appsflyer — нет) Возможны задержки между отправкой события и доступностью информации о нем через API, особенно, в периоды когда сервисы статистики нагружены	реализация возможна для некоторых сервисов, но имеет ограничения
Через дашборд на стороне сервиса	Проверка через сайт сервиса	Привязываемся к интерфейсу и логике сервиса и полностью зависим от его внешнего вида — как только изменится, наши скрипты не будут работать. На дашборде в некоторых сервисах информация отображается с непрогнозируемой и когда-то длительной задержкой.	реализация нецелесообразна

Выводы

Итого, комбинируя все варианты делаем вывод, что автоматизация проверки статистики целесообразна на проектах, где вызов событий может быть выполнен при помощи автоматизированных функциональных тестов через UI, а получение событий только для сервисов статистики, которые имеют общедоступный API для выгрузки данных о событиях (например, Amplitude).

Проверку статистики, для сервисов, которые не предоставляют API, автоматизировать сложно или невозможно. Их необходимо будет дополнительно выполнять вручную.

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

интерфейс приложения может меняться достаточно часто, в том числе при использовании A/B-тестов,
на проектах может использоваться кастомный алгоритм отправки событий статистики в определенный сервис, только рандомному % пользователей,
общее количество событий статистики на проекте объемно — может составлять от несколько десятков до пары сотен; некоторые из них важны, некоторые оказываются не нужными — потому они меняются, отключаются, добавляются.

``Давайте сделаем, чтобы по одной кнопке статистика отправилась и проверилась``

Хочется пояснить, почему идеи формата “нажать одну кнопку в приложении — статистика отправилась и проверилась” и похожие неверны. Это практически аналог unit тестов из таблицы выше — отличие только в том, что набор таких unit тестов запускается нажатием на кнопку в интерфейсе, а не программно.

Опыт других компаний

Изучение опыта других компаний по вопросу автоматизации проверок событий статистики говорит о том, что:

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

Дополнительно. Когда уместно внедрять автоматизацию через UI

Т.к. может возникнуть желание внедрить функциональную автоматизацию через UI и вместе с ней внедрить статистику, то важно результаты анализа выше дополнить факторами, при которых уместно внедрять такую автоматизацию. Ключевые из них:

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

Анализ и статья — Илья Лычков, Наташа Савастюк.

Февраль 2023