Платіжна інтеграція – це завжди зона підвищеної відповідальності, а коли до цього додається багатошарова архітектура та високе навантаження, челенджів стає тільки більше. Тому у FAVBET Tech для тестування платіжних інтеграцій виділена окрема команда.
Як вони борються із цими викликами і які особливості є саме у платіжних інтеграцій (окрім фінансових ризиків), для партнерського матеріалу розповідає QA Lead цієї команди Тетяна Калашнікова.
Зміст
Що таке платіжна інтеграція і чому вона складна
Моя команда відповідає виключно за тестування інтеграцій платіжних систем. Інші команди FAVBET Tech можуть це робити, якщо їхній функціонал зачіпає таку систему, але поверхнево. Основну перевірку завжди виконуємо ми.
Зараз у команді 11 людей включно зі мною як лідом:
- двоє автоматизаторів;
- один General QA;
- семеро мануальних тестувальників.
На співбесідах я часто пояснюю, чим ми займаємося, так:
Уявіть, що ви щось купуєте онлайн. Коли доходите до моменту оплати, включаються в роботу платіжні системи. Ви вибираєте, чим платити – Apple Pay, Google Pay або банківською карткою. Але сам магазин, у якому ви купуєте, спочатку мав ці платіжні системи до себе під’єднати. І от саме тестування, чи правильно працює ця інтеграція, є нашою роботою.
Систем, з якими ми інтегруємось, дуже багато. Є популярні платіжки, як-от Apple Pay або Google Pay. Але є й менш очевидні, як-от Skrill, Neteller, AirCash, що більш відомі за кордоном.
Для користувача все виглядає просто (оплатив – і все), проте платіжні системи – це складна інтеграція, бо під капотом відбувається багато процесів. Розглянемо кілька прикладів:
- Інтеграція із платіжною системою. Щоб протестувати її, потрібно врахувати, які податки та комісії стягуються, на яких етапах, у яких розмірах.
- Протестувати, як працює інтеграція, коли користувач хоче забрати свої гроші назад. Це також може оподатковуватися залежно від країни і провайдера.
- Поповнення рахунку. Це одна з найрозповсюдженіших фіч, але вона ускладнюється, якщо потребує верифікації особистості.
Крім того, робота із грошима – це завжди велика відповідальність як перед користувачами, так і перед провайдерами та нашою компанією. Ми маємо забезпечити безпеку інформації та одночасно швидку роботу платіжної системи.
З технічного погляду це ускладнюється тим, що архітектурно наш бекенд розділений на декілька прошарків, кожен з яких відповідає за свою частину роботи платіжної системи. Тож нам потрібно з нуля розробити весь сценарій, як платіжна система працюватиме на кожному із цих прошарків, враховуючи її особливості.
Як виглядає процес тестування інтеграцій
Процес починається з того, що замовник реалізації висуває свої вимоги. Потім бізнес-аналітик оформлює їх у чітке завдання. Водночас провайдер – платіжна система, яку ми інтегруємо – надає свою документацію. Там зазвичай описані стандартні API-запити, які ми можемо використовувати.
Ми вивчаємо цю документацію і паралельно описуємо, як наша система має взаємодіяти із системою провайдера. Після цього створюємо тест-кейси та чеклісти, як і що саме потрібно тестувати.
Найчастіше ми перевіряємо, чи може користувач поповнити рахунок. Це базова фіча для будь-якої платіжної системи. Для неї в нас є готові інструкції й мануали, на які ми орієнтуємося. Якщо в команду заходить новенький – це частина його онбордингу.
Такі самі інструкції є і для інших фіч і процесів: виведення коштів, верифікації користувача, платежів. Але в роботі з кожним конкретним випадком усе одно виникає багато нюансів.
Найважливіше – завжди звірятися з документацією. Якщо ми робимо описаний у ній запит, а він не працює, то звертаємось до провайдера: можливо, ми неправильно зрозуміли ендпоїнти або реалізація мала бути іншою.
У платіжних інтеграціях усе пов’язане. Неможливо протестувати виведення коштів, не протестувавши поповнення. Або, наприклад, буває, що платіжна система заблокована іншими частинами проєкту. Щоб повноцінно її протестувати, потрібно узгодити це з іншими командами.
Важливо також, щоб у команді були універсальні фахівці – тоді не виникатиме ситуація, коли все зав’язане на одній людині. Якщо виникає форс-мажор або хтось вибуває із процесу, інший може підхопити задачу.
Середовища, з якими ми працюємо
Більшість платіжних провайдерів надає нам тестове середовище. Ми під’єднуємо до нього своє та обмінюємося між собою фейковими грошима. Якщо таке середовище є, ми можемо повноцінно перевірити функціонал і покрити майже 100% кейсів, у тому числі нестандартні.
Але трапляється, що тестового середовища немає. На такі випадки є MOCK-сервіс. Ми прописуємо, які ендпоїнти будуть, яку відповідь вони мають повертати, і таким чином моделюємо поведінку реального сервісу.
У такому разі тестуємо на продакшені. Беремо реальні тестові картки, які нам надає компанія, створюємо під них тестові акаунти і вручну проходимо флоу, як звичайний користувач.
Ще одна складність – неочікувані зміни в тестових середовищах. Іноді нам про них не повідомляють або повідомляють пізно. У таких випадках нас рятує гнучкість нашої архітектури. Нам не потрібно переписувати весь код, тому що зазвичай зміни стосуються окремих модулів. Ми перевіряємо їх і водночас дивимось, чи не зламалася взаємодія з іншими частинами системи.
Хоч ми й намагаємося врахувати максимум сценаріїв, один з найважливіших принципів у тестуванні – це те, що вичерпне покриття неможливе. Ми не можемо протестувати абсолютно всі варіації поведінки користувача, особливо на проді. Але завжди орієнтуємося на вимоги як бізнесові, так і користувацькі.
Перед релізом проводимо кілька рівнів перевірки: на тестовому середовищі, на стейджі (сендбоксі), на препродакшені. Лише після цього ми виходимо на прод. Плюс перед релізом завжди показуємо демо замовнику. Якщо він дає фінальне «так» – версія йде у продакшен.
Типи тестів: що, як і навіщо перевіряємо
Ми використовуємо кілька типів тестів:
- Юніт-тести – зона відповідальності розробників. Вони покривають свій код і перевіряють, як працює логіка окремих компонентів.
- Інтеграційні та системні тести – це вже наша зона. Їх виконують тестувальники – і мануальні, і автоматизатори. Ми перевіряємо, як одна частина системи працює у зв’язці з іншою і як усе це інтегрується в наш багатошаровий бекенд. Такий підхід обовʼязковий, бо часто буває, що окремий модуль працює ідеально, але при взаємодії з іншими виникають помилки.
- Контрактні тести – це перевірка API. Тобто ми відправляємо запит і перевіряємо, чи отримаємо саме ту відповідь, яка описана в документації провайдера і яка нам потрібна для роботи нашої системи. Кожен запит ми тестуємо на всіх рівнях як у нашій системі, так і в системі провайдера.
Контрактні тести проходять у два етапи. Спочатку ми все перевіряємо вручну – тестувальники самі «пробивають» запити, аналізують відповіді. Якщо все працює як треба – передаємо флоу на автоматизацію. Це важливо для того, щоб зменшити ризик людської помилки та в майбутньому спростити підтримку.
На сьогодні в нас автоматизовано близько 70% актуального функціоналу. І це дійсно полегшує роботу. Але попри це, ми не можемо обійтися без мануального тестування.
Чому? Бо кожен флоу, який ми тестуємо, досить специфічний. Завжди є свої нюанси:
- в одній платіжці потрібно вводити CVV, в іншій ні;
- десь є обов’язкова верифікація гаманця або користувача, а десь немає.
Є й випадки, коли автоматизація не покриває певні ситуації. Скажімо, якщо автотест занадто часто робить однаковий запит, то банківська система може сприйняти це як фрод і заблокувати картку.
У майбутньому кількість мануальних тестувальників може зменшитись, але повністю відмовитися від ручного тестування нереалістично. Наш клієнт – жива людина, тож вона здатна створити ситуацію, яку жоден автотест не передбачить. Єдиним дієвим підходом стає синергія: автоматизація плюс уважна ручна перевірка.
Як ми виявляємо й обробляємо проблеми
Більшу частину проблем ми ловимо під час тестування, але деякі виявляються вже після релізу – через скарги користувачів або інциденти на продакшені.
Перша лінія, яка приймає скаргу – це сапорт. Якщо в користувача щось не спрацювало під час оплати, він звертається саме до нас. Іноді сапорт сам і розбирається із проблемою. Наприклад, звʼязується із провайдером і дізнається, що збій був на його боці. Якщо ж причина неочевидна, скарга потрапляє до нас як потенційний баг.
Нашим основним інструментом розслідування є логи. Ми працюємо із Grafana, яка показує повну картину того, що відбулося в системі. Якщо бачимо, що все працювало за флоу, але провайдер повернув помилку – передаємо інформацію йому. Якщо бачимо, що проблема на нашому боці, то передаємо розробникам.
У звичайному режимі ми самостійно не моніторимо прод, цим займаються інші команди: сапорт, розробники. Але коли йде реліз, ми під’єднуємося до моніторингу, бо відповідальні за той функціонал, що щойно вийшов.
Типові ризики та виклики і як з ними працюємо
Платіжна інтеграція – це завжди зона підвищеної відповідальності. Найбільший ризик – звичайно, втрата грошей. Якщо транзакція не проходить, користувач може втратити кошти або просто не зможе поповнити рахунок. А для бізнесу це недоотриманий прибуток.
Але не всі ризики фінансові. Наприклад, якщо в інтерфейсі не відображається логотип платіжної системи або відсутня інформація про транзакцію, це може здаватися дрібницею. Насправді такі деталі впливають на довіру користувача до продукту. Тому, хоч ми і приділяємо найбільшу увагу грошовим флоу, усе інше теж критично.
Ще один серйозний виклик – нестабільні провайдери. Якщо у платіжної системи повільна комунікація або нестабільне тестове середовище, ми не можемо рухатись з потрібною швидкістю. Такі кейси траплялись. І саме після них ми почали закладати цей ризик в естімейти, аналізувати документацію ще уважніше та ретельніше перевіряти, чи підтримує API усе, що нам потрібно реалізувати.
На що звертати увагу: поради з досвіду
Загалом, якщо все добре описане та команда компетентна, навіть найскладніші реалізації можна зробити якісно. Ось ще кілька порад наостанок:
- При естимації обов’язково враховувати ризики з боку провайдера. Це може вплинути не тільки на строки реалізації, а й на якість продукту на виході.
- Прискіпливо аналізувати API провайдера. Треба ще до старту переконатися, що весь функціонал, який ми закладаємо у своїх вимогах, реально підтримується та може бути реалізований.
- Мати доступ до тестових акаунтів і гаманців. Інакше це не буде близько до реальних умов.
Ну і звісно, щоразу, коли ми щось інтегруємо, ми враховуємо всі помилки, які були раніше. Аналізуємо їх, покриваємо тестами, робимо висновки. Це дуже допомагає.
Повідомити про помилку
Текст, який буде надіслано нашим редакторам: