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.

Комментарии

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