108 lines
6.3 KiB
Markdown
108 lines
6.3 KiB
Markdown
---
|
|
title: Test Scenario Catalog
|
|
tags: [testing, scenarios, qa, e2e]
|
|
created: 2026-06-06
|
|
---
|
|
|
|
# Test Scenario Catalog
|
|
|
|
This catalog lists the designed test flows. Each scenario should eventually
|
|
have an automation owner, a smoke command, and a UAT checklist.
|
|
|
|
## Priority Model
|
|
|
|
| Priority | Meaning |
|
|
|---|---|
|
|
| P0 | Blocks release or payment trust if failing. |
|
|
| P1 | Core user experience or operational reliability. |
|
|
| P2 | Important edge case with workaround. |
|
|
| P3 | Nice-to-have or exploratory. |
|
|
|
|
## Scenario Matrix
|
|
|
|
| ID | Scenario | Priority | Current status | Procedure |
|
|
|---|---|---:|---|---|
|
|
| ESCROW-E2E-001 | Buyer creates request, multiple sellers bid, buyer accepts, pays, seller delivers, buyer confirms | P0 | Live tested on dev, two rounds | [[Escrow Marketplace E2E Procedure]] |
|
|
| PAY-SCAN-001 | BSC Testnet tUSDT direct-balance scanner confirms funded wallet transfer | P0 | Live tested on dev | [[Scanner BSC Testnet Payment Procedure]] |
|
|
| PAY-SCAN-002 | Scanner/backend/frontend token registry consistency for chain 97 | P0 | Smoke covered | [[Smoke and Regression Procedure]] |
|
|
| PAY-SCAN-003 | Wrong token contract does not confirm payment | P0 | Designed, needs automated negative test | [[Scanner BSC Testnet Payment Procedure#Negative scenarios]] |
|
|
| PAY-SCAN-004 | Underpayment does not confirm payment | P0 | Designed, needs automated negative test | [[Scanner BSC Testnet Payment Procedure#Negative scenarios]] |
|
|
| PAY-SCAN-005 | Wrong destination does not confirm payment | P0 | Designed, needs automated negative test | [[Scanner BSC Testnet Payment Procedure#Negative scenarios]] |
|
|
| DELIVERY-001 | Seller delivery advances request to `delivery` | P0 | Live tested on dev | [[Escrow Marketplace E2E Procedure]] |
|
|
| DELIVERY-002 | Buyer delivery confirmation advances request to `delivered` | P0 | Live tested after `2.8.117` id fix | [[Escrow Marketplace E2E Procedure]] |
|
|
| DELIVERY-003 | Non-buyer cannot confirm delivery | P0 | Designed, should be regression test | [[Testing Expansion Backlog]] |
|
|
| RELEASE-001 | Physical product enters grace period before release | P0 | Product policy not implemented | [[Testing Expansion Backlog]] |
|
|
| RELEASE-002 | Gift card/digital product releases immediately after proof/confirmation | P0 | Product policy not implemented | [[Testing Expansion Backlog]] |
|
|
| DISPUTE-001 | Buyer opens dispute before release | P0 | Backend incomplete / needs route alignment | [[Testing Expansion Backlog]] |
|
|
| DISPUTE-002 | Admin resolves dispute for seller and release path is unblocked | P0 | Not complete | [[Testing Expansion Backlog]] |
|
|
| DISPUTE-003 | Admin resolves dispute for buyer and refund path is unblocked | P0 | Not complete | [[Testing Expansion Backlog]] |
|
|
| CI-001 | Code push builds and deploys backend/frontend/scanner via Woodpecker | P0 | Live used | [[Smoke and Regression Procedure]] |
|
|
| UI-CHAIN-001 | Checkout shows BSC Testnet, tUSDT contract, and testnet explorer links | P1 | Implemented in frontend `2.8.118` | [[Scanner BSC Testnet Payment Procedure]] |
|
|
| NOTIF-E2E-001 | Every E2E state-changing step issues expected notifications | P0 | Designed, needs automation | [[Notification Assertion Procedure]] |
|
|
| PERF-CONC-001 | Ramp simultaneous full escrow E2E workers: 1, 2, 4, 8, 16, 32+ | P0 | Designed, needs automation and baseline report | [[Concurrency and Performance Profile]] |
|
|
| AUTH-001 | Admin-created generated users can log in and execute role actions | P0 | Live used | [[Escrow Marketplace E2E Procedure]] |
|
|
| CLEANUP-001 | Test users/requests can be identified and excluded from reports | P2 | Designed | [[Test Environment and Data]] |
|
|
|
|
## Core Escrow Scenario
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
A["Create buyer and sellers"] --> B["Buyer creates purchase request"]
|
|
B --> C["Sellers submit bids"]
|
|
C --> D["Buyer accepts one bid"]
|
|
D --> E["Buyer pays tUSDT on BSC Testnet"]
|
|
E --> F["Scanner confirms payment"]
|
|
F --> G["Seller delivers"]
|
|
G --> H["Buyer confirms delivery"]
|
|
H --> I["Assert notifications after every step"]
|
|
I --> J["Policy boundary: grace, release, or dispute"]
|
|
```
|
|
|
|
## Concurrency Scenario Family
|
|
|
|
The concurrency profile runs the same full escrow worker in parallel and doubles
|
|
the worker count until a stop condition is reached:
|
|
|
|
```text
|
|
1 -> 2 -> 4 -> 8 -> 16 -> 32 -> 64 ...
|
|
```
|
|
|
|
Each worker executes one isolated buyer/seller/payment/delivery flow with unique
|
|
test users, request ids, destination addresses, and payment ids. Notification
|
|
assertions remain mandatory inside each worker. See
|
|
[[Concurrency and Performance Profile]].
|
|
|
|
## Payment Negative Scenario Families
|
|
|
|
| Family | What to mutate | Expected result |
|
|
|---|---|---|
|
|
| Wrong token | Pay old BSC Testnet USDT or USDC instead of canonical tUSDT | Scanner does not mark intended payment paid. |
|
|
| Wrong chain | Pay on chain `56` or another EVM chain | Scanner watch for chain `97` remains pending. |
|
|
| Wrong amount | Send less than expected base-unit amount | Direct-balance delta below threshold, no paid transition. |
|
|
| Wrong destination | Send correct token/amount to another address | Intended destination delta unchanged, no paid transition. |
|
|
| Duplicate payment | Send twice to same destination after paid | First payment confirms; second must not double-credit escrow ledger. |
|
|
| Late payment | Pay after expiration/cancellation | Payment should not auto-credit an inactive intent without explicit recovery. |
|
|
|
|
## Release Policy Scenario Families
|
|
|
|
These are not implemented yet, but they define the test shape we need before
|
|
shipping fund release automation.
|
|
|
|
| Product type | Expected policy |
|
|
|---|---|
|
|
| Physical product | Delivery proof starts a grace period. Funds release only after buyer confirmation, no dispute, or grace expiry. |
|
|
| Gift card | Delivery should require immediate proof and release funds immediately or near-immediately after buyer acceptance, depending on final policy. |
|
|
| Digital file/license | Same as gift card unless manual review is required. |
|
|
| Service | May need milestone acceptance and dispute window. |
|
|
|
|
## Scenario Completion Criteria
|
|
|
|
A scenario is complete when all are true:
|
|
|
|
1. It has a written procedure.
|
|
2. It has deterministic test data setup.
|
|
3. It captures expected API statuses and DB/business states.
|
|
4. It has at least one automated test or smoke script where practical.
|
|
5. It has a documented live-dev verification result.
|
|
6. It names residual risk or product gaps.
|