09.01 Test Strategy And Definition Of Done

Статус: черновик для обсуждения

1. Назначение документа

Этот документ описывает test strategy и Definition of Done для MVP.

Test strategy - это не список конкретных тест-кейсов.

Test strategy отвечает на вопросы:

• какие части системы обязательно должны быть покрыты тестами;
• какие flow должны проверяться end-to-end;
• какие проверки блокируют release;
• что считается минимальным качеством для MVP.

Definition of Done - это критерии, без которых feature / release нельзя считать готовыми.

2. Основной принцип

MVP нельзя принимать только потому, что UI выглядит готовым или happy path вручную прошел один раз.

Система работает с деньгами, routing, provider integrations, webhooks, permissions и secrets.

Поэтому release должен блокироваться любым fail-ом в обязательных test layers.

Правило:

Any required test failure blocks release.

3. Unit tests

Unit tests обязательны для domain logic.

Unit tests должны покрывать:

• routing rule evaluation;
• routing sequence / priority logic;
• routing fallback logic;
• MASTER MID GROUP selection;
• SUB MID GROUP selection;
• velocity limits;
• FX conversion;
• conversion fee;
• processing fee;
• fee thresholds;
• transaction status transitions;
• provider callback status mapping;
• merchant webhook payload mapping;
• error mapping;
• permissions/visibility business rules, если они реализованы как domain logic.

Unit tests должны быть быстрыми и запускаться в CI.

4. E2E tests

E2E tests обязательны для полного deposit flow.

Минимальный E2E должен покрывать flow:

1. Merchant вызывает POST /api/v2/deposit.
2. Система создает transaction.
3. Merchant получает hosted payment URL.
4. Routing выбирает execution path.
5. Hosted payment form открывается.
6. Provider request выполняется через test provider / mocked provider.
7. Provider callback принимается gateway-ом.
8. Callback обрабатывается системой.
9. Transaction получает expected status.
10. Merchant webhook отправляется.
11. Webhook payload соответствует контракту.
12. Transaction видна в Back Office.
13. Timeline содержит понятный flow.

E2E tests должны покрывать не только happy path, но и ключевые failure cases:

• duplicate merchant transactionId;
• missing required request field;
• routing not found;
• provider callback with final status;
• webhook delivery failure and retry;
• velocity exceeded with fallback;
• all routing candidates exhausted.

5. Hosted payment form tests

E2E / integration tests должны покрывать hosted payment form dynamic fields.

Нужно проверить:

• hosted form получает transaction/session data;
• если SUB MID требует дополнительные customer fields, form показывает эти inputs;
• fields, уже переданные merchant-ом, prefilled и read-only;
• customer заполняет missing fields;
• система сохраняет collected fields in transaction customer context;
• provider execution продолжается после заполнения fields;
• expired transaction/session показывает expected error state.

6. Contract tests

Contract tests обязательны для Merchant API и merchant webhook.

Contract test - это тест, который проверяет, что public API contract не сломан.

Пример:

• create deposit request принимает согласованную schema;
• create deposit response содержит expected fields;
• error response содержит errorCode и description;
• webhook payload содержит все agreed fields;
• webhook payload не содержит лишние fields, которые мы решили не отдавать;
• errorCode и errorDescription присутствуют в webhook payload always, even when null;
• HMAC/signature headers соответствуют выбранному формату.

Contract tests нужны, чтобы development team случайно не изменила API response или webhook payload так, что merchant integration сломается.

7. Provider adapter tests

Provider adapter tests обязательны.

Так как реальные providers могут быть нестабильными или недоступными в test environment, MVP должен иметь test provider and/or mocked provider responses/callbacks.

Для MVP нужен test provider, который поддерживает все MVP payment methods and sandbox flow.

Provider adapter tests должны проверять:

• request mapping from canonical transaction/customer fields to provider-specific format;
• response parsing;
• callback validation;
• callback status mapping;
• amount/currency matching;
• provider transaction ID mapping;
• account reference extraction, если provider возвращает account/IBAN/reference;
• provider error mapping to unified internal error code;
• timeout/error handling;
• ignored/rejected/duplicate callback behavior.

Test provider / sandbox tests должны проверить:

• all MVP methods supported by test provider;
• hosted redirect URL returned;
• PROCESSING simulation;
• COMPLETED simulation;
• FAILED simulation;
• CANCELED simulation;
• REJECTED simulation;
• provider timeout simulation;
• provider error response simulation;
• merchant/admin can choose/simulate expected test outcome;
• test transaction marker visible in Back Office;
• test transaction sends merchant webhook;
• test transaction can participate in velocity/fees/turnover in test context.

Duplicate callback, ignored callback / unknown status, amount/currency mismatch and invalid callback signature can be tested through automated/integration tooling and do not require dedicated merchant-facing test provider controls.

8. Migration tool validation

Для temporary migration tool автоматические tests в MVP не обязательны.

Достаточно manual validation and immediate report.

Manual validation должна проверить:

• source old merchantId / old merchantConfigId valid;
• target merchantId / brandId / paymentMethodId valid;
• imported transactions marked as legacy;
• imported transactions read-only;
• old IDs saved;
• webhooks are not sent for migrated transactions;
• report contains total/success/failed/skipped/errors.

9. Performance / load tests

До MVP acceptance нужно выполнить performance/load test.

После MVP release load test нужно выполнять периодически:

once per month

Цель monthly load test - убедиться, что новые changes в routing, callbacks, webhooks, queues, database indexes и Back Office-heavy operations не ухудшили performance системы.

Target:

• support 5 million transactions per month;
• baseline около 2 transactions per second;
• peak 10 transactions per second for 5 minutes.

Load test должен проверить:

• create deposit API;
• transaction creation throughput;
• routing execution;
• queue processing;
• callback handling;
• merchant webhook dispatch;
• database/index behavior for transaction writes and timeline events.

Exact test implementation должна быть предложена development/QA team.

10. Resilience tests

Resilience test обязателен для asynchronous gateway requirement.

Нужно проверить:

• gateway принимает merchant deposit requests, когда core service временно недоступен/restarting;
• accepted requests сохраняются durably;
• после восстановления core service requests продолжают processing;
• provider callbacks быстро принимаются gateway-ом и кладутся в queue;
• callback processing продолжается после восстановления core service;
• merchant webhook delivery не теряется.

Цель: internal restart/lag не должен ломать merchant-facing entry points.

11. Permissions and visibility tests

Permissions/visibility tests обязательны.

Нужно отдельно проверить:

• platform user visibility;
• merchant user visibility;
• merchant group access;
• merchant context access;
• role permission changes;
• provider access visibility;
• hidden platform-created MASTER MID / SUB MID internals;
• SUB MID AGGREGATOR visibility;
• transaction details visibility;
• timeline visibility;
• audit logs visibility;
• export visibility.

Особенно важно проверить, что merchant user не видит real provider details, если у него нет соответствующего provider access / entity visibility.

12. Secret leakage tests

Secret leakage tests обязательны.

Нужно проверить, что secret values не появляются:

• in API responses;
• in Back Office UI after save;
• in audit logs;
• in exports;
• in transaction details;
• in transaction timeline;
• in provider raw data visible to unauthorized users;
• in system logs;
• in error responses;
• in webhook payloads.

Secret values можно только создать/заменить, но нельзя повторно прочитать.

13. Release blockers

Release должен быть заблокирован, если падает любой required test layer:

• unit tests;
• E2E tests;
• hosted form dynamic fields tests;
• contract tests;
• provider adapter tests;
• performance/load test;
• resilience test;
• permissions/visibility tests;
• secret leakage tests.

Manual migration validation fail также блокирует migration execution, но не обязательно блокирует весь MVP release, если migration еще не используется.

Если migration входит в конкретный release step, failed migration validation blocks that migration step.

14. MVP UAT / Product Acceptance

MVP принимает Product Owner.

Дополнительные approvers для MVP acceptance не требуются.

Support / ops / merchant manager могут участвовать в review/demo, но final product acceptance делает PO.

Отдельный standalone checklist для первого merchant перед live traffic в MVP не нужен.

Acceptance должна быть основана на обязательных UAT/demo сценариях и required test results.

14.1 Required UAT/demo scenarios

Перед MVP acceptance нужно показать и проверить end-to-end demo сценарий:

Create merchant -> create brand -> create API key -> create payment method ->
configure routing -> create deposit -> hosted form -> provider callback ->
merchant webhook -> Back Office transaction details/timeline.

Required product acceptance scenarios:

• successful deposit happy path;
• failed deposit scenario;
• fallback routing scenario;
• velocity rejection scenario;
• manual transaction correction scenario;
• webhook retry scenario;
• manual webhook resend scenario;
• provider duplicate callback handling;
• provider ignored callback handling;
• platform/merchant permission visibility scenario;
• secret leakage manual check;
• load test result review.

14.2 Product acceptance blockers

MVP cannot be accepted if:

• successful deposit demo fails;
• failed deposit scenario fails;
• fallback routing scenario fails;
• velocity rejection scenario fails;
• manual correction scenario fails;
• webhook retry/resend scenario fails;
• duplicate/ignored provider callback scenario fails;
• platform/merchant visibility scenario fails;
• any secret value is visible where it must not be visible;
• required load test is not completed;
• load test result does not meet agreed MVP target;
• required automated/manual test layer has unresolved blocker.

Load test is mandatory for MVP acceptance.

Functional readiness without load test is not enough.

15. Definition of Done for feature

Feature считается готовой, если:

• use case documented;
• domain model updated, если feature добавляет/меняет entity;
• API contract updated, если feature меняет public/internal API;
• permissions documented, если feature доступна через Back Office;
• audit/timeline behavior described, если feature меняет state;
• unit tests added for domain logic;
• integration/E2E tests added where needed;
• visibility/secret rules covered where relevant;
• acceptance criteria passed;
• no required test failures.

16. Definition of Done for MVP release

MVP release считается готовым, если:

• first merchant configuration created;
• at least one payment method ready for live traffic;
• public Merchant API documentation ready;
• public merchant documentation portal ready;
• merchant documentation contains HMAC request signing examples;
• merchant documentation contains webhook signature validation examples;
• merchant documentation contains statuses, error codes and sandbox/test flow;
• successful test deposit completed;
• successful live deposit completed;
• provider callback processed;
• merchant webhook delivered;
• transaction visible in Back Office;
• transaction timeline/routing path understandable;
• monitoring/alerts configured in Prometheus;
• required UAT/demo scenarios passed;
• PO accepted MVP;
• load test completed and accepted;
• required tests pass;
• no release blockers remain.

17. Не входит в MVP

В MVP не обязательно:

• писать automated tests for temporary migration tool;
• создавать отдельный Back Office QA dashboard;
• делать UI для test strategy;
• делать permanent release checklist UI.
• делать отдельный standalone checklist для первого merchant, если UAT/demo сценарии и release tasks покрывают acceptance.

18. Acceptance Criteria

Test Strategy / Definition Of Done считается согласованной для MVP, если:

• Test strategy описана отдельным документом.
• Unit tests обязательны для routing, velocity, fees, status transitions, webhook/error mapping.
• E2E tests покрывают full deposit flow from API request to merchant webhook.
• Hosted payment form dynamic fields покрыты тестами.
• Contract tests обязательны для Merchant API and merchant webhook payload.
• Provider adapter tests используют mocked provider responses/callbacks.
• Test provider exists and supports all MVP payment methods.
• Test provider returns hosted redirect URL.
• Test provider can simulate PROCESSING, COMPLETED, FAILED, CANCELED, REJECTED.
• Test provider can simulate provider timeout and provider error response.
• Test provider lets merchant/admin intentionally choose/simulate expected test outcome.
• Test transactions are marked as test and visible in transaction list/details.
• Test transactions send merchant webhooks.
• Test transactions can participate in velocity/fees/turnover in test context.
• Migration tool требует manual validation/report, automated tests не обязательны.
• Performance/load test проверяет peak 10 tx/sec for 5 minutes.
• Load test обязателен для MVP acceptance.
• После MVP release load test выполняется periodically once per month.
• Resilience test проверяет gateway behavior during core restart/lag.
• Permissions/visibility tests обязательны.
• Secret leakage tests обязательны.
• MVP принимает Product Owner.
• Отдельный standalone checklist для первого merchant не нужен.
• End-to-end demo from merchant creation to successful deposit обязателен.
• Failed deposit scenario обязателен.
• Fallback routing scenario обязателен.
• Velocity rejection scenario обязателен.
• Manual correction scenario обязателен.
• Webhook retry/resend scenario обязателен.
• Provider duplicate/ignored callback scenarios обязательны.
• Platform/merchant permission visibility scenario обязателен.
• Manual secret leakage check обязателен.
• Any required test failure blocks release.

19. Open Questions

Product open questions отсутствуют.

Technical/QA follow-up:

1. QA/development team должна описать exact test cases.
2. Development team должна определить test framework.
3. Development team должна определить mocked provider strategy.
4. DevOps/development team должна определить load test tooling.
5. DevOps/development team должна определить resilience test environment.