Как Протестировать Международный Платежный Сервис Без Боли И Нервов

Всем привет! Меня зовут Саша Зубарчук.

Я пришел в компанию Твердый три года назад в качестве младшего руководства QA. С этого времени я стал специалистом по автоматизации и первым стал аспирантом.

Школа контроля качества , с которым мы сотрудничали, и перешел на должность менеджера по продукту.

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

Этот опыт будет полезен тем, кто строит процесс тестирования на проекте — как QA-инженерам, так и менеджерам продуктов/проектов.

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

Из чего состоит платежный сервис и как он работает? Solid — это шлюз, который позволяет предприятиям по всему миру принимать онлайн-платежи клиентов различными способами: от кредитных карт и электронных кошельков до PayPal и Alipay. Во всей этой истории есть четыре главных игрока:

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

У вас может возникнуть вопрос: почему торговцы выбирают Solid, если они могут работать напрямую с банками? Все просто: 1) банков много, и каждый из них имеет свою специфику – объединяя разные банки из разных стран в единую инфраструктуру, мы добиваемся максимальной конверсии и дохода; 2) у нас огромный опыт в логике платежей и борьбе с мошенничеством; 3) помимо банковских платежей мы принимаем все альтернативные способы оплаты, популярные в конкретном регионе, и 4) у нас дешевле.

Начнем с первого пункта – каковы особенности проведения платежей в разных странах? Например, в США, как ни странно, совершить платеж не получится так же легко, как в Украине – используя только данные карты.

Там банки обязаны проверять дополнительные данные плательщика, такие как платежный адрес и почтовый индекс.

Таких нюансов много.

А также альтернативы карточным платежам.

Например, в Нидерландах и Германии люди предпочитают использовать местные онлайн-кошельки.

Самыми популярными способами оплаты в Китае являются Alipay, WeChat Pay и UnionPay. И в Нигерия Чтобы оплатить товар онлайн, пользователи идут в банк наличными! Мы принимаем все без исключения популярные платежи – с банковских карт на PayPal, электронные кошельки, Google Pay, Apple Pay или SMS. С Solid мерчант получает доступ к работе со всеми видами оплаты в одной интеграции.

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

Зачем тестировать платежные системы и риски нетестирования

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

Если с нашей стороны что-то пойдет не так, мы подведем слишком много компаний.

И наоборот – тестируя и совершенствуя свой платежный сервис, мы улучшаем продукты других бизнесов.

К сожалению, помимо успешного платежа, могут возникнуть ошибки, как системные, так и пользовательские.

Важно понимать, что 100% платежей никогда не будут успешными ни в каком месте.

Но мы со своей стороны обязаны сделать все, чтобы конверсия платежей была максимально высокой.

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

Мы тестируем все в три этапа.

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

Давайте подробнее рассмотрим, что именно нам предстоит протестировать.

Особенности тестирования платежных систем

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

Кажется, протестировать платеж несложно: нужно совершить платеж, проверить, чтобы деньги списывались с одного счета и зачислялись на другой.

Но есть нюансы.

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

Второй момент — разные виды платежей: подписки, первый платеж, авторизация (заморозка денег на счету), оплата через электронный кошелек.

Каждый из них имеет свою специфику тестирования.

Особое внимание следует уделить работе с валютами: не все из них имеют дробную часть.

Например, в гривне есть копейки, а в чилийском песо — нет. Если перевести сумму платежа 100 по Украине, банк спишет 1 гривну, то есть 100 копеек.

А в Чили это будет означать 100 песо.

Как видите, такие моменты нельзя упускать.

Что необходимо тестировать в платежных системах

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

Солидные разработчики занимаются решением нескольких типов задач (и все эти задачи в конечном итоге попадают в руки команды QA):

• разработка нового функционала (новые платные сервисы, например, система подписки, различные возможности для мерчантов, новые формы оплаты);
• разработка новых интеграций с платежными сервисами (сервисы токенизации PayPal, Alipay, Visa и Mastercard);
• обновление и проверка существующих интеграций: банки постоянно обновляют свои API, поэтому мы проводим проверку раз в месяц;
• задачи по оптимизации (увеличение скорости ответа продавца, сокращение времени загрузки форм);
• задачи, не связанные напрямую с процессингом (например, админ-панель для мерчантов, сложная финансовая система и сайт-витрина);
• исправление ошибок.

Подводя итог, все, что мы тестируем, можно разделить на следующие категории: Серверные службы Solid:

• по борьбе с мошенничеством;
• абонентское обслуживание;
• маршрутизация платежей;
• система бухгалтерского учета и финансового контроля;
• интеграция с внешними сервисами.

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

• проверка оплаты;
• проверка особенностей местоположения.

• внутренняя админ-панель (все, что помогает аналитикам Solid проводить A/B-тесты конвертации платежных форм, настраивать правила борьбы с мошенничеством);
• админ-панель для торговцев.

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

• ЕАТ при подключении нового мерчанта к Solid;
• задания от отдела рисков по проверке новых конфигураций;
• исследование работоспособности функционала (например, работает ли Apple Pay в WKWebView).

Шаги к успешному тестированию

Автоматизация

Без автоматизации не получится.

Если какой-то сервис не охвачен автотестами, сбоев не избежать.

Запускайте автотесты, когда это возможно.

После того как вы выпустили задачу в среду, запустите тесты.

Вы объединили несколько задач в релиз-кандидат — запустите тесты.

В нашем случае это выглядит примерно так:

• разработчики самостоятельно запускают тесты при реализации задачи;
• тестировщики запускают тесты при тестировании задачи в изолированной среде;
• тесты запускаются автоматически при сборке новой версии сборки;
• Автотесты постоянно запускаются в среде Prod.

Тесты выполняются многопоточно, а также делятся на задачи по важности.

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

Все остальные тесты Solid API и других микросервисов занимают около 3-4 минут. Пользовательские тесты, конечно, немного медленнее.

Но даже здесь мы не прекращаем работу над улучшением и оптимизацией.

Почему изолированное тестирование — не лучший вариант при тестировании платежей? Расскажу на нашем примере с антифродом.

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

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

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

Мы обсудили это с помощью автотестов, но столкнулись с проблемой.

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

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

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

Как мы делали каждый платеж: чистили тестовые данные, создавали все условия, чтобы платеж попадал под определенное правило, и тогда он работал.

Но не факт, что так будет и в рабочей среде, ведь идеальной ситуации, чтобы оплата подпадала под одно правило, никогда не будет. Мы решили подключить к тестовому мерчанту реальные антифрод-правила наших клиентов.

Потом они стали работать более четко.

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

Теперь клиенты Solid могут настраивать под себя правила борьбы с мошенничеством.

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

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

Человек вряд ли купит пять программ тренировок в день.

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

Автоматизация поможет снизить как затраты на тестирование, так и риски, связанные с человеческим фактором.

Тестирование на этапе технического задания

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

Методика «раннего тестирования» имеет ряд преимуществ:

• команда разработчиков правильно поймет задачу, и мы не будем тратить время на исправления;
• хорошо написанное техническое задание — это 70% хорошей документации;
• Благодаря тому, что команда тестирования заранее ознакомилась с техническим заданием, сценарии тестирования также продумываются заранее, и в момент поступления реализованной задачи на тестирование процесс идет быстрее.

Хорошая тестовая документация

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

В Solid мы создали собственную базу знаний.

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

Такая база – это емкая и сложная задача, ставшая для нас вызовом.

Необходимо было собрать всю документацию воедино и четко описать процессы.

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

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

Позвольте мне привести вам еще один пример.

Однажды мы изменили логотипы международных платежных систем на платежных формах.

У нас есть более 200 различных дизайнов для наших клиентов.

Для каждого дизайна может быть несколько конфигураций полей на форме.

Например, для Бразилии добавляется дополнительное поле CPF — аналог нашего идентификационного кода.

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

Никто из команды тестирования Solid не может физически знать, как должны выглядеть все 200 фигур.

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

***

Либо украинские банки так хорошо предотвращают мошенничество, либо никто не хочет воровать карточные данные украинских пользователей.

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

Ведь задача каждого бизнеса – выпустить качественный продукт. Кто еще, как не QA-инженеры, в этом поможет? Буду рад, если вы поделитесь в комментариях своими принципами хорошего процесса тестирования.

Теги: #Тестирование веб-сервисов #Тестирование ИТ-систем #тестирование платежных систем

• Обзоры Онлайн-Доступа К Спутниковому Телевидению - Обзор Лучших Пакетов Спутникового Интернет-Телевидения

  19 Oct, 24

• Байконуру – 60 Лет.

  19 Oct, 24

• Приглашаем Студентов Мфти Присоединиться К Новому Сезону Лаборатории Искусственного Интеллекта Вконтакте

  19 Oct, 24

• Прыжок Из Стратосферы

  19 Oct, 24

• Информационная Безопасность Банковских Безналичных Расчетов. Часть 6 - Анализ Банковских Преступлений

  19 Oct, 24

• «Рунет Сегодня», 27 Февраля 2012. Эксперты Выпуска: Руслан Фазлиев, Павел Власов-Мрдуляш

  19 Oct, 24

• Зачем Нам Нужны Нейронные Процессоры?

  19 Oct, 24

• Гарнитура Bb-Mobile Microon-1

  19 Oct, 24

• Увольнение 2.0

  19 Oct, 24

• Наши Новогодние Поздравления...

  19 Oct, 24