Тестирование рекламы
Для тестирования в основном используется тестовая реклама, которую партнёры готовят заранее. Это делается, потому что разные характеристики рекламы на продакшене не позволяют быть уверенным, что новый функционал или фикс бага не задели основные параметры и работу рекламного креатива.
Но получение тестовой рекламы требует изменения определённых параметров в наших экспериментах, обращения к тестовой админке медиатора, добавления тест-мода (специальные параметры, чтобы партнер понимал, что запрашивается именно тестовый креатив), использования своей дебаг-панели, а также VPN по странам, а в отдельных кейсах - по городам. И тут нам понадобятся некоторые инструменты.
Инструменты
Сниффер для анализа трафика;
Админка у медиатора, где можно настроить получение рекламы от конкретного партнера на свой тестовый юнит (специальный id, используя который, паблишер запрашивает рекламу у медиатора);
Своя админка с фича-тогглами, где можно включить/отключить, или изменить наши эксперименты;
Наша дебаг-панель;
VPN;
Внешние гайдлайны;
Внутренняя база знаний и Confluence для её хранения;
Чек-листы;
TMS.
Инструмент №1. Charles. Активно используется не только тестировщиками, но и разработчиками. Практически все задачи требуют замены продакшн параметров на тестовые. Например, часто возникает необходимость добавить в конфиг эксперимент или обращаться к тестовым юнитам медиатора. К тому же для тестирования при запросе рекламы необходимо добавлять дополнительные параметры тест-мода. Также довольно часто требуется имитировать проблемы с загрузкой креативов и проверять их с нужными параметрами, например, во время регрессионного тестирования.
Инструмент №2. Тестовая админка медиатора. Медиатор - это специальная платформа, которая позволяет подключать приложение сразу к нескольким рекламным сетям, а также управлять показом рекламы (например, Google AdMob, Fyber и другие). Ещё во время онбординга мы проводим обучающие курсы по рекламе, где сотрудники в тестовой админке медиатора создают свой тестовый юнит для настройки параметров рекламы под себя.
Инструмент №3. Админка с фича-тогглами. Практически все рекламные (и не только) механики в приложении iFunny закрыты под фича-тогглы (механизм реализации, при котором часть кода прячется за флаг, контролирующий его включение или выключение). Это нужно, чтобы сделать более надёжным и безопасным выпуск той или иной функциональности. Чтобы получить нужный для тестирования конфиг, мы используем нашу админку с фича-тогглами или подменяем параметры, используя Charles. А эксперименты помогают понять, какая из запущенных гипотез является наиболее оптимальной. Всё это есть в нашей админке, которая хранит данные и управляет ими по всем фичам и экспериментам. Документацию обновляем и дополняем по мере необходимости: если после обновления SDK изменилась описанная логика работы, или если вышли нормативы/регламенты, требующие внесения обязательных правок.
Инструмент №4. Дебаг-панель. Для удобства разработали свою рекламную дебаг-панель, которая представляет собой отдельный интерфейс и в большинстве случаев позволяет локально на клиенте настроить необходимые параметры, заменяя собой практически все инструменты, описанные выше.
Инструмент №5. VPN. В основном используется для проверки задач, связанных с GDPR и CCPA. Для тестирования GDPR подходит VPN с возможностью получения IP европейской страны. Для тестирования CCPA необходим VPN с возможностью получения калифорнийского IP.
Инструмент №6. Внешние гайдлайны. В работе с рекламными SDK часто используем их официальную документацию, где можно получить:
рекламные креативы и их идентификаторы, которые используются для настройки и получения тестовой рекламы;
форматы запросов и ответов рекламной SDK, а также параметры, из описания которых понимаем, за что они отвечают, и какие возможные значения для них допустимы;
changelog изменений рекламных SDK - чтобы понять, на какие изменения при обновлении SDK нужно обратить внимание во время тестирования.
Инструмент №7. Внутренняя документация. Внешние гайды не всегда являются достаточно подробными. Кроме того, проверка одной и той же функциональности от разных SDK требует переключения между разными источниками для поиска необходимой информации. Поэтому оказалось удобным агрегировать информацию из разных гайдлайнов SDK и делать сборную внутреннюю документацию в нашем Confluence, дополняя ее своими комментариями.
Инструмент №8. Чек-листы. Наравне с внешней и внутренней документацией для проверок различных задач используем чек-листы (пример можно посмотреть ниже в разделе про обновление SDK). Для такого типа задач, как проверка обновлений SDK, обновлений медиатора или адаптеров, мы используем уже составленный чек-лист, который изменяется по мере необходимости. Для остальных задач составляем чек-листы либо в процессе разработки задачи, либо непосредственно перед тестированием, в зависимости от сложности задач.
Инструмент №9. Тест-кейсы. Тест-кейсы - неотъемлемая часть тестирования любого проекта/функциональности, в том числе рекламы. Тест-кейсы разделены по приоритетам, что позволяет использовать risk-based testing, о котором будет рассказано подробнее ниже. В тест-кейсах фигурируют такие проверки, как загрузка и показ рекламы, запросы на рекламу, работа разных механик (например: водопад, аукцион), а также запрос и отображение рекламы от партнерских рекламных сетей. Данные проверки в полной мере позволяют убедиться, что рекламный функционал работает без сбоев/корректно.
Задачи
Тестирование рекламных интеграций, чтобы все механики работали как часы - довольно трудоемкий процесс. Среди всех задач есть много рутинных, но они компенсируются интересными и технически сложными исследованиями по ходу проработки других задач.
Разберем, с чем приходится сталкиваться на постоянной основе:
Обновление SDK;
Тестирование форматов;
Безопасность;
Регрессионное тестирование;
Смоук тестирование;
Другие задачи (юридические вопросы, локализации, эксперименты, аналитика, рефакторинг и так далее).
Задача №1. Обновление SDK. Можно сказать, что обновление SDK - наиболее популярная задача в рамках тестирования рекламы. Из-за частого проведения тестирования обновлений SDK (а также медиатора или адаптеров) составили чек-лист проверок:
Вёрстка. Проверяем всё: центрирование, размер, отображение на устройствах с разными разрешениями экранов.
Пользовательские сценарии. Тап по контенту/кнопке и по privacy icon, возврат в приложение, воспроизведение и остановка видеорекламы.
Репорт (отправка жалоб, связанных с рекламой). Пользователь может пожаловаться на рекламный контент или сообщить о технических проблемах.
Соответствие стандартам GDPR и CCPA.
Отправка аналитики. Внутренняя и внешняя (партнёру и медиатору).
Технические проверки. Например, уход в фон во время загрузки рекламы.
Задача №2. Тестирование форматов. Баннерная и нативная рекламы у нас закрепились и работают стабильно, но мы пробуем интегрировать и другие виды, в частности, fullscreen-рекламу. В целом, тестирование Rewarded Video и Interstitial во многом схоже с тестированием других видов: проверяется корректная загрузка и отображение рекламы, а также отправка аналитики.
Ключевым в проверке fullscreen-рекламы является ее отображение на разных по диагонали экранах, например, на смартфоне и планшете. Важно, чтобы появившаяся на экране реклама не перекрывалась другими элементами, и по завершению таймера скрывалась автоматически или тапом по крестику, возвращая пользователя в исходную точку приложения:
Отдельно нужно сказать про механику Rewarded Video - после окончания просмотра рекламы (или просмотра до определенной временной метки) пользователь должен получить вознаграждение. Поэтому очень важно хорошо протестировать этот функционал.
Подробно про разные форматы мобильной рекламы мы уже писали в отдельной статье.
Задача №3. Безопасность. Чтобы следить за качеством трафика, интегрировали в iFunny внешнее антифрод-решение. В него для дополнительной проверки атрибуции показов и кликов на каждое событие генерируется новое. На стороне системы с помощью технологий машинного обучения и большого объема накопленных данных происходит дальнейший анализ. Со своей стороны мы проверяем отправку и разметку событий для разных сетей и разных типов рекламы.
Задача №4. Регрессионное тестирование. Раз в две недели iFunny релизится на iOS и Android. Независимо от количества рекламных задач, попавших в релизную ветку, мы проводим регрессионное тестирование рекламного функционала/блока. В регрессионных паках собраны следующего рода проверки:
Основные проверки, что реклама запрашивается и отображается на нужных экранах приложения;
Работа нативной и баннерной рекламы, а также рекламных сетей, с которыми сотрудничаем - по сути, это упрощенный чек-лист, используемый для тестирования SDK (добавления, обновления);
Работа разных механик: водопад и биддинг (что это такое, можно ознакомиться здесь);
Проверка на соответствие юридическим нормам;
Проверки каких-то наших внутренних разработок (например, эксперименты с дизайном).
Если встречаем проблемы в процессе тестирования (не проходят какие-то кейсы регресса), то чиним в текущей релизной ветке - не катимся с рекламой, которая не работает.
Проведение полного ручного прогона регресса занимает порядка 2-3 дней. Поэтому, чтобы сократить время прохождения регресса, используется практика проведения Risk-based testing (вид тестирования, основанный на вероятности риска). Суть такого тестирования - исключить некоторое количество тест-кейсов из прогона, проведение которых не может выявить потенциальных ошибок на текущем релизном билде. Иными словами, кейс не имеет смысла включать в регрессионное тестирование, если при разработке не был затронут функционал, проверяющийся в кейсе.
Задача №5. Смоук тестирование. Перед тем, как выкладывать сборку в сторы, а также при тестировании хотфиксов, мы прогоняем смоук тесты. В рамках смоук тестирования реклама проверяется, но не так детально, как при регрессе. Мы тестируем основные моменты, связанные с рекламой, а именно ее загрузку и отображение.
Задача №6. Другое. К тестированию других задач можно отнести:
юридические задачи, например, связанные с GDPR и CCPA;
задачи локализации (для пользователей iFunny из Бразилии);
эксперименты, связанные с дизайном рекламы;
задачи аналитики;
рефакторинг, оптимизации. Например, оцениваем доступный нам для анализа контент на предмет валидности.
Источники:
Доп. материал:
Last updated
