Skip to content

06.02 Quality Expectations ​

Status: draft for discussion

1. Goal ​

This document describes how the business expects to see the MVP before launch.

It is not a test plan or a list of test cases.

2. Business-Ready MVP ​

MVP is ready for business review if:

  • platform user can create merchant;
  • platform user can create brand;
  • platform user or merchant user can create payment method inside brand;
  • routing can be configured and published;
  • merchant can create deposit;
  • customer can complete Hosted Payment Page;
  • transaction goes through routing and receives a clear result;
  • merchant receives webhook;
  • transaction can be investigated through timeline;
  • provider names are hidden from merchant users without business access;
  • secret values are not exposed after saving;
  • migrated transactions are shown as legacy and are read-only.

3. Critical Flows ​

Before MVP release, the team must check:

  • create merchant;
  • create brand;
  • create payment method;
  • configure routing;
  • create deposit;
  • Hosted Payment Page;
  • additional customer fields collection;
  • successful provider flow;
  • failed provider flow;
  • fallback routing;
  • velocity limit rejection;
  • currency conversion and fees;
  • merchant webhook delivery;
  • webhook retry/resend;
  • manual transaction correction;
  • user/role/access visibility;
  • audit logs;
  • legacy transaction migration.

4. Load Expectation ​

The system must support expected MVP traffic and be ready for short peak loads.

Exact load test plan is proposed by development and QA teams.

5. Release Blockers ​

MVP must not be released if:

  • merchant cannot create deposit;
  • customer cannot complete payment flow;
  • routing works unpredictably;
  • provider names are exposed to merchant users without business access;
  • secrets are visible after saving;
  • webhooks are not sent or cannot be investigated;
  • transaction timeline does not explain what happened;
  • roles and access allow user to see other merchant data.

6. What Development and QA Decide ​

Development and QA teams propose test strategy, automation scope, load testing approach, release checklist, rollback/recovery approach, and acceptance criteria.

Комментарии

Комментариев пока нет.