talas-group/10_QUALITE_TESTS/QA_Fonctionnels/SCENARIOS_TESTS.md

Scénarios de tests fonctionnels — Veza

Tests par module : critères d'acceptation, cas limites, flows à valider. Chaque scénario = un test qui doit passer avant mise en production. Dernière mise à jour : avril 2026.

---

Organisation

Priorité des tests

Priorité	Signification	Quand exécuter
P0	Bloquant production — si échec, pas de deploy	Chaque PR
P1	Critique — à corriger dans les 24h si regression	Chaque release
P2	Important — à corriger avant la prochaine release	Hebdomadaire
P3	Nice-to-have — à corriger quand possible	Mensuel

Format d'un scénario

[ID] Titre
Priorité: PX | Type: unit/integ/e2e
Préconditions: ...
Étapes:
  1. ...
  2. ...
Résultat attendu: ...
Cas limites: ...

---

Module 1 — Authentification

AUTH-001 — Inscription email + password

P0 | e2e

• Préconditions : aucun compte existant
• Étapes :
  1. POST /auth/register { email, password, username }
  2. Vérifier email reçu (lien de vérification)
  3. Cliquer le lien
  4. Vérifier que le compte est actif
• Résultat : compte créé, JWT retourné, email vérifié
• Cas limites :
  • Email déjà pris → erreur 409
  • Username déjà pris → erreur 409
  • Password < 12 car → erreur 400
  • Password pwned (HIBP) → warning (V1.5)
  • Email invalide → erreur 400
  • Lien de vérification expiré (> 24h) → erreur + lien "renvoyer"

AUTH-002 — Login + JWT

P0 | integ

• Étapes :
  1. POST /auth/login { email, password }
  2. Vérifier cookies HTTP-only (access + refresh)
  3. GET /auth/me avec cookie
• Résultat : user info retournée
• Cas limites :
  • Mauvais password → 401 (pas de distinction "email inconnu")
  • Compte verrouillé (5 échecs) → 429 + message "réessaie dans 15 min"
  • Compte non vérifié → 403 "vérifie ton email"

AUTH-003 — Refresh token

P0 | integ

• Étapes :
  1. Login → obtenir access + refresh
  2. Attendre expiration access (ou simuler)
  3. POST /auth/refresh avec refresh cookie
• Résultat : nouveau access token, refresh token tourné
• Cas limites :
  • Refresh expiré → 401
  • Refresh révoqué (post-logout) → 401
  • Double utilisation du même refresh → 401 + révoquer TOUTES les sessions (detection replay)

AUTH-004 — 2FA TOTP

P1 | integ

• Étapes :
  1. POST /auth/2fa/setup → QR code
  2. POST /auth/2fa/verify { code } → activation
  3. Logout + login → reçoit { requires_2fa: true }
  4. POST /auth/login/2fa { temp_token, code }
• Résultat : login complet
• Cas limites :
  • Code TOTP incorrect → 401
  • Code TOTP expiré (> 30s window) → 401
  • Backup code utilisé → OK, code invalidé
  • Tous backup codes utilisés → message "configure un nouveau 2FA"

AUTH-005 — OAuth Discord

P1 | e2e

• Étapes :
  1. GET /auth/oauth/discord → redirect Discord
  2. User autorise → callback avec code
  3. Backend échange code → crée/lie le compte
• Résultat : JWT retourné, compte actif
• Cas limites :
  • State mismatch → 400
  • Discord down → erreur propre "service temporairement indisponible"
  • Email Discord déjà lié à un compte local → propose de lier

AUTH-006 — Rate limiting auth

P0 | integ

• Étapes :
  1. Envoyer 6 POST /auth/login (mauvais password)
• Résultat : 429 au 6e avec Retry-After header
• Vérifier : IP différente ne bloque pas

---

Module 2 — Tracks (morceaux)

TRACK-001 — Upload + processing

P0 | integ

• Étapes :
  1. POST /tracks (metadata)
  2. PUT upload URL (binaire WAV)
  3. POST /tracks/:id/publish
  4. Attendre event "transcoding.completed"
  5. GET /tracks/:id
• Résultat : track publié, HLS manifest disponible, waveform générée
• Cas limites :
  • Fichier > 500 MB → 413
  • Format non supporté (.exe, .pdf) → 415
  • ClamAV détecte virus → status "removed" + notif admin
  • Upload interrompu → status "draft" conservé, reprise possible

TRACK-002 — Lecture streaming

P0 | e2e

• Étapes :
  1. GET /tracks/:id → HLS manifest URL
  2. Charger dans player HLS.js
  3. Vérifier lecture audio
• Résultat : audio jouable, adaptatif (qualité s'adapte au réseau)
• Cas limites :
  • Track privé sans auth → 401
  • Track supprimé → 404
  • Connexion lente → fallback bitrate bas

TRACK-003 — Permissions

P1 | integ

• Vérifier :
  • User A ne peut pas DELETE /tracks/:id de user B → 403
  • User A ne peut pas PUT /tracks/:id de user B → 403
  • Track privé de user A non visible par user B → 404
  • Track avec lien secret accessible avec le bon token

---

Module 3 — Samples & Presets

SAMPLE-001 — Upload pack complet

P0 | integ

• Même flow que TRACK-001 mais avec .zip
• Vérifications supplémentaires :
  • Extraction liste fichiers post-upload
  • Preview MP3 généré automatiquement
  • Tags indexés pour recherche

SAMPLE-002 — Téléchargement

P1 | integ

• Étapes :
  1. GET /samples/packs/:id/download
  2. Vérifier URL signée MinIO
  3. Vérifier incrément downloads_count
• Cas limites :
  • Pack supprimé → 404
  • Rate limit (50 downloads/h) → 429

SAMPLE-003 — Remix (arbre)

P1 | integ

• Étapes :
  1. Créer pack parent
  2. POST /samples/packs/:id/remix (nouveau pack)
  3. GET /samples/packs/:parent_id/remixes
• Résultat : arbre parent → enfant visible
• Cas limites :
  • Parent avec remix_allowed=false → 403
  • Licence incompatible → erreur

SAMPLE-004 — Recherche et filtres

P1 | integ

• Tester chaque combinaison de filtres :
  • type + genre + bpm_min/max + key + tags + licence
  • sort=recent|popular|downloads
  • Pagination (page + limit)
• Résultat : résultats cohérents, pas de crash

---

Module 4 — Troc

TROC-001 — Flow complet création → closing

P0 | e2e

• Étapes :
  1. User A : POST /trades/listings (créer annonce)
  2. User B : POST /trades/listings/:id/interest
  3. Vérifier : DM créé entre A et B
  4. User A : POST /trades/listings/:id/conclude { concluded_with: B }
  5. User B : POST /trades/listings/:id/recognition { badges: ['reliable'] }
• Résultat : annonce "conclue", badges sur profil B
• Cas limites :
  • Auto-intérêt (creator == interested) → 403
  • Conclude avec user non-intéressé → 400
  • Double reconnaissance → 409

TROC-002 — Détection anti-argent

P1 | unit

• POST /trades/listings avec "je cherche 100€" → 400
• POST avec "échange contre euros" → 400
• POST avec "je propose un mix" → OK

TROC-003 — Limites

P1 | integ

• 6e annonce active → 400 "max 5 annonces actives"
• 3e annonce dans la journée → 400 "max 2/jour"

---

Module 5 — Shop

SHOP-001 — Parcours achat complet

P0 | e2e

• Étapes :
  1. GET /shop/products/talas-one → fiche produit
  2. POST /shop/cart/items { variant_id, qty: 1 }
  3. POST /shop/checkout/validate { addresses }
  4. POST /shop/orders → commande créée
  5. POST /payments/create → redirect Mollie
  6. Webhook Mollie payment.paid
  7. Vérifier : order status = "paid", email confirmé, facture générée
• Cas limites :
  • Stock = 0 → erreur au checkout
  • Réservation expirée (15 min) → stock libéré
  • Webhook Mollie en double → idempotent (pas de double charge)
  • Paiement échoué → order annulé, stock libéré

SHOP-002 — Réservation stock concurrente

P0 | integ

• Étapes :
  1. Stock = 1 unité
  2. User A et user B tentent checkout simultanément
• Résultat : un seul réussit, l'autre reçoit "rupture de stock"
• Vérifier : pas de survente (stock négatif impossible)

SHOP-003 — Calcul prix

P0 | unit

• Vérifier :
  • Prix base + options = total correct
  • TVA = 0% (franchise en base) avec mention légale
  • Frais de port ajoutés au total
  • Fees Mollie pas facturés au client (absorbés)

SHOP-004 — Remboursement

P1 | integ

• Étapes :
  1. Commande payée
  2. Admin : POST /admin/payments/:id/refund
  3. Webhook Mollie refund.paid
  4. Vérifier : order status "refunded", facture d'avoir, stock ré-incrémenté

---

Module 6 — Cloud Perso

CLOUD-001 — CRUD fichiers

P1 | integ

• Upload, download, rename, delete, restore
• Vérifier quotas mis à jour après chaque action

CLOUD-002 — Isolation

P0 | integ

• User A ne peut pas :
  • Lister les fichiers de user B
  • Télécharger un fichier de user B
  • Supprimer un fichier de user B
• Même via manipulation d'URL / brute-force UUID

CLOUD-003 — Partage

P1 | integ

• Créer lien partagé → accessible sans auth
• Lien avec password → exige le bon password
• Lien expiré → 410 Gone
• Max downloads atteint → 403

---

Module 7 — Formation

LEARN-001 — Inscription et progression

P1 | integ

• Enroll → start lesson → complete lesson → progress updated
• Vérifier progress_percent recalculé correctement

LEARN-002 — Video streaming

P1 | e2e

• Leçon vidéo → HLS manifest → lecture dans player
• Position sauvegardée → reprise au bon endroit

LEARN-003 — Permissions contenu

P1 | integ

• Leçon non-preview sans enrollment → 403
• Leçon preview → accessible sans enrollment
• Seul le content_creator peut modifier son cours

---

Module 8 — Chat et notifications

CHAT-001 — DM entre users

P1 | integ

• Créer conversation, envoyer message, recevoir (WebSocket)

CHAT-002 — Groupes

P1 | integ

• Poster dans un groupe, voir les messages des autres
• Permissions : modérateur peut supprimer

NOTIF-001 — Notifications

P2 | integ

• Vérifier que chaque action génère la bonne notif :
  • Like sur track → notif au créateur
  • Intérêt troc → notif à l'annonceur
  • Commande payée → email client
  • SAV message → notif user

---

Module 9 — Performance

PERF-001 — Temps de réponse API

P1 | load test

• GET /tracks (feed) : p95 < 200ms sous 100 req/s
• GET /tracks/:id : p95 < 100ms
• POST /auth/login : p95 < 500ms

PERF-002 — Streaming concurrence

P1 | load test

• 100 connexions WebSocket simultanées → pas de drop

PERF-003 — Upload concurrence

P2 | load test

• 20 uploads simultanés → pas de timeout, pas de corruption

---

Outils de test

Couche	Outil	Langage
Unit backend	go test	Go
Unit Rust	cargo test	Rust
Unit frontend	Vitest	TypeScript
Integration API	go test + httptest	Go
E2E	Playwright	TypeScript
Load	k6	JavaScript
Sécurité	OWASP ZAP, Nuclei	-
Visual	Storybook + Chromatic	TypeScript

---

Exécution en CI

# Chaque PR
- go test ./...
- cargo test
- npm run test
- govulncheck ./...
- cargo audit
- npm audit --audit-level=high
- gitleaks detect

# Nightly
- playwright test (e2e)
- k6 run perf-tests.js (load)
- trivy image scan

# Pre-release
- OWASP checklist manuelle
- Pentest ciblé si code critique modifié

---

Voir aussi

• Tableaux_Validation/CHECKLIST_VALIDATION_V0 — checklist pré-vente (86 items)
• Audit_Sécurité/PLAN_AUDIT_SECURITE — tests sécurité spécifiques
• Tests_Hardware/PROTOCOLES_TESTS_HARDWARE — tests matériel
• ARCHITECTURE_VEZA — composants à tester
• 05_EXPERIENCE_UTILISATEUR/Flux_Utilisateurs/PARCOURS_UTILISATEURS_VEZA — flows à valider en e2e