Тестування реклами
Для тестування переважно використовується тестова реклама, яку партнери готують заздалегідь. Це робиться, тому що різні характеристики реклами на продакшені не дозволяють бути впевненим, що новий функціонал або фікс бага не торкнулися основних параметрів і роботи рекламного креативу.
Але отримання тестової реклами вимагає зміни певних параметрів у наших експериментах, звернення до тестової адмінки медіатора, додавання тест-мода (спеціальні параметри, щоб партнер розумів, що запитується саме тестовий креатив), використання своєї дебаг-панелі, а також 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, повернення в додаток, відтворення та зупинка відеореклами.
Репорт (надсилання скарг, пов'язаних з рекламою). Користувач може поскаржитися на рекламний контент або повідомити про технічні проблеми.
Надсилання аналітики. Внутрішня та зовнішня (партнеру та медіатору).
Технічні перевірки Наприклад, догляд у фоновому режимі під час завантаження реклами.
Завдання №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