nick/nick-doc
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: add notification and concurrency test procedures

Browse Source
This commit is contained in:
Siavash Sameni
2026-06-06 10:57:44 +04:00
parent 9267961909
commit bee91dd01f
6 changed files with 552 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
11 - Testing/Test Scenario Catalog.md
View File

@@ -38,6 +38,8 @@ have an automation owner, a smoke command, and a UAT checklist.
| 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]] |
@@ -52,9 +54,24 @@ flowchart LR
E --> F["Scanner confirms payment"]
F --> G["Seller delivers"]
G --> H["Buyer confirms delivery"]
H --> I["Policy boundary: grace, release, or dispute"]
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 |
@@ -88,4 +105,3 @@ A scenario is complete when all are true:
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.