Test logiciel : UI, API, manuel et automatisé

Basé sur le guide « La qualité prime tout : guide complet du test logiciel » (Roman Surkov). Tout ce qui est marqué [hors livre] provient d'autres sources (liste en fin de document) ou de pratiques courantes. Présente-le comme un complément, et non comme une position de l'auteur.

Quand l'utiliser

« Teste une fonctionnalité / un écran / une application / une API », « crée une liste de vérification / des cas de test », « rédige un bug ».
Vérification des spécifications, maquettes Figma ou Swagger avant le développement (shift-left).
Choix de ce qu'il faut automatiser et comment ; scénario de charge ; rapport d'état de version.
Pour les jeux vidéo, utilise la compétence qa-game-testing, et reprends la base générale (conception de tests, artefacts).

Étape 0. Définir le mode de travail

Demande	Ce qu'il faut fournir
Spécifications / maquettes existantes, pas encore de code	Revue des exigences (étape 1) + liste de vérification rédigée à l'avance
« Teste » sans détails	Décomposition selon « BLUGUID avec PC » (étape 2) → liste de vérification → cas de test pour les parties complexes
Site / application en ligne disponible	Exécution des vérifications, rapports de bugs, TRR final
API / Swagger / cURL	BINMEN + POISED (étape 6), collection de requêtes
« Qu'automatiser ? », tests flaky, Playwright	Plan selon la pyramide et règles des tests automatisés (étape 8)
Vérification de la sécurité de l'API	Matrice OWASP API Top 10 (étape 6)
Fonctionnalité LLM (chatbot, génération)	Couches de vérification et ensemble de référence (étape 9)
Test exploratoire d'une nouvelle fonctionnalité	Chartes de sessions SBTM + SFDIPOT (étape 2)

Commence par les vérifications positives (happy path), puis les négatives. Dans les vérifications positives, on peut fusionner ; dans les négatives, un seul paramètre invalide par vérification.

Étape 1. Test des exigences (shift-left)

Une erreur coûte plus cher selon la règle 1–10–100 : une correction dans les spécifications coûte 1, dans le code 3 à 8 fois plus cher, trouvée par le QA 20 à 80 fois plus, en production plus de 100 fois. Donc commence par le document.

Critères d'une bonne exigence (pour chaque violation, ajoute un commentaire dans le document) : complétude (cas limites et erreurs décrits), non-contradiction (le texte ne contredit pas la maquette), non-ambiguïté, exactitude, testabilité (« comment vais-je vérifier cela ? »), atomicité (une seule idée).

Mots à éviter — « rapide », « pratique », « intuitif », « flexible », « adéquat », « si nécessaire ». Reformule en mesurable : « recherche rapide » → « résultats ≤ 1,5 s avec 1000 requêtes simultanées ».

S'il n'y a pas de spécifications, le résultat attendu provient de : maquettes et prototypes → concurrents → lois et régulateurs (RGPD, PSD2) → bonnes pratiques et bon sens (validation d'email, rate-limit, masques de téléphone) → discussion avec le développeur ou l'analyste.

Comment « griller » les exigences : questions sur les limites (longueur maximale, caractères interdits, rupture de réseau, deux utilisateurs cliquent en même temps) ; schéma fonctionnel ou mind map du parcours (une flèche pointant vers le vide est un scénario non décrit) ; cas de test directement pendant la lecture (si tu ne peux pas rédiger un cas, c'est qu'il y a un bug dans les spécifications).

Oracles FEW HICCUPPS [hors livre, M. Bolton et J. Bach] — comment prouver que le comportement est problématique s'il n'y a pas de spécifications ou si elles sont incomplètes. Le produit doit être cohérent avec : Familiar problems (ne reproduit pas des bugs connus), Explainability (le comportement peut être expliqué), World (ne contredit pas la réalité), History (versions précédentes), Image (image de l'entreprise), Comparable products (produits similaires), Claims (déclarations : spécifications, publicité, aide), User desires (désirs raisonnables de l'utilisateur), Product (lui-même : une seule action doit avoir le même comportement partout), Purpose (finalité), Statutes and standards (lois et normes). Dans le rapport de bug, mentionne l'oracle : « contredit la version précédente », « contredit l'aide » — il sera plus facile de contester un « ce n'est pas un bug ».

Missing Feature : si une fonctionnalité n'existe pas et n'est pas dans les spécifications, ce n'est pas un Bug, mais une Amélioration / Demande de fonctionnalité. Les litiges peuvent être résolus par la matrice de fonctionnalité : Web — existe, iOS — existe, Android — n'existe pas.

Étape 2. Décomposition de la tâche « Teste »

Les tests fonctionnels répondent à la question « QUOI » fait le produit, les tests non fonctionnels au « COMMENT ». Parcours les vecteurs non fonctionnels à l'aide du moyen mnémotechnique « BLUGUID avec PC » :

B — sécurité (XSS, injections SQL, droits d'accès)
L — localisation
U — utilisabilité (usability)
G — interface graphique (GUI)
U — installation (uniquement ce qui s'installe : desktop, mobile, consoles)
I — accessibilité (a11y)
D — performances (côté client et serveur)
P — configuration et compatibilité

Ajoute les tours exploratoires de Whittaker pour la découverte libre : guide (fonctionnalités principales), arrière-cour (paramètres rares), coursier (un seul objet à travers tous les statuts), argent (panier et paiement), travailleur de nuit (tâches d'arrière-plan), éboueur (« Annuler », « Réinitialiser »), obstiné (100 répétitions d'une même action), mauvais quartier (modules historiquement problématiques), musée (code ancien, longtemps non modifié).

De quoi est composé le produit — SFDIPOT [hors livre, HTSM de J. Bach] : Structure (de quoi il est fait : fichiers, modules, builds), Function (ce qu'il fait), Data (ce qu'il saisit, stocke, affiche ; vide, énorme, corrompu), Interfaces (UI, API, import/export, intégrations), Platform (système d'exploitation, navigateur, matériel, services externes), Operations (comment il est réellement utilisé : scénarios fréquents, utilisateur inexpérimenté et malveillant), Time (timeouts, parallélisme, ordre des événements, fuseaux horaires, fonctionnement prolongé). Parcours les sept mots — tu obtiendras une carte de couverture que BLUGUID ne fournit pas.

Tests exploratoires par sessions (SBTM) [hors livre, J. et J. Bach]. Session de 60 à 90 minutes sans distraction, avec une charte : « Explorer à l'aide de <outils, techniques, données> pour découvrir ». À la fin — feuille de session : ce qui a été couvert, bugs trouvés, questions, risques, proportion du temps passé sur les tests / la rédaction de bugs / la configuration de l'environnement, et une brève analyse avec le responsable. Ainsi, les tests libres deviennent traçables : on voit ce qui a été vérifié et ce qui reste à faire.

Étape 3. Techniques de conception de tests

Ordre : d'abord le squelette avec EP + BVA + tables de décision, puis renforcement par l'Error Guessing.

Classes d'équivalence (EP) : une valeur de chaque classe valide et invalide.
Valeurs limites — uniquement 3BVA : à chaque limite, prends min-1, min, min+1 (et de même pour max). 2BVA laisse passer une erreur de frappe de l'opérateur X == 10 au lieu de X >= 10 : les points 9 et 10 passent, mais 11 échoue. Exemple : accès 18–100 ans → -1, 0, 1, 16, 17, 18, 99, 100, 101. Pour l'argent, le pas est l'unité minimale (0,01 €).
Combinatoire : 1-wise (≈50% des bugs, express), pairwise — standard (70–90%), 3-wise pour la fintech (≈95%), balayage complet uniquement pour les systèmes critiques. Ne construis jamais une matrice pairwise dans ta tête : génère-la avec un outil (PICT, s'il est installé, sinon pip install allpairspy --break-system-packages) et vérifie avec un script que toutes les paires sont couvertes. Où l'appliquer : filtres de catalogue, calculateurs, paiement × livraison, export (format × encodage × séparateur). Pour les tests inter-navigateurs, n'utilise pas pairwise (voir étape 5).
Tables de décision : lorsqu'il y a beaucoup de « si / et / ou / sauf » dans les spécifications, 2 à 5 conditions binaires. Supprime les combinaisons impossibles et fusionne les règles ayant le même résultat en un seul cas. Endroits typiques : réductions et codes promo, matrice des rôles, champs de formulaire dépendants (personne morale → INN et KPP obligatoires), statuts de commande.
États et transitions : tout ce qui a un cycle de vie et des timeouts. Vérifie les transitions interdites, l'expiration du timeout (une réservation non payée revient à « Libre »), le caractère unique des jetons (réinitialisation du mot de passe avec un ancien lien), la rupture à chaque étape.
Error Guessing — catalogue de pièges :
- saisie sale : uniquement des espaces, espaces aux bords de l'email, U+200B, émojis, guillemets, caractères idéographiques, 10 000 caractères depuis le presse-papier ;
- répétitions et courses : triple clic sur « Payer », « Retour » après une transaction, le dernier produit est acheté par deux personnes ;
- interruptions : rupture réseau à 99 %, fermeture de l'onglet pendant l'acquisition ;
- dates et nombres : 29.02 en année non bissextile, date de naissance dans le futur, 00.00.0000, quantité −1, 0, 999 999 ;
- environnement : session expirée après 3 heures d'inactivité, .exe avec l'extension .jpg, fichier de 500 Mo.

Étape 4. Artefacts

Liste de vérification (ID, vérification, statut) — par défaut. Cas de test — pour une logique complexe, l'intégration et la transmission à l'automatisation.

Champs d'un cas de test : ID, titre, priorité, précondition (toujours renseignée), étapes, données de test, résultat attendu ; après exécution — résultat réel et statut (Passed / Failed / Blocked / Skipped).

Règles : dans les étapes, seulement les actions du testeur, les réactions du système vont dans le résultat attendu ; les étapes sont atomiques (« saisir l'email », « saisir le mot de passe », « cliquer sur Connexion » — trois étapes) ; un seul cas = une seule vérification ; les cas ne dépendent pas les uns des autres (la préparation va dans la précondition ou se fait via l'API) ; le niveau de détail est raisonnable, sans « déplacer la souris » ; la priorité High concerne l'argent et l'authentification, Low les éléments cosmétiques, le reste (≈80%) est Medium.

Suite de tests (Test Suite) — dossier par module avec des sous-dossiers par fonctionnalité ; les vérifications communes du module se trouvent à la racine de la suite. Exécution de test (Test Run) — exécution d'un ensemble sur une version et un environnement spécifiques avec des statuts. Plan de test (sur demande) : scope (in / out), stratégie et environnement, critères d'entrée, de suspension et de sortie, ressources et délais, risques avec plan B.

Rapport de bug

Titre :       [Où] Ce qui se produit, sous quelle condition
              exemple : [Fenêtre du code promo] erreur 500 lors de la saisie d'un coupon expiré
Environnement : Prod/Stage, navigateur et version, système d'exploitation ; pour mobile, modèle et version exacte de l'OS ; URL
Précondition :  rôle de l'utilisateur, page, données préparées
Étapes :       1. … 2. … (uniquement les actions, chaîne minimale)
Attendu :      concret, avec référence aux spécifications ou à la maquette
Réel :         ce qui s'est produit
Gravité :      Blocker / Critical / Major (existe une solution de contournement) / Minor / Trivial — évaluation technique, déterminée par le QA
Priorité :     High / Medium / Low — urgence métier (décidée par le PO/PM)
Reproductibilité : Toujours (10/10) ou Intermittent (ex. 1/10)
Solution de contournement :  chemin alternatif, s'il existe
Pièces jointes : capture d'écran pour les éléments statiques, vidéo pour les éléments dynamiques, journaux console ou HAR pour le backend

Règles : 1 bug = 1 ticket ; avant de créer, cherche un doublon ; crée-le immédiatement ; ton neutre ; n'invente pas de correctif dans le ticket ; rédige de manière à pouvoir vérifier le correctif dans un mois à partir de la description. La gravité et la priorité sont indépendantes (une faute de frappe dans le logo : Trivial / Immediate).

Rapport de test (TRR)

Minimum de blabla, maximum de chiffres et une recommandation explicite Go / No-Go :

RAPPORT DE TEST DE LA VERSION vX.Y
N cas planifiés : Passed a (a%) · Failed b (b%) · Blocked c (c%)
Défauts : BUG-… — résumé (priorité) [lien] …
Bloqué : quel bloc et en raison de quels bugs
Recommandation QA : version NON recommandée / recommandée sous conditions …

Étape 5. UI : formulaires, GUI, utilisabilité, accessibilité, compatibilité, localisation

Formulaires et champs de saisie

Texte : valeur valide ; champ obligatoire vide ; exactement max ; max+1 ; caractères spéciaux ' " < > / ; : @ # $ % ^ & * ( ) _ + ; émojis (crash sur utf8mb4) ; uniquement des espaces, espaces en tête, en queue et internes (trim attendu) ; mélange de cyrillique, latin, idéogrammes et RTL ; F5 conserve la saisie (sauf mot de passe et captcha) ; double clic sur « Envoyer » n'envoie pas deux requêtes ; U+200B.
Mot de passe : masquage ; effacé lors du rechargement et d'une erreur ; vérification de la faiblesse et de la correspondance avec l'identifiant ou l'email ; collage depuis le presse-papier et le gestionnaire de mots de passe ; l'« œil » bascule entre password ↔ text.
Sélection et téléchargement : valeurs par défaut raisonnables (consentement non coché par défaut — RGPD) ; le clic sur le libellé active la case à cocher ; « tout sélectionner / tout désélectionner » ; groupe de boutons radio obligatoire ; extensions interdites (.exe, .php), fichier de 0 octet et de 100 Mo+, barre de progression.
Validation UX : vérification inline au blur, la saisie n'est pas effacée en cas d'erreur, le champ est mis en évidence et la raison est indiquée à côté avec un CTA ; le format est suggéré à l'avance (« JJ.MM.AAAA ») ; un seul champ par valeur ; écran de succès avec le numéro, le statut et l'étape suivante ; « Retour » dans un formulaire multi-étapes conserve les données ou est explicitement interdit.
Plus BLUGUID : Tab / Shift+Tab / Entrée, Safari et mobile, traductions des erreurs, XSS, SQL, CSRF, rate limit.

GUI : vérification de la maquette (Figma + DevTools)

Commence par les Common Components — la correction d'un composant commun répare des dizaines d'écrans. Dimensions — extension Pixel Measurement (largeur « inférieure à la maquette » avec DevTools ouvert — c'est de l'adaptatif, pas un bug). Polices et couleurs — Elements → Computed (font-size, background-color → HEX). Espacements — Option/Alt dans Figma contre Box Model. Animations — Command Palette → Show Animations, ralentir à 10–25 %. Superposition — PerfectPixel avec opacité à 50 %. Une différence de 1 px n'est pas un bug (arrondi subpixel), si la mise en page n'a pas dérivé.

Utilisabilité (usability)

Vérifie selon les 10 heuristiques de Nielsen : statut du système, langage de l'utilisateur, contrôle et Undo, standards de la plateforme (HIG / Material), prévention des erreurs, reconnaissance plutôt que mémorisation, accélérateurs, minimalisme, erreurs claires, aide. Pour un public adulte : police d'au moins 12 pt, contraste, grandes cibles. Ne casse pas les modèles natifs : double tap, gestes système au bord de l'écran. L'annulation avec « Undo » pendant 5 secondes est meilleure qu'un dialogue « Êtes-vous sûr ? ».

Accessibilité (WCAG, POUR)

Exécution rapide : Lighthouse (uniquement Accessibility) → axe DevTools → IBM Equal Access → ANDI (ordre Tab et noms des éléments) → contraste (AA ≥ 4.5:1, AAA ≥ 7:1). Texte sur image ou dégradé à revérifier avec la pipette DevTools : les scanners prennent la couleur de la balise adjacente. Manuellement : tout le travail sans souris, focus visible et non masqué, alt sur les images informatives, rien ne clignote plus de 3 fois par seconde, respect de prefers-reduced-motion, lecteur d'écran (NVDA / VoiceOver). Simulations — Web Disability Simulator.

Compatibilité

Construis la matrice à partir des données : tes propres analyses → statistiques régionales → StatCounter (et signale le risque de couverture insuffisante). Regarde le chiffre d'affaires par plateforme, pas seulement le trafic. Supprime la queue < 0,5 %. Regroupe par moteur : Chrome et Edge sous Windows — un seul Chromium ; tous les navigateurs sous iOS — WebKit, mais Safari sous iOS doit être testé séparément (ses propres bugs de mise en page). Distribue la régression proportionnellement aux parts (200 cas × part du groupe), et non par pairwise « navigateur × cas » (cela donnerait 1400 exécutions). Le manque d'appareils peut être comblé par l'émulation Chrome DevTools, BrowserStack, et des tests sur une matrice réduite de vrais appareils.

Localisation

Texte : pas de troncature (le russe +30% par rapport à l'anglais), pas d'encodage détruit, variables non traduites (Your {name} → Votre {name}), accents en tête, devises et séparateurs locaux, RTL + mixage LTR/RTL, format de date et d'heure, fuseau horaire universel (ISO 8601).
Zones complexe : multiligne (adresse, commentaire), combinaisons (prénom + nom + téléphone + code postal + ville + pays), conversion de devise neutre.
Actualité : translations Pale или не выгружены, месяца в родительном падеже (janvier → janvier 2024, mais « du 1er janvier au 31 décembre »).

Étape 6. API

Que tester dans une API : structure de la requête/réponse, code HTTP, corps et en-têtes, schéma et types, valeurs limites et valeurs manquantes, authentification/autorisation, sécurité, performances, état, compatibilité des versions, documentation.

Analyse BINMEN pour la méthode et le code

Code	BINMEN (ce qu'il signifie)
2xx	B — Bien (réussi)
3xx	I — Informé (redirection)
4xx	N — Non (faute du client)
5xx	M — Moi (faute du serveur)
La méthode repose sur le EN de MEN :
GET / DELETE / HEAD / OPTIONS	E — Idempotent, sans effet de bord (sûr)
PUT / PATCH	N — Non idempotent (ou sans garantie) — PUT est idempotent, PATCH ne l'est pas toujours.

POISED — vérification de la réponse : Protocole / schéma (JSON, XML, HTTP/2), Order (ordre des clés, champs obligatoires), Interface (types, valeurs limites, format), Structure (tableaux, objets, null), Erreurs (message, code, stack trace en dev, pas en prod), Data (valeurs réelles).

Vérifications de sécurité (matrice de paramètres)

Vérifie chaque paramètre pour : IDOR (modification de l'identifiant d'un objet d'un autre utilisateur) — GET /api/orders/123 → 124 ; injection (SQL, NoSQL, LDAP, XXE) ; mass assignment (envoi de champs supplémentaires "isAdmin": true) ; traversée de répertoire (../../../etc/passwd) ; débordement d'entier ; paramètre inconnu ; paramètre vide.

OWASP API Top 10 [hors livre]

API1:2023 — Broken Object Level Authorization : l'utilisateur accède aux données d'un autre via l'ID. Vérifie les IDOR dans tous les endpoints avec des identifiants.
API2:2023 — Broken Authentication : mots de passe faibles, absence de rate-limit sur la connexion, jetons non invalidés après déconnexion.
API3:2023 — Broken Object Property Level Authorization : l'utilisateur lit/modifie des champs interdits. Vérifie l'injection de champs supplémentaires dans PATCH/PUT, la révélation d'informations sensibles dans la réponse.
API4:2023 — Unrestricted Resource Consumption : absence de pagination, pas de limit sur la taille d'entrée, pas de rate-limit. Vérifie ?limit=100000 et ?page=100000.
API5:2023 — Broken Function Level Authorization : les accès administrateur sont disponibles sans vérification du rôle. Vérifie GET /api/admin/users en tant qu'utilisateur normal.
API6:2023 — Unrestricted Access to Sensitive Business Flows : l'API ne limite pas les actions en termes de volume/nombre, ce qui permet les bots (réservation de tous les billets). Vérifie les limitations de taux d'achat et de réservation.
API7:2023 — Server Side Request Forgery : l'API télécharge une URL fournie par l'utilisateur et l'exécute sans validation. Vérifie les URL de schémas file://, localhost.
API8:2023 — Security Misconfiguration : CORS permissif (Access-Control-Allow-Origin: *), messages d'erreur verbeux (stack trace), méthodes HTTP non sécurisées (PUT, DELETE sur GET).
API9:2023 — Improper Inventory Management : documentation obsolète (swagger.json accessible), versions d'API non prises en charge et non désactivées (/v1/ → /v2/).
API10:2023 — Unsafe Consumption of APIs : l'API fait confiance à des API tierces sans valider leur réponse. Vérifie l'injection via des API tierces (JSONP, callback).

Vérifications des contrats [hors livre]

Compatibilité directe : les nouveaux schémas sont un sur-ensemble des anciens : on peut ajouter des champs, on ne peut pas en supprimer, ni changer le type ni le nom.
Rétrocompatibilité : pour supprimer un champ, il faut : 1) le marquer comme « obsolète » dans la documentation ; 2) publier une version ; 3) après le temps de grâce, le supprimer (enfrew ou breaking change).
Outils : OpenAPI diff, Optic, assertible. En les intégrant dans le CI, on obtient Contract Testing.
Les types de contrats : obligations du fournisseur (schéma), comportement côté client (Consumer-Driven Contract ; exemple : Pact).

Contrat manquant : soulève une question, mais ne crée pas de bug.

Tests d'API manuels

Collection dans l'outil : vérifier la présence des endpoints (toast, titre), les valeurs limites, le nombre de requêtes (1, 2, 100, max). Sécurité et performances (via k6 ou wrk). Rédiger un rapport de bug sur l'API avec la requête et la réponse réelle.

Étape 7. Tests non fonctionnels

Performances

Client : Lighthouse, WebPageTest, Chrome DevTools Performance (FPS, paint, layout, memory). Core Web Vitals : LCP (≤ 2.5 s), FID/INP (≤ 200 ms), CLS (≤ 0.1). L'image du compresseur est lourde — l'éditeur envoie l'original, le front n'a pas fait de redimensionnement. Le format de police est le woff2 (enfin), les polices ne pèsent pas plus de 150 Ko.
Serveur : k6 pour l'API (ou wrk, siege). Scénario proche du réel : connexion, navigation, action. Rampe : de 1 à 20, puis de 20 à max (ou plateau). Surveillance : temps de réponse (p95 < 500 ms, p99 < 1000 ms), erreurs (< 1%), saturation des ressources (CPU, RAM, I/O). Les réponses en cache (304) ne doivent pas solliciter le backend. Si une fonctionnalité suppose un affichage à froid (première fois) et à chaud (cache), vérifie les deux.
Tests de charge : temps de réponse ne doit pas augmenter plus que linéairement avec la montée en charge ; avec 2× de charge, p95 ne doit pas augmenter de plus de 1,5×. S'il augmente de 3× — l'architecture est sous-dimensionnée ou il y a un goulet d'étranglement.
Base de données : N+1 queries, index manquants, verrous longs (PageTimeout).

Étape 8. Automatisation

Stratégie (pyramide avec boîte de test)

Tests unitaires : fonctionnalité atomique, pas d'API et de base de données. Rapides. Sont écrits par les développeurs.
Tests de service (API / intégration) : une API, une base de données, sans UI. Stables, rapides, couvrent la logique métier.
Tests E2E UI : utilisateur → navigateur → API → base de données → réponse. Lents et flaky. Uniquement pour les parcours critiques (achat, connexion).

La pyramide n'est pas une pyramide mais une montagne inversée — en pratique, les tests d'API (boîte) sont plus nombreux que les tests unitaires. Mais l'essentiel est de réduire les E2E.

Règles des tests automatisés :

Le test flaky n'existe pas : soit c'est un bug de l'automatisation, soit de l'application. Si le bug est intermittent, il vaut mieux le tester (scénario de charge, timer).
Le test ne dépend pas d'un autre test (nettoyage obligatoire).
Les données non critiques sont aléatoires (Faker).
Les sélecteurs sont stables (data-testid ou aria-label, mais pas CSS + .class).
Un seul assert par test. Si je veux vérifier trois champs, j'écris trois tests (Assertion First).
Le test est indépendant de l'environnement : les URL, les mots de passe sont dans les variables d'environnement, pas dans le code.
Le test s'exécute en 5 secondes (sauf pour la vidéo).

Tests avec Playwright

Pourquoi Playwright : un seul langage (JS/TS), API stable, attentes automatiques, capture d'écran/vidéo en cas d'échec, test mobile (émulation), interception réseau (mock), parallélisation, trace viewer, test ID (getByTestId), composants (Storybook + Vite).

Modèle Page Object : la page est une classe/objet avec des méthodes (getters, actions) et des assertions. Les tests ne contiennent que la logique : scénario + assertion, sans sélecteurs.

Tests flaky : problèmes de synchronisation (Playwright a des attentes automatiques, mais il arrive que waitForTimeout soit utile) ; ordre : désactiver test.describe.serial ; données : test.use({ storageState: ... }) ou seed de base de données ; rareté : répéter un test 5 fois (test.flaky ou retry) et analyser la trace pour la tendance.

Bonne pratique : exécuter les tests dans le CI sur tous les navigateurs cibles. Configurer les retries (2–3). Pour les tests lents — augmenter le timeout dans playwright.config.ts. Utiliser le mode UI pour le débogage (npx playwright test --ui).

Exemple de test dans le projet :

test('doit ajouter un article au panier', async ({ page }) => {
  await page.goto('/catalogue');
  await page.getByTestId('add-to-cart').first().click();
  await expect(page.getByTestId('cart-badge')).toHaveText('1');
});

CI/CD

Le test est un fichier qui s'exécute dans le CI.
Les tests ne sont pas exécutés s'il n'y a pas de changements (GitHub Actions paths-filter).
Les tests échoués ne doivent pas bloquer le CI (sauf pour l'achat). Mais s'ils échouent en permanence — soit le test, soit l'application est cassé.
La parallélisation n'est pas effectuée localement, mais dans le CI (le nombre de workers est = 1/2 CPU).
Pour les tests inter-navigateurs — une matrice : chaque navigateur séparément, et dans le worker, les tests par navigateur.

Étape 9. Tests des fonctionnalités LLM [hors livre]

Couches de vérification

Couche 1 : Composant LLM — le modèle lui-même : format de réponse (JSON, MD, texte), qualité (sens, fait, absence de contradiction), harmonie (ton, style).
Couche 2 : Application LLM — l'application autour du modèle : saisie utilisateur, API, contexte, mémoire, actions (tool calls).
Couche 3 : Intégration et déploiement — RAG, source de données, qualité de l'API, CI/CD, monitoring.

Ensemble de référence (Evals)

Vérification du fait (Groundedness) : le modèle ne se trompe pas, utilise les faits donnés. Exemple : le texte de la réponse correspond au contexte intégré.
Pertinence (Relevancy) : la réponse correspond à la question.
Harmonie (Alignment) : la réponse n'est ni agressive, ni toxique, ni discriminatoire.
Format de la réponse : JSON valide (vérification standard ou avec jsonschema), Markdown correct.

Outils : LangSmith, DeepEval, PromptFlow. Les tests sont un ensemble de paires question-réponse, chacun avec un oracle (le LLM lui-même, appelé LLM-as-a-Judge).

Types de tests

Tests de régression : un ensemble de questions de base auxquelles on attend des réponses correctes (par exemple, « Qu'est-ce que le test logiciel ? »).
Tests de sécurité : injection de prompt (( Prompt Injection ), saturation du contexte, toxines en entrée.
Tests de robustesse : synonymes, reformulation, fautes de frappe, bruit dans la requête.
Tests de performance : temps de réponse, débit, mémoire.

Nota bene : l'ensemble de référence doit être révisé et complété après chaque mise à jour du modèle. Le comportement du LLM n'est pas déterministe (un même appel peut donner des résultats différents), il s'agit donc non pas de tests assertifs, mais de métriques et de seuils (qualité > 85 %).

Étape 10. Tests inter-systèmes et tests de migration [hors livre]

Utilise les catégories d'Anchors & Hooks (ancres et crochets) et Twisers

[truncated]

Demander à votre IA préférée

Documentation