QA Interview Hub · База знань · Тести

Manual QA

Специфіка фінтеху

гроші, платежі, транзакції

Що перевіряти в розрахунках з грошима?

  • Точність: гроші не можна рахувати у float — 0.1 + 0.2 ≠ 0.3. Правильно: decimal або цілі мінімальні одиниці (копійки, центи).
  • Округлення: яке правило (вгору, до найближчого, банківське до парного) і на якому кроці. Різні кроки дають різну суму.
  • Мінімальні одиниці валют: у гривні й доларі 2 знаки, в єні 0, у бахрейнському динарі 3.
  • Розподіл: 100 грн на трьох — 33.33 + 33.33 + 33.34, сума має зійтися.
  • Відображення: роздільники тисяч і десятків, знак валюти, від'ємні суми.
На співбесіді: Я перевіряю, що гроші рахуються без float, бо там виникають помилки на кшталт нуль одна плюс нуль дві не дорівнює нуль три. Уточнюю правило округлення і крок, де воно відбувається, кількість знаків для кожної валюти і що при розподілі сума сходиться до копійки.

Які стани має платіж і що в них тестувати?

Типово: створено → в обробці → авторизовано (кошти заблоковано) → списано → розраховано, з відгалуженнями «відхилено», «скасовано», «повернено», «частково повернено».

Що тестувати:

  • Кожен валідний перехід і заборону невалідних (повернення відхиленого платежу).
  • Баланс на кожному стані: доступний і заблокований.
  • Тайм-аут провайдера: платіж не зникає і не дублюється, стан з'ясовується пізніше.
  • Часткове повернення: сума повернень не перевищує суму платежу.
  • Сповіщення користувачу на кожному стані.
На співбесіді: Платіж проходить стани від створення до розрахунку, з гілками відхилення, скасування й повернення. Я тестую всі валідні переходи й заборону невалідних, баланс на кожному етапі, поведінку при тайм-ауті провайдера і що сума часткових повернень не перевищує суму платежу.

Які типові ризики в платіжних сценаріях?

  • Подвійне списання: подвійний клік, ретрай, кнопка «Назад».
  • Гонки: два паралельні перекази з балансу, якого вистачає лише на один.
  • Обрив зв'язку після відправки, але до відповіді — який стан бачить користувач?
  • Ліміти: денні, місячні, на одну операцію; що відбувається на межі доби.
  • Часові пояси: «сьогодні» для ліміту — за часом сервера чи користувача? Що з операцією о 23:59?
  • Валюти: курс фіксується в момент створення чи списання?
На співбесіді: Головні ризики — подвійне списання, гонки при паралельних переказах, обрив зв'язку посеред операції, ліміти на межі доби, часові пояси і момент фіксації курсу валют. Подвійний клік і дві вкладки з тим самим переказом я перевіряю в кожному платіжному сценарії.

Що таке звірка (reconciliation) і як її тестувати?

Звірка — порівняння даних нашої системи з даними банку чи платіжного провайдера: кожна операція в нас має відповідну у провайдера, з тією самою сумою і статусом.

Тестую: повний збіг; операція є в нас, але немає у провайдера, і навпаки; розбіжність суми чи статусу; дублікати у файлі провайдера. Перевіряю, що розбіжності потрапляють у звіт або чергу на ручний розбір, а не губляться.

На співбесіді: Звірка порівнює наші операції з даними банку чи провайдера. Я тестую не лише повний збіг, а й розбіжності: операція є тільки в одній системі, різні суми чи статуси, дублікати. Головне — що кожна розбіжність потрапляє у звіт на розбір, а не зникає.

Що треба знати про безпеку і комплаєнс у фінтеху?

  • PCI DSS — стандарт для даних карток: повний номер маскується (видно лише останні 4 цифри), CVV не зберігається ніде, включно з логами.
  • GDPR — персональні дані: мінімізація, право на видалення, згода.
  • KYC / AML — перевірка особи клієнта і протидія відмиванню коштів: обмеження до верифікації, підозрілі операції.
  • Аудит: кожна фінансова операція і зміна налаштувань має запис хто, що, коли.
  • SCA / 3-D Secure — підтвердження платежу кодом або в застосунку банку.

Як QA перевіряю це на рівні поведінки: що номер картки замаскований в UI, відповідях API і логах, що неверифікований користувач упирається в ліміти.

На співбесіді: Я знаю базові вимоги: PCI DSS — номер картки маскується, а CVV ніде не зберігається, навіть у логах; GDPR для персональних даних; KYC і AML для перевірки клієнтів; аудит усіх фінансових дій; підтвердження платежів через 3-D Secure. Як QA я перевіряю це на рівні поведінки — в UI, у відповідях API і в логах.