---
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.
