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

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:

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:

It has a written procedure.
It has deterministic test data setup.
It captures expected API statuses and DB/business states.
It has at least one automated test or smoke script where practical.
It has a documented live-dev verification result.
It names residual risk or product gaps.

6.3 KiB Raw Blame History