Worldwide-біллінг Badoo очима QA


Привіт, Хабр! Ось уже більше чотирьох років я займаюся ручним і автоматизованим тестуванням білінгових систем Badoo. А біллінг Badoo — один з найбільш розвинених (і складних) в світі, і тестувати його — найчастіше цікава і неординарна завдання. Сьогодні я хочу вам розповісти, чому ці системи такі цікаві і могутні, чого я навчився за всі ці роки і чому тестувати біллінг — це не (дуже) страшно. І заодно поділюся з вами черговою партією цікавих історій (так, я цю справу дуже люблю). Більшість речей буде застосовно не тільки до нашого конкретного випадку, але і до будь-якої іншої складної платіжній системі (і не тільки платіжної, якщо чесно).

Що ж таке наш біллінг? Це система обробки платежів в соціальній мережі, в якій понад 330 мільйонів зареєстрованих користувачів. Ми приймаємо платежі у всіх країнах світу, підтримуємо понад тридцять активних платіжних методів (а за весь час їх було імплементовано близько ста) і обробляємо близько 1500 запитів в секунду. Біллінг Badoo є самостійним виділеним сервісом, що працюють з десятком різних клієнтів (різні платформи, різні додатки). Досить цікава база для розвитку тестування, чи не так? :)

Об'єкт тестування
Отже, для початку коротко розповім, що саме нам доводиться тестувати. Всі наші клієнти (веб, мобільні програми та деякі back-end сервіси) спілкуються з білінгом за допомогою API. Сам же біллінг розташовується на окремому кластері в кожному з наших дата-центрів і веде спілкування з різними платіжними системами (надсилає запити на оплату, отримує нотифікації з результатом обробки запитів тощо). У кластері розташовуються машини для обробки звернень клієнтів та платіжних систем, машини для запуску CLI-скриптів (наприклад, для оновлення стікали підписних сервісів), наш власний сервер обробки платежів банківськими картами і бази даних.



Розробники білінгу займаються вирішенням завдань декількох видів:

  • розробка нового функціоналу: нові платні сервіси, промо-кампанії, різні фічі для передплатників;
  • розробка нових інтеграцій з платіжними сервісами (завжди можна знайти когось з більш низькими комісіями або більш високою конверсією);
  • актуалізація наявних інтеграцій (наші партнери теж розвиваються);
  • виправлення багів (давайте визнаємо — у всіх вони бувають!);
  • задачі з оптимізації та рішенням технічного боргу (завжди можна зробити сервіс трохи краще);
  • рішення задач технічної підтримки (дуже любимо самих хитрих користувачів, які примудряються створити десяток підписок на різних платіжних сервісах в різних країнах і потім плутаються, як же скасувати непотрібні).
І все це «добро» в кінцевому підсумку приходить на тестування нашій невеликій команді. Крім завдань безпосередньо від білінгових розробників, ми отримуємо завдання і від інших команд, якщо вони як-небудь стосуються платежів: наприклад, зміни та нові фічі на клієнтах або сервері мобільних додатків.

Що ж саме ми тестуємо? Можна розбити на три категорії:

  • користувальницькі інтерфейси: всілякі платіжні вікна (ми називаємо їх «визардами») на різних платформах, вікна налаштувань, рекламні банери, промо-віконця і т. д.;
  • «адмінку» і конфігураційні інструменти: налаштування цін, промо-кампаній, експериментів та інструменти для техпідтримки (якими ми ще й дуже активно користуємося при тестуванні);
  • білінговий back end: обробка платежів, черги, надання послуг і проведення різних відкладених операцій (найскладніша і «соковита» частина).
Постараюся вам про все це розповісти по порядку.

Користувальницькі інтерфейси
Отже, найголовніша частина тут — платіжні визарды. Виконуючи одну і ту ж функцію (отримання від користувача інформації про те, скільки сервісу він хоче придбати і яким способом він хоче це зробити), визарды виглядають по-різному на різних платформах. Залежить це, в першу чергу від особливостей платформи, але також і від різних вимог регуляторів і від незліченних A/B тестів, які проводяться на наших програмах.

Що ж тут можна протестувати? Так море всього! Кожен платіжний метод повинен відображатися коректно при будь-якому вибраному варіанті сервісу. Список самих варіантів повинен відповідати бажаному, на кожному з них повинна бути вказана задана у налаштуваннях білінгу ціна, при цьому формат ціни і валюти повинен відповідати прийнятим у країні стандарту, наприклад: $6,49, 125,00 MXN або 17.64 BYN.

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

Будь-яка дія користувача в таких вікнах повинно супроводжуватися коректними повідомленнями, причому не тільки про успішних платежах, але й про помилки (потрібно вміти відрізняти ситуації, коли користувач скасував платіж на стороні партнера, а коли реально ввів некоректну інформацію).

Здавалося б, можна скласти для всього цього звід базових перевірок і обмежитися їм. Не тут-то було! У кожній країні є свої обов'язкові до виконання вимоги, яких необхідно дотримуватися, щоб мати можливість вести бізнес. Наприклад, при оплаті через СМС в Бельгії короткий номер для оплати потрібно обов'язково перетворювати великими білими цифрами в чорному прямокутнику (я не жартую). У Франції деякий час на КОЖНІЙ сторінці сайту повинна була знаходитися кнопка на відписку від наявного передплатного сервісу, а сама відписка досі повинна проводитися в один клік, без будь-яких підтверджувальних кроків. У деяких країнах потрібно обов'язково повідомляти, що ціна включає в себе податки, а в деяких інших навіть окремо вказувати вартість послуги та додаткові податки (і ніде не писати їх у сумі).

Як же перевіряти такий «зоопарк» платіжних методів? Їздити по всім країнам світу для максимально чесного тестування не вийде (а так хотілося б потестувати платежі в Бразилії, хнык), рівно як і заводити акаунти у всіх існуючих платіжних системах. Тому доводиться задовольнятися різними «пісочницями». Деякі партнери надають нам власні дуже зручні пісочниці, наприклад, агрегатори банківських карт або PayPal. Деякі з них не так функціональні: у одного з партнерів вона являє собою скріншот їх звичайного платіжного вікна з накладеним на нього кнопкою «Заплатити».

В інших випадках будувати пісочниці нам доводиться самим, емулюючи різні відповіді і нотифікації. Але навіть це виходить не скрізь, і доводиться руками збирати нотифікації, робити якісь підміни в коді і відправляти їх собі https-запитів.

Зовсім окремим головним болем є визарды в мобільних додатках. Тут користувач спілкується з білінгом ще більш опосередковано. Додаток надсилає запит до платіжної системи (AppleStore або GoogleWallet, наприклад), отриманий відповідь відразу ж відсилає на сервер мобільних додатків, той, у свою чергу, обробляє інформацію і посилає новий запит на білінговий кластер, а відповідь білінгу проходить весь цей шлях назад у платіжну систему. «Юзер-експірієнс» може зламатися в будь-якому місці цієї ланцюжка! Хмарка про помилку може означати, що запит не дійшов до білінгу і платіж не здійснений, а цілком може означати і те, що все пройшло чудово, але сервер мобільних додатків відповів платіжній системі не зовсім в тому форматі, який вона очікувала. Бардак!

І давайте навіть не будемо тут говорити про те, які незручні пісочниці у Apple і Google, особливо при спробах тестувати підписки.

Між іншим, сам факт роботи з зовнішніми партнерами приносить з собою чимало проблем. Їх платіжні вікна можуть відкриватися довго і гальмувати тестування, вони можуть містити в собі звичайні баги (які ти, як поважаючий себе тестувальник, насамперед приписываешь власним розробникам). Будь-які дії, які потребують співпраці з їхнього боку (фікси тих же помилок, розширення протоколу) теж часто затягуються, причому вони можуть самостійно робити якісь зміни, не поставивши нас до відома (про що ми дізнаємося тільки за зрослими графіками помилок), та надавати нам неповну або навіть некоректну документацію.

Адмінка
Нітрохи не менш важлива складова білінгу повністю прихована від очей наших користувачів. Це все те, що дозволяє нашому менеджменту регулювати ціни і доступність сервісів і запускати промо-кампанії, а трудівникам служби технічної підтримки — виявляти причини проблем користувача (і переконуватися в тому, що вони не намагаються просто отримати сервіс «на халяву») і максимально простим і безпечним способом їх вирішувати. До того ж всі ці засоби допомагають нам у тестуванні (відтворювати багато кейси виключно діями в інтерфейсі користувача або досить складно, або дуже довго).

Крім безпосередньої перевірки працездатності тут потрібно багато часу приділяти тому, щоб розробники і менеджери сприймали реалізований функціонал однаково (продуже часто тільки ми справляємося з тим, щоб встановити між ними контакт і повне взаєморозуміння). Всі конфігураційні системи досить складні з-за широкого спектру можливостей (у нас постійно проводяться десятки A/B тестів дизайну, платіжних методів і промо-кампаній), і найменші деталі можуть призвести до того, що система буде вести себе зовсім не так, як очікує менеджмент. У наші обов'язки входить упевнитися в тому, що розробник правильно зрозумів завдання, а менеджер зміг розібратися в наданій документації (якщо така взагалі є). Ну і звичайно, дуже здорово після кожної зміни конфигураторов стежити за результатами їх роботи і кілька разів уточнювати, чи насправді всі хотіли зробити ось ЦЕ ось.

А ще тут треба похвалитися, що один з розроблених (і звичайно ж протестованих!) нами інструментів для роутінга платежів картками на потрібні банки і акаунти нам приніс нам престижну нагороду Merchant Spotlight Award.

Back end
А ось тут починається найцікавіше. Те, що приховано від очей звичайних користувачів; те, про що навіть не хочуть нічого знати менеджери; те місце, де втілюються самі жахливі фантазії наших розробників — внутрішня логіка обробки платежів і надання сервісів

Тут тестується просто сила-силенна всіляких речей.

  • Звернення до партнерських систем: перевірка статусів підписок (іноді ми ніяк не можемо керувати ними зі свого боку, і залишається тільки перевіряти, що вони все ще активні), запити на оновлення та скасування підписок і багато іншого.

  • Обробка нотифікацій від партнерів: ми повинні правильно обробити кожну нотифікацію (адже у кожного партнера свій власний формат і протокол!), визначити юзера, сервіс і всі можливі параметри, щоб нічого не переплутати. Іноді нотифікації взагалі нічого не значать: «Дивіться, ми все ще не змогли списати гроші з користувача!»;, іноді вони суперечать самі собі: «Користувач скасував платіж :( А ні, ось і гроші прийшли!»; іноді вони зовсім не актуальні: «Пам'ятаєте ту підписку три роки тому? Так ось, вона все ще минула!» — і ми повинні придумати правильний «флоу» для кожного можливого випадку.

  • Надання послуг: щоб не втратити в разі проблем замовлення користувачів, послуги виявляються через черги. Якщо щось пішло не так — подія відкладається, і будь-яка послуга у будь-якому випадку повинна бути доставлена до користувача. Ось це «в будь-якому випадку» ми і повинні гарантувати при тестуванні.

  • Оновлення підписок: якщо користувач підписаний на певні послуги, він повинен їх отримувати вчасно. Ми не повинні «чарджить» його раніше або пізніше часу, з нього завжди повинна списуватися саме та сума, на яку він підписувався. Крім того, у нас існує багато різної логіки вибору часу оновлення підписок в різних країнах (або це наші експерименти, або вимоги регуляторів). Наприклад, де-то ми «чарджим» користувачів тільки в робочий час, десь тільки в певні дні тижня.

  • Платежі за наявними даними: як і в будь-якій поважаючій себе платіжній системі, у нас користувач може зберегти деталі свого платіжного методу для того і наступного разу платити швидше. Ми повинні перевіряти, що деталі зберігаються безпечно (для банківських карт, наприклад, нам потрібно дотримуватися PCI DSS), що платежі проходять і коректно обробляються випадки, коли деталі більше не валідні (наприклад, картка користувача заблокована).

  • І так далі, і тому подібне.
Кількість різної логіки в серверному коді просто безмежно. Кожна нова задача перетворюється на цікавий квест виду «Розберися, як воно працює => Розберися, як воно МАЄ працювати => Розберися, як змусити систему працювати». Якими способами цього потрібно домагатися?

По-перше, потрібно читати код. Тестувати біллінг як чорний ящик практично неможливо: тільки маючи уявлення про те, як працює система, можна зрозуміти, які кейси тут можна протестувати. Крім того, дуже часто для успішного тестування потрібно робити зміни в коді: прибирати звернення до агрегаторів (щоб ми не запитували у них статус неіснуючої тестовій підписки), підміняти перевірку підпису для нотифікацій (щоб не треба було кожного разу її генерувати) або «хардкодить» вибір певного варіанту A/B тесті (щоб не реєструвати десятки користувачів, що потрапляють на потрібні групи). На щастя, ми всіма силами розвиваємо тестировочные утиліти, щоб ці процеси спростити.

По-друге, не потрібно боятися тестувати речі неочевидними способами. Не можна напевно відтворити кейс з інтерфейсу? Можна написати функціональний тест! Можна полізти в тестову базу «ручками» і заповнити потрібні дані! Можна зібрати нотифікацію від партнера вручну і відправити її на власний адресу! Головне — не боятися забиратися в нетрі.

по-третє, розробник — ваш друг. Спільний цікавий дебаг — захоплююче (завжди) і сплачивающее команду (крім випадків, коли ти хочеш придушити девелопера) справа. Разом розібратися з несподіваною поведінкою куди простіше. І ви або зрозумієте свої помилки і виправдаєте завдання, які знайдете справжню проблему і дозволите девелоперу повернутися до її доопрацювання, вже маючи якесь уявлення про ситуації (або розібратися в ситуації нового девелоперу, якщо старий вирушив у відпустку).

Автоматичне тестування
Автотесты — це дуже класна річ. І насправді перетестировать тут куди краще, ніж недотестировать. Безпосередньо у нас все автотесты можна поділити на чотири групи:

  • юніт-тести: пишуться розробниками під час роботи над завданням. У нашому процесі завдання вважається вирішеним, поки вона не покрита тестами;
  • інтеграційні тести: пишуться розробниками (і іноді тестерами) на етапі тестування для перевірки тих, що важко відтворюються місць. Продовжують підміняти частину коду, як і юніт-тести, але працюють з набагато більш широким пластом сутностей одночасно;
  • системні Selenium — і Calabash-тести: тестують клієнт так, як його бачить користувач. Не ідеально стабільні, досить повільні, але дуже корисні, оскільки дозволяють знаходити ще і проблеми, викликані завданнями інших відділів;
  • системні curl-тести: досить новий напрямок. Вони перевіряють загальну працездатність системи на тисячах різних кейсів: ми отримуємо платіжні визарды всіх сервісів, всіх їх варіантів, в кожній країні світу, на кожному платіжному методі. Перетестирование як воно є.
Коли ці тести запускаються? В різних комбінаціях це відбувається постійно:

  • розробники запускають тести вручну при роботі над завданням;
  • вони автоматично запускаються при переході завдання в статус «Готово»;
  • QA-інженери запускають їх вручну при тестуванні;
  • вони запускаються кожен раз при складанні кожної нової версії білду;
  • в кінцевому рахунку вони постійно і регулярно запускаються на препродакшене.
Звичайно, всі ці автотесты займають істотне час, і тому ми завжди прагнемо максимально оптимізувати цей процес. Для інтеграційних та юніт-тестів (а з недавніх пір і для curl-тестів) у нас застосовується хмарна «пускалка» тестів (вже більше 73 тисяч тестів за 4 хвилини!). Для Selenium-тестів у нас працює «велика ферма» кластера SeleniumGrid. Та й у цілому робота з поліпшення й оптимізації тестів ніколи не припиняється.

Моніторинг
Робота тестувальника над завданням не припиняється відразу ж в той момент, як завдання відправляється на продакшен. Переконатися в тому, що вона витримує напругу роботи у бойовому оточенні, можна лише шляхом уважного моніторингу. Не з'явилися в логах нові несподівані помилки (так, очікувані помилки бувають, це нормально)? Не зросла навантаження на білінговий кластер? Не почала падати (або різко зростати, що теж зазвичай дивно) прибуток в якій-небудь країні або в якому-небудь платіжному методі? В Badoo є чудовий відділ моніторингу, який цілодобово стежить за всіма метриками в ручному і автоматичному режимах. Однак їм у будь-якому випадку знадобиться якийсь час для того, щоб самостійно з'ясувати причини тих чи інших аномалій. Тому QA-інженер зобов'язаний уважно проводити своє завдання (останній) бій.

Для цих цілей ми використовуємо декілька різних систем, найважливішими з яких є три:

  • RRD Tool: RRD ми зберігаємо логи помилок і дебага, графіки безлічі основних показників (прибуток, кількість платежів, кількість наданих сервісів, розміри черг);
  • Splunk: чудова система, з допомогою який ми в реальному часі аналізуємо всі білінгові події, можемо будувати різні графіки про кількість тих чи інших запитів до білінгу та багато-багато іншого;
  • Anomaly Detection: наша власна система для виявлення аномалій, автоматично повідомляє про несподіване поведінку тієї або іншої метрики. На відміну від перших двох систем ця працює в повністю автоматичному режимі.
Що ж можна вважати аномаліями на білінгових графіках? Давайте подивимося на цей графік у Польщі. Кожна точка показує сумарний прибуток за останні добу, масштаб графіка — теж добу.


Кошмар, страшне падіння прибутку, треба бити в усі дзвони! Але що це таке? Відкриваємо графік за місяць…


Що за неподобство? Виявляється, так працюють мобільні агрегатори в Польщі. Вони проводять всі оновлення підписок тільки в конкретний день тижня, наприклад, у вівторок. Якщо юзер підписався в понеділок на тиждень, то… все одно «зачарджат» у вівторок! Такі вже в Польщі порядки. І кожен пік — «заповітний» день тижня того чи іншого агрегатора.

Дивимося далі. Аналогічний графік прибутку від AppleStore за тиждень з 24 числа по 1 число наступного місяця:


Починаємо відразу ж лякатися? Звичайно! Таке падіння, ніякого зростання за добу — однозначна проблема! Поки ми стрімголов носимося по офісу і волаємо, проходять добу. І що ж ми бачимо?


Графік відновився сам собою! Магія? Катастрофічні помилки? Змова рептилоидов? Зовсім ні, це політика Apple. Вони завжди роблять оновлення підписок в той же день місяця, в який підписка була заведена. Але що ж відбувається в лютому з тими, хто починав підписки 30 або 31 числа: вони щасливо сидять цілий місяць безкоштовно? Звичайно, немає, їх «чарджат» 28 лютого. І з тих пір починають чарджить тільки 28 числа. Тому на кінець місяця припадають ось ці два піки (28 число для лютого і 30 число для всіх інших «коротких» місяців), а 31 числа не оновлюються взагалі ніякі підписки зі строком більше місяця.

Як бачите, моніторити теж потрібно з розумом. Як я вже говорив, перетестировать — це не так погано, але наловити стусанів від розробників за зайва паніка теж можна.

Замість висновку
Тестування білінгу — цікаве й цікава справа. В ньому є багато неординарних речей, підводних каменів і нікому толком не відомих закутків, але рішення майже кожної задачі — справжній квест, по завершенню якого відчуваєш абсолютне відчуття тріумфу. Дуже шкода, що про цю сферу тестування йдеться не так багато (а на конференціях я неодноразово чув речі типу «А біллінг ми тестуємо на продакшені»). Розраховую, що моя стаття допоможе кому-небудь інакше поглянути на процеси тестування у своїй компанії і, можливо, вирішити трохи щільніше тестувати свої платіжні системи. Та й взагалі будь-які низькорівневі речі. Повірте мені, це дійсно не нудно!

Кудінов Ілля, Sr. QA Engineer
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.