Как тестируют сложные интеграции в FAVBET Tech: разбираем на примере платежных интеграций

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

О том, как они справляются с этими вызовами и какими особенностями обладают платёжные интеграции (помимо финансовых рисков), в партнёрском материале рассказывает QA Lead этой команды Татьяна Калашникова.

Что такое платёжная интеграция и почему она сложная

Моя команда отвечает исключительно за тестирование интеграций платёжных систем. Другие команды FAVBET Tech могут этим заниматься, если их функционал затрагивает такую систему, но поверхностно. Основную проверку всегда выполняем мы.

Сейчас в команде 11 человек, включая меня как лида:

• двое автоматизаторов;
• один General QA;
• семь ручных тестировщиков.

На собеседованиях я часто объясняю, чем мы занимаемся, так:
Представьте, что вы покупаете что-то онлайн. Когда доходите до момента оплаты, в работу включаются платёжные системы. Вы выбираете, чем платить — Apple Pay, Google Pay или банковской картой. Но сам магазин, в котором вы покупаете, сначала должен был подключить эти платёжные системы. И вот именно тестирование того, правильно ли работает эта интеграция, и есть наша работа.

Для пользователя всё выглядит просто (оплатил — и всё), однако платёжные системы — это сложная интеграция, ведь «под капотом» происходит множество процессов. Рассмотрим несколько примеров:

• Интеграция с платёжной системой. Чтобы протестировать её, нужно учитывать, какие налоги и комиссии взымаются, на каких этапах и в каких объёмах.
• Протестировать, как работает интеграция, когда пользователь хочет вернуть свои деньги. Это тоже может облагаться налогами в зависимости от страны и провайдера.
• Пополнение счёта. Это одна из самых распространённых фич, но она усложняется, если требует верификации личности.

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

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

Как выглядит процесс тестирования интеграций

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

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

Чаще всего мы проверяем, может ли пользователь пополнить счёт. Это базовая фича для любой платёжной системы. Для неё у нас есть готовые инструкции и мануалы, на которые мы опираемся. Если в команду приходит новичок — это часть его онбординга.

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

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

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

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

Среды, с которыми мы работаем

Большинство платёжных провайдеров предоставляют нам тестовую среду. Мы подключаем к ней свою и обмениваемся между собой фейковыми деньгами. Если такая среда есть, мы можем полноценно проверить функционал и покрыть почти 100% кейсов, включая нестандартные.

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

В таком случае тестируем на продакшене. Берём реальные тестовые карты, которые нам предоставляет компания, создаём под них тестовые аккаунты и вручную проходим флоу как обычный пользователь.

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

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

Перед релизом проводим несколько уровней проверки: на тестовой среде, на стейдже (песочнице), на препродакшене. Только после этого выходим в прод. Плюс перед релизом всегда показываем демо заказчику. Если он даёт финальное «да» — версия уходит в продакшн.

Типы тестов: что, как и зачем проверяем

Мы используем несколько типов тестов:

• Юнит-тесты — зона ответственности разработчиков. Они покрывают свой код и проверяют, как работает логика отдельных компонентов.
• Интеграционные и системные тесты — это уже наша зона. Их выполняют тестировщики — как ручные, так и автоматизаторы. Мы проверяем, как одна часть системы работает в связке с другой и как всё это интегрируется в наш многослойный бэкенд. Такой подход обязателен, потому что часто бывает, что отдельный модуль работает идеально, но при взаимодействии с другими возникают ошибки.
• Контрактные тесты — это проверка API. То есть мы отправляем запрос и проверяем, получим ли именно тот ответ, который описан в документации провайдера и который нам нужен для работы нашей системы. Каждый запрос мы тестируем на всех уровнях как в нашей системе, так и в системе провайдера.

Контрактные тесты проходят в два этапа. Сначала мы всё проверяем вручную — тестировщики сами «пробивают» запросы, анализируют ответы. Если всё работает как надо — передаём флоу на автоматизацию. Это важно, чтобы снизить риск человеческой ошибки и упростить будущую поддержку.

На сегодня у нас автоматизировано около 70% актуального функционала. И это действительно облегчает работу. Но несмотря на это, мы не можем обойтись без ручного тестирования.

Почему? Потому что каждый флоу, который мы тестируем, довольно специфичен. Всегда есть свои нюансы:

• в одной платёжке нужно вводить CVV, в другой — нет;
• где-то обязательна верификация кошелька или пользователя, а где-то — нет.

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

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

Как мы выявляем и обрабатываем проблемы

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

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

Наш главный инструмент расследования — это логи. Мы работаем с Grafana, которая показывает полную картину происходящего в системе. Если видим, что всё сработало по флоу, но провайдер вернул ошибку — передаём информацию ему. Если видим, что проблема у нас — передаём разработчикам.

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

Типичные риски и вызовы, и как мы с ними работаем

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

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

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

На что обращать внимание: советы из опыта

В целом, если всё хорошо описано и команда компетентна, даже самые сложные реализации можно сделать качественно. Вот ещё несколько советов напоследок:

• При эстимации обязательно учитывать риски со стороны провайдера. Это может повлиять не только на сроки реализации, но и на качество продукта на выходе.
• Тщательно анализировать API провайдера. Нужно ещё до старта убедиться, что весь функционал, который мы закладываем в своих требованиях, реально поддерживается и может быть реализован.
• Иметь доступ к тестовым аккаунтам и кошелькам. Иначе это не будет похоже на реальные условия.

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