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 і в логах.