Информации о том, как тестировать CPA-сети, пока мало, поэтому новичкам бывает сложно в них погрузиться: что и как тестировать, что обязательно учесть в первую очередь, что проверять одному, а что — с командой. В нашей компании несколько таких платформ, мы уже не единожды вводили на них тестировщиков. И решили собрать весь наш опыт в полное руководство, которое поможет тестировщикам быстрее погружаться в подобные проекты. Меня зовут Маша Смирнова, я руководитель отдела тестирования Kokoc Group, года два назад была бы рада найти такое руководство на просторах интернета, если честно.

Немного про CPA

CPA-сети — это платформы-агрегаторы, на которых рекламодатели и вебмастера договариваются о сотрудничестве. Первые размещают заказы на привлечение пользователей к своим проектам; вторые — эти заказы исполняют. Важно, что в CPA-модели рекламодатели платят не за абстрактное привлечение, а только за определенные действия пользователей: регистрацию, подписку, покупку товара и так далее.

У Kokoc Group несколько CPA-платформ, которые работают с разными сферами бизнеса:

• Где Слон? — платформа CPA-маркетинга для e-commerce

• AdvGame — платформа для продвижения онлайн-игр;

• Rafinad — платформа для компаний из финансовой сферы. 

Как тестировать CPA-сети, я буду преимущественно показывать на примере «Где Слон?». Во-первых, потому что это большая e-com-платформа: много пользователей, много менеджеров, много операций и так далее. А во-вторых, потому что внутри много хороших тестировщиков, у которых собралось много информации по теме.

Чтобы понять, что мы тестируем, нужно изучить пользователей и их логику работы

У CPA сетей 4 типа пользователей:

• рекламодатель — размещает на платформе заказы;

• вебмастер — выполняет эти заказы;

• менеджер — работает на стороне СРА и помогает клиентам сервиса;

• администратор — работает на стороне СРА, следит за корректной работой сервиса.

У каждого из них своя логика использования сети, свои личные кабинеты, свой набор прав доступа. Например, рекламодатель может завести страницу компании, менеджер — мониторить эту компанию, администратор — менять настройки пользователей и так далее. Поэтому тестировщик должен не пройти по цепочке и убедиться, что сервис работает, а проверить каждую роль: зарегистрировать тестового пользователя (вебмастера, администратора и так далее), изучить, какие права и ограничения выставлены, убедиться, что они настроены корректно и условный вебмастер не видит инструменты менеджера.

На что следует обратить внимание

Для вебмастера

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

• изучите, как заходить в систему и переходить на дашборд, как работают фильтры и интерпретация отчетов;

• создайте трекинговую ссылку, добавьте UTM-метки и токены, проверьте редиректы и сохранение ссылок;

• проверьте, приходят ли уведомления о конверсии;

• создайте и отправьте тикет техподдержке.

Для рекламодателя

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

• создайте новый оффер, настройте условия работы и запустите рекламную кампанию;

• изучите дашборды и отчеты для анализа;

• изучите антифрод-инструменты и отчеты для мониторинга фрод-активности.

Для менеджера

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

• создайте и отредактируйте аккаунт через панель управления, поработайте с аккаунтом: попробуйте провести различные операции, которые доступны через панель инструментов, проверьте, что статистика показывается корректно;

• изучите дашборды для анализа кампаний всех пользователей;

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

Для администратора

Администратор должен видеть и использовать все имеющиеся в сервисе инструменты через панель. Поэтому на этой роли нужно изучить систему целиком.

После знакомства нужно тщательно протестировать все инструменты и элементы СРА-сети

Дальше подробно разберу, что именно нужно протестировать в каждом элементе системы.

Что тестировать важнее? Все. СРА-сети — это продукты, в которых несколько видов пользователей смотрят и на финансовую сторону, и на интеграции со сторонними сервисами, и качество предоставления отчетности, и на возможности коммуникации. Поэтому протестировать тщательно что-то одно не выйдет. Но особое внимание все-таки советую уделить этим пунктам:  вывод средств, трекинг лидов, начисление на баланс, авторизация, редиректы ссылок, инструменты интеграции.

Отслеживание и аналитика

• Проверьте корректность отслеживания данных о конверсиях: клики, лиды, покупки и прочее. Для этого соберите данные на тестовом аккаунте и проанализируйте статистику.

• Протестируйте сеть на разных платформах (десктопная и мобильная версии) и браузерах (Safari, Chrome и прочие).

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

  Покажу на примере ADVGame и Rafinad. 

• При подключении к офферу, у которого доступен тип трафика, создайте поток. Если тип трафика не совпадает, этого сделать не получится, если все в порядке, поток пойдет на модерацию. Далее подтвердите его, сделайте ссылку, перейдите по ней и, наконец, посмотрите статистику по источникам.

• Убедитесь, что UTM-метки и GET-параметры (erid, ID вебмастера или рекламодателя и прочие) правильно распознаются, то есть в базу данных записывается верный идентификатор перехода, referrer, ID вебмастера или рекламодателя, дата перехода, sub_id, erid и так далее.

Интеграция с разными системами:

• Проверьте корректность интеграции со сторонними API и вебхуками (метод отправки данных в режиме реального времени от одного веб-приложения к другому). Убедитесь, что работа API-методов к сторонним сервисам соответствует документации.

• Имитируйте различные ответы и задержки. Для этого можно, например, самому настроить моковые данные или попросить разработчиков сделать тестовый стенд, на которому моковые данные уже будут настроены. 

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

• Убедитесь, что синхронизация данных между CPA сетью и партнерскими системами корректно: все своевременно обновляется и передается без ошибок.

• Проверьте корректность редиректов (различные URL и параметры), скорости и надежности перенаправлений. Для того скооперируйтесь со специалистами по нагрузочному тестированию: они напишут скрипт, который будет имитировать нагрузку на сервис при большом наплыве пользователей, например, на один редиректор.

Финансовые операции

Финансовые операции — один из ключевых аспектов функционирования CPA-сервисов и для вебмастеров, и для рекламодателей. Вот на что стоит обратить внимание при тестировании финансовых инструментов:

Финансовые транзакции и выплаты

• Убедитесь, что система корректно рассчитывает заработанные суммы для вебмастеров на основе подтвержденных конверсий. Проведите тесты на разные условия выплат (повременные, за каждую конверсию, с учетом бонусов).

• Убедитесь, что вебмастеры и рекламодатели могут получать полные и точные финансовые отчеты по своим операциям. Проверьте корректность расчета комиссии, налогов и других сборов.

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

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

Зачисление средств рекламодателями

• Проверьте, что рекламодатели могут легко пополнять свои счета различными методами (кредитные карты, банковские переводы, электронные кошельки). Убедитесь в правильности зачисления средств на балансы рекламодателей.

• Проверьте процессы автоматического списания средств с балансов рекламодателей по мере регистрации конверсий. Убедитесь, что все транзакции корректно фиксируются и списываются. 

Безопасность финансовых операций

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

• все финансовые операции должны проводиться через защищенные соединения;

• для доступа к таким операциям стоит иметь удобную  корректно работающую многофакторную аутентификацию.

Фрод и защита от мошенничества

• Убедитесь в наличии и корректной работе инструментов для выявления финансового фрода, таких как мониторинг аномальных транзакций и подозрительных действий.

• Проверьте систему уведомлений о подозрительных действиях и возможность временной блокировки транзакций до выяснения обстоятельств.

• Убедитесь, что алгоритмы и правила для автоматического выявления подозрительной активности работают.

• Убедитесь, что система способна оперативно блокировать подозрительную активность. Протестируйте сценарии эскалации и уведомлений.

Накрутки на платформах бывают. Допустим, вебмастер приносил в среднем 100 лидов, но внезапно начал приносить по 1000. Это подозрительная активность и повод проверить, не накручивают ли статистику. Этим занимаются менеджеры, но тестировщику полезно знать, какие типы мошенничества бывают и как его выявлять.

Проблемы с качеством трафика

Низкокачественный трафик: высокий bounce rate, низкая продолжительность сессий — не приводит к ожидаемым конверсиям. Поэтому тестировщик должен следить за качеством источников и запросов.

Тщательно проанализируйте источники трафика, чтобы выявить площадки с высоким bounce rate и низкой конверсией — в этом поможет статистика и сравнение с идентичными типами трафика у других вебмастеров. 

Также можно настроить фильтры для отклонения подозрительных запросов. Но решение об этом советуем принимать вместе с командой. Мы, если видим, подозрительную активность, обращаемся в специальный отдел.

Политика конфиденциальности и соблюдение законодательных норм

• Проверьте систему на соответствие требованиям GDPR и другим регулирующим актам.

Масштабируемость

• Вместе со специалистом по нагрузочному тестированию оцените производительности системы под высоким трафиком. 

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

Оптимизацией запросов и индексов, как правило, занимаются разработчики. Но если тестировщик обладает этими компетенциями и знаком с темой, то может сделать это самостоятельно (чтобы не передавать задачу туда-сюда и не тратить время).

Автоматизация тестов и обработка и предотвращение ошибок

Специалисты по ручному тестированию, особенно джуны и мидлы, обычно этим не занимаются — это задачи автотестеров, разработчиков и девопсов. Но полезно знать, какая работа ведется и к кому идти, если возникли вопросы или всплыли ошибки. На что обратить внимание:

• разработка сценариев для стандартных процессов (регистрация, покупка, подписка);

• включение автоматизированных тестов в CI/CD;

• настройка системы логирования для фиксации всех важных событий;

• настройка систем мониторинга для выявления и устранения аномалий.

Что осталось сказать

Наш отдел существует два года. За это время мы взяли в тестирование уже шесть СРА проектов. Что-то осталось на уровне MVP, что-то только появилось и будет работать как большая платформа.

Чтобы покрыть все перечисленные пункты, нужна большая и сложная команда: ручные тестировщики и автоматизаторы, тестировщики производительности и безопасности. Два года назад СРА-проекты тестировали наши проджекты и интеграторы, год назад на три проекта было три тестировщика, сейчас на четыре постоянных проекта в тестировании — пять ручных и один автоматизатор. И команда все еще растет и будет расти.

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