Questions d'entretien QA manuel

Prenez-en un où vous avez défendu la décision : un crash de paiement derrière un feature flag désactivé — grave mais zéro utilisateur touché, donc il a attendu un sprint. Ou un souci cosmétique de logo livré en correctif d'urgence avant une démo client.

Sortez des adjectifs pour aller sur l'impact : qui le rencontre, à quelle fréquence, y a-t-il un contournement. Souvent ils chiffrent l'effort de correction pendant que vous chiffrez le dommage utilisateur — les deux peuvent avoir raison. Si ça persiste, le product owner tranche.

Reproduisez-le à nouveau sur un état propre et comptez le taux, comparez votre environnement au leur — build, données, flags — puis apportez une preuve : un enregistrement, l'ID de requête, la ligne de log. Dix minutes à votre bureau battent une semaine de commentaires.

Le product owner ou le groupe de triage — pas le testeur ni le développeur seul. Le travail de la QA est de rendre le risque visible et consigné ; le travail du métier est de décider de le porter. Gardez la décision et la date dans le ticket.

Le taux honnête — « 3 tentatives sur 10 » — plus tout ce qui variait entre les tentatives : timing, données, état du compte. N'écrivez jamais « ça arrive parfois » ; comptez-le. Un bug intermittent étiqueté comme toujours-reproductible brûle votre crédibilité au retest.

Presque toujours la reproductibilité : une étape manquante, un état de départ non énoncé, des données qui n'existent que dans votre session, ou une différence d'environnement que personne n'a mentionnée. Le correctif est d'écrire les étapes depuis un état propre et de nommer le compte, le build et les flags.

Alors dites-le et changez de tactique : capturez l'ID de requête de production, tirez les logs de cet horodatage, et comparez la config et les données de production à la staging. Un bug qui a besoin de données de production est en soi un constat de parité d'environnement.

Quand des tentatives répétées sur état propre, une comparaison d'environnement et une session de binôme reviennent toutes vides — alors c'est documenté avec tout ce qui a été essayé et parqué comme non-reproductible, pas fermé comme invalide. S'il revient, l'historique attend.

Sévérité basse — rien n'est cassé fonctionnellement. Probablement priorité haute — chaque prospect la voit et ça fait paraître la marque négligée. C'est la paire divergente classique, et le dire montre que vous comprenez les deux cadrans.

Oui — quand le contournement ne couvre pas le dommage. Une corruption de données avec un chemin de réparation manuel reste Critique : la perte a déjà eu lieu. Les problèmes de sécurité aussi — « se déconnecter et se reconnecter » ne dé-fuit pas un token.

Lire les stories et attaquer les manques : cas limites indéfinis, états d'erreur manquants, formulations intestables comme « rapide » ou « convivial ». Chaque ambiguïté que vous faites clarifier avant le code est un bug qui n'est jamais écrit.

Exactement ça — déplacer l'effort de test plus tôt : revues d'exigences, apport en conception, cas de test avant le code, vérifications en CI. La logique est le coût : plus un défaut est attrapé tôt, moins cher il est à corriger.

Toutes — compressées dans chaque sprint. L'analyse des exigences se fait en refinement, la planification en sprint planning, la conception et l'exécution dans le sprint, la clôture à la review. Les étapes ne sont pas mortes ; elles ont rétréci de mois à jours.

Entrée : build déployé, smoke qui passe, données prêtes — apte à démarrer. Sortie : cas planifiés exécutés, aucun défaut critique ou haut ouvert — autorisé à s'arrêter. Les deux doivent être des faits vérifiables, pas des opinions.

Pas attendre les builds : relire les critères d'acceptation des stories, poser les questions de cas limites, planifier les données et environnements de test, étendre la couverture de régression pour ce qui arrive. Le travail de test commence avant le premier commit.

Dans les domaines réglementés — médical, automobile, aviation — il est vivant et souvent imposé, parce qu'il produit la traçabilité que les auditeurs veulent. Ailleurs son idée centrale a survécu dans l'Agile : concevoir les tests à partir des exigences, avant le code.

100 % des cas planifiés exécutés, 95 %+ qui passent ; zéro défaut critique ou haut ouvert ; suite de régression verte sur le build de release ; performance dans le seuil convenu ; problèmes connus documentés et validés par le product owner.

Testez ce qui est testable et consignez le reste : quels critères ont échoué, ce qui ne peut pas être vérifié à cause de ça, quel risque ça laisse. Le métier peut échanger la qualité contre le temps — mais sciemment, par écrit, pas par accident.

Ayez-en un prêt : un état d'erreur indéfini, une règle qui en contredisait une autre, un « que se passe-t-il à zéro article » que personne n'avait décidé. L'examinateur vérifie que le shift-left est quelque chose que vous avez fait, pas un diagramme que vous avez vu.

Étendre le travail de qualité en production : monitoring, alerting, releases canary, feature flags, tests avec du vrai trafic. Le shift-left prévient ; le shift-right détecte vite et limite le rayon d'impact. Les équipes matures font les deux.

Vérification — vous vérifiez que les produits du travail sont cohérents et complets sans rien exécuter. Mais une question de revue pointue comme « est-ce ce que le client a réellement demandé ? » frôle la validation. Dire les deux montre de l'étendue.

Oui — le produit sert bien les utilisateurs mais a dérivé de la spec documentée. Ça veut généralement dire que la spec est périmée. Ça a quand même besoin d'être corrigé : la prochaine personne à faire confiance à ce document hérite de l'écart.

Une revue de cause racine de défaut qui change le processus — comme ajouter des vérifications de contrat d'API après un incident de changement cassant. Aussi : standards de revue d'exigences, règles de definition-of-done, standards de code. Tout est prévention, rien n'est exécuter le produit.

L'habitude, et les rôles se brouillent vraiment : un bon testeur fait les deux — trouve le défaut (QC) et pousse le changement de processus qui arrête ses frères (QA). Connaître la différence compte plus que policer l'intitulé du poste.

Oui — du test statique par définition : examiner le produit du travail pour des défauts sans l'exécuter. Elle attrape les manques de logique, la gestion d'erreur manquante et le code peu clair que les tests dynamiques ne feraient surgir que plus tard, si tant est.

Gardez-en un vrai prêt : un état vide indéfini, deux stories qui se contredisent, un mot immesurable comme « rapidement ». La question derrière la question est de savoir si vous assistez réellement aux revues avec votre casquette de testeur.

Le smoke — il tourne à chaque build, a un périmètre stable, et sa valeur est la vitesse du verdict. Un smoke automatisé en CI veut dire qu'un build cassé rebondit en minutes sans qu'un humain y touche. Le périmètre du sanity change à chaque correctif, donc il reste flexible plus longtemps.

L'app charge, le login marche, la recherche de produits renvoie des résultats, l'ajout au panier, le chemin nominal du checkout jusqu'à la confirmation de commande, et le prestataire de paiement répond en sandbox. Dix à vingt vérifications, sous quinze minutes — vivant ou pas vivant.

Retest du correctif, puis régression cadrée par le risque : le module où il vit, tout ce qui partage son code, et le chemin de revenu de bout en bout. La régression complète ne se fera pas dans la nuit — dites ce que vous avez lancé et ce que vous n'avez pas, par écrit.

Depuis le diff et la carte des dépendances : qu'est-ce qui partage du code, des données ou de l'état avec le changement ? Plus l'historique du produit — les modules qui ont cassé avant, recassent. Le rayon d'impact d'abord, l'historique de bugs ensuite, les chemins de revenu toujours.

Le produit avec l'ingénierie — mais en pratique personne, jusqu'à ce que la QA demande. « Quelle vitesse est acceptable ? Combien d'utilisateurs concurrents ? Quel standard d'accessibilité ? » Si ces chiffres n'existent pas, les demander est en soi du travail de testeur senior.

L'accessibilité — elle n'a pas d'utilisateur en colère dans la pièce jusqu'à ce que ce soit une lettre juridique. En deuxième : la performance sous des volumes de données réalistes ; une staging avec 100 lignes ne prédit jamais une production avec 10 millions.

Ayez-en un prêt : vérifier qu'un enregistrement « supprimé » était supprimé en douceur avec un flag plutôt que retiré, attraper un toast de succès d'UI par-dessus un appel d'API échoué, ou utiliser le schéma pour construire une entrée de cas limite que l'interface seule ne suggérerait pas.

Via le contrat c'est boîte noire — vous envoyez des requêtes et affirmez des réponses sans lire le code. Ça devient boîte grise dès que vous utilisez une connaissance interne : le schéma, la file derrière l'endpoint, le cache que vous savez placé devant.

Du signal qui arrive encore : taux de crash pas encore plat, un flux critique à couverture mince (disons, peu d'utilisateurs ont essayé les paiements), ou un correctif frais qui a besoin de re-exposition. Vous terminez une beta quand les nouvelles sessions cessent de vous apprendre des choses.

Instrumentez d'abord : reporting de crash, analytique sur les flux qui vous importent, un bouton de signalement in-app qui attache automatiquement appareil, OS et logs. « Écrivez-nous si quelque chose casse » ne collecte rien — l'app doit porter la preuve elle-même.

Réduisez la demande : scénarios pré-construits pour leurs cinq workflows principaux, données prêtes, une heure réservée avec quelqu'un à leurs côtés. S'ils ne peuvent toujours pas, escaladez le risque par écrit — un UAT sauté est le métier acceptant une adéquation non validée.

Le propriétaire métier du processus — pas la QA, pas le chef de projet. Ça veut dire : nous confirmons que ça soutient notre vrai travail, problèmes connus reconnus. C'est une acceptation de l'adéquation et du risque restant, pas une affirmation de zéro défaut.

C'est la même idée à deux niveaux de zoom : le partitionnement dit OÙ tester (une valeur par classe), les limites disent QUELLES valeurs exactes (les bords entre classes, où vivent les bugs off-by-one). Utilisez-les ensemble.

Code valide actif ; code expiré ; code pas-encore-actif ; code épuisé ; chaîne mal formée ; entrée vide ; code valide pour un autre produit. Chacun se comporte différemment, donc chacun est sa propre partition — un test par classe.

Le pas est 0,01, donc : 0,00, 0,01, 0,02 et 99,98, 99,99, 100,00. Plus l'attaque de précision : 0,015 — arrondit-il, tronque-t-il ou rejette-t-il ? Les champs décimaux cachent une seconde limite dans le nombre de décimales.

Lisez la formulation de l'exigence : « 18 à 60 » veut généralement dire inclusif, « moins de 100 » veut dire que 100 est exclu. Si la spec ne dit pas, c'est un vrai bug d'exigence — demandez, ne supposez pas, et faites écrire la réponse.

Seize — 2 à la puissance du nombre de conditions. Cette croissance est le sujet de la question suivante : à cinq ou six conditions vous fusionnez les lignes qui partagent un résultat, ou passez au pairwise pour garder la table testable.

Fusionnez les lignes où une condition décide le résultat quel que soit le reste (mettez un tiret pour « peu importe »), abandonnez les combinaisons impossibles, et si c'est encore énorme, couvrez des paires de conditions au lieu de toutes les combinaisons.

Demandé → e-mail envoyé → lien cliqué → nouveau mot de passe défini → terminé ; avec des expirations depuis « e-mail envoyé » et « lien cliqué », et « lien déjà utilisé » comme ré-entrée refusée. Les tests qui rapportent : réutiliser un lien utilisé, et cliquer après expiration.

Apportez-en une : éditer un formulaire soumis en cliquant sur retour, annuler une commande déjà expédiée, double-cliquer sur payer et débiter deux fois. Le double-envoi est le classique — même événement, déclenché deux fois, dans un état qui ne devrait l'accepter qu'une fois.

Quand des combinaisons précises portent un risque connu — prestataire de paiement × devise dans un produit de paiement a besoin de chaque paire qui déplace de l'argent, explicitement. Le pairwise est pour un étalement de config large, pas pour les combinaisons sur lesquelles votre métier saigne.

Depuis l'analytique et l'historique de bugs : les navigateurs et appareils que les utilisateurs exécutent vraiment, les locales qui ont cassé avant, les rôles aux chemins de code différents. Le pairwise sur des facteurs que personne n'utilise est une couverture efficace de rien.

Fichier de zéro octet ; fichier énorme juste au-dessus de la limite ; mauvaise extension avec type renommé (exe en jpg) ; nom de fichier avec espaces, unicode ou caractères de chemin ; et double-soumission du même téléversement. Chacune correspond à un vrai incident de production quelque part.

L'error guessing est une astuce de ciblage — des entrées précises visant des défaillances probables. L'exploratoire est toute une approche : chartes, time-boxes, apprendre en avançant. Vous utiliserez l'error guessing DANS une session exploratoire constamment.

Connexion valide (la vérification de smoke dont chaque build a besoin), mauvais mot de passe avec la bonne erreur, et verrouillage après N échecs. Ils sont stables, objectifs et tournent constamment — la définition de bons candidats à l'automatisation.

Quand les messages d'erreur révèlent si un compte existe — « mauvais mot de passe » vs « aucun utilisateur » dit à un attaquant quels e-mails sont enregistrés. Testez un vrai et un faux compte : l'erreur doit être identique, en texte ET en temps de réponse.

Quand l'exécutant a le contexte et que la fonctionnalité se prête à l'exploratoire : scénarios plus notes de session suffisent. Les cas détaillés gagnent leur coût là où la précision compte — conformité, passations, exécution externalisée, ou flux à mise en place de données exacte.

Identifiants valides ; mauvais mot de passe ; e-mail inconnu ; champs vides ; vérification de sensibilité à la casse ; compte verrouillé ; se-souvenir-de-moi persiste ; la redirection après connexion revient à la page d'où vous veniez. Huit cas, une ligne de scénario.

Stratégie : le lead QA ou le responsable ingénierie — c'est une politique permanente. Plan : celui qui dirige le test pour cette release, relu par l'équipe. Si les deux ne sont possédés par personne, vous le découvrez pendant la revue d'incident.

Chaque plan réinvente les décisions : quelles couches automatiser, quels environnements existent, ce que « critique » veut dire. Les plans se contredisent, l'outillage se fragmente, et les nouveaux arrivants apprennent un process différent par projet. La stratégie est ce qui rend les plans courts.

Des exemples avec leurs raisons : le prestataire de carte déprécié (arrêt au T4), les flux de chargeback (possédés par les ops finance), la charge au-delà du pic actuel (le plan de l'équipe plateforme). Chaque exclusion nomme le pourquoi et qui la porte à la place.

Aussi court que l'honnêteté le permet — une ou deux pages pour la plupart des fonctionnalités. Dès qu'un plan est assez long pour que personne ne le lise, il cesse de prévenir les disputes, ce qui était tout son travail. Périmètre, critères, risques ; coupez le boilerplate.

Faites-en un sous-produit, pas un document : liez les cas de test aux stories dans l'outil que vous utilisez déjà (Jira, TestRail le font nativement), et vérifiez-la aux moments où vous relisez déjà — refinement et préparation à la release.

D'une matrice lourde, rarement. De l'idée, toujours : chaque critère d'acceptation a besoin d'au moins une vérification, et le lien story-vers-test dans votre outillage EST la matrice légère. Les équipes Agile réglementées gardent la version formelle parce que les auditeurs demandent.

Lisez les bugs échappés avant de toucher au moindre process : quel module, quel type, trouvables comment ? Puis corrigez le trou précis — un environnement manquant, une intégration non testée, une régression mince dans un domaine. La fuite est un symptôme ; la liste de bugs est le diagnostic.

Bugs-par-testeur. Elle transforme les collègues en concurrents, récompense le fractionnement superficiel de bugs, et punit le testeur qui passe une journée à prouver un critique difficile. Tout ce qui gamifie les individus corrompt les données et l'équipe à la fois.

90 ÷ (90 + 10) × 100 = 90 %. Au-dessus de 90 est généralement solide. Le piège de la relance est « 90 est-il bon ? » — la réponse honnête : par rapport à nos trois dernières releases, pas à une table sectorielle.

Parce que les unités ne sont pas standard : les équipes comptent la taille différemment, loggent les défauts à des seuils différents, et construisent des logiciels à risque différent. Dans une base de code la comparaison trouve les points chauds ; entre équipes c'est de la numérologie.

Des notes de session : le charter, ce que vous avez couvert, les bugs remontés, les questions restantes. Postez-les là où l'équipe vit — le ticket, le canal. L'exploration sans trace ressemble à « j'ai joué avec l'app » ; avec des notes c'est de la couverture auditable.

La mission de la session, une ligne : « explorer les flux de remboursement avec des cartes expirées ». Assez serré pour focaliser, assez lâche pour suivre les surprises. C'est la différence entre explorer et errer.

« Explorer le téléversement de fichiers avec des fichiers hostiles — surdimensionnés, zéro octet, mauvaises extensions, types renommés, noms unicode — et observer les réponses serveur et le stockage. » Une ligne, une direction d'attaque, de la place pour poursuivre ce qui saigne.

Cinq minutes avec le lead : ce qui a été couvert, ce qui a été trouvé, ce qui inquiète encore, ce que le prochain charter devrait être. Ça convertit la session d'un testeur en connaissance de l'équipe — et repriorise souvent le lendemain.

Oui — comme prise de pouls rapide : un tâtonnement façon smoke sur un build frais, une vérification de deux minutes après un changement de config. Il devient un problème seulement quand c'est toute la stratégie, parce qu'il ne peut pas montrer la couverture ni être répété.

En-tête : charter, build, time-box. Corps : trace en puces des domaines touchés, bugs remontés avec ids, questions pour l'équipe, et ce que j'explorerais ensuite. Une demi-page, écrite pendant la session, lisible par n'importe qui.

Depuis des preuves, pas des impressions : à quelle fréquence le domaine change (historique git), son historique de bugs, sa complexité, à quel point le code est neuf. Un module qui a changé douze fois ce trimestre avec cinq bugs passés se note lui-même.

Le product owner — parce qu'un classement de risque est en réalité une déclaration de priorité métier déguisée en QA. La QA propose avec des preuves ; le métier possède le risque accepté. Rendez-le visible en planning, pas enterré dans un plan de test.

Alors ils choisissent plus de périmètre, donc ils choisissent la monnaie : plus de temps, plus de personnes, ou accepter des risques précis par leur nom. « Tout tester en deux jours » n'est pas une option au menu — mon travail est de garder le menu honnête.

Attaquez la cause en rétro avec des chiffres : fenêtres de test compressées sur quatre releases d'affilée. Poussez pour la QA en refinement (stories plus petites, testables), l'automatisation de la régression répétée, et des critères de release convenus avant la date, pas à la date.

Cette contradiction est un constat — la fonctionnalité ne peut pas satisfaire les deux. Mettez les deux versions côte à côte dans le ticket, obtenez une décision par écrit, et testez contre elle. Vous venez de faire du travail d'exigences ; c'est le métier face à l'ambiguïté.

Non — je testerais contre mes hypothèses documentées en les signalant fort. Bloquer punit les utilisateurs pour un manque de process. Mais une ambiguïté à haut risque — argent, suppression de données — reçoit une réponse avant que je valide quoi que ce soit.

Ayez-en une prête — la forme est « qu'arrive-t-il quand X échoue en plein Y » : paiement en plein renouvellement, réseau en plein téléversement, expiration en plein checkout. Les meilleures questions de refinement portent sur les chemins d'échec que personne n'a écrits dans la story.

Estimer ensemble, mais l'effort de test doit être visible dans le chiffre — un changement de code à deux points avec une lourde mise en place de données n'est pas une story à deux points. L'effort de test silencieux est comment les sprints « mystérieusement » débordent.

Des éléments concrets et vérifiables : critères d'acceptation vérifiés, régression autour du changement verte, vérifications automatisées ajoutées ou mises à jour en CI, aucun défaut critique/haut ouvert, notes exploratoires pour les stories risquées. Rien de vague comme « correctement testé ».

Le product owner esquisse l'intention, mais les critères les plus forts sortent des trois amigos — la QA ajoute les cas limites, le dev ajoute la faisabilité. Les critères écrits seul par n'importe qui tendent à ne couvrir que le chemin nominal.

Les formes récurrentes : qu'arrive-t-il à zéro/vide, à la limite, à la nouvelle tentative, à l'expiration en plein flux, quand deux utilisateurs le font en même temps. Apportez un attrapage concret à vous — façon « remboursement après expédition partielle » — et la réponse atterrit.

Le refinement est toute l'équipe traitant le backlog ; les trois-amigos, c'est trois perspectives allant en profondeur sur UNE story, souvent juste avant qu'elle soit prise. Le refinement décide quoi et quand ; les amigos clouent exactement ce que « correct » veut dire.

Alors le sprint livre silencieusement du travail non testé, et la facture arrive en bugs de production. Montrez la fuite : quels défauts échappés venaient des stories du dernier jour. Quand le schéma a un coût attaché, « c'est comme ça » cesse d'être une réponse.

La date story-atteint-la-QA vs fin du sprint, par story, sur plusieurs sprints ; et les défauts échappés retracés aux stories du dernier jour. Deux chiffres simples — l'empilement et son prix — font mieux valoir la cause que tout argument.

Même sprint si la fonctionnalité est stable et que la DoD l'exige ; sprint suivant si l'UI se stabilise encore. Ce qui compte, c'est que la dette d'automatisation soit suivie, pas silencieuse — un élément de backlog nommé, pas un espoir.

Ayez une vraie réponse : la mise en page visuelle d'un PDF, une vérification de migration ponctuelle, un flux derrière un sandbox tiers instable où la suite crierait au loup chaque semaine. Savoir ce qu'il ne faut PAS automatiser est le signe de mid-à-senior.

PUT remplace toute la ressource — envoyez tout, les omissions peuvent être effacées. PATCH ne met à jour que les champs que vous envoyez. Le test qui coince les équipes : PUT avec un champ manquant — met-il le champ à null ou rejette-t-il la requête ?

404 — la ressource est partie. Un second 200 peut être une conception idempotente acceptable si documentée, mais un 500 est toujours un bug : l'API n'a pas su gérer son propre passé réussi. Cette sonde exacte trouve de vrais défauts constamment.

Une requête de connexion stocke le token dans une variable d'environnement via un script post-réponse ; chaque autre requête le référence dans l'en-tête Authorization. Nouvel environnement = même collection tournant contre dev, staging, ou sandbox sans changement.

Des assertions de corps : les champs requis existent, les valeurs correspondent à ce que vous avez créé, les types sont bons. Plus un plafond de temps de réponse et — pour les créations — un GET de suivi affirmant la persistance. Un 200 avec un mauvais corps reste un test qui échoue.

Validation de schéma dans les tests — affirmer la structure et les types, pas juste les valeurs — pour qu'un champ renommé ou re-typé échoue immédiatement. Les équipes avec des consommateurs qu'elles ne contrôlent pas ajoutent des tests de contrat (façon Pact) figeant ce sur quoi les consommateurs s'appuient.

Insecure Direct Object Reference : accéder aux ressources d'autrui en devinant les IDs. Testez avec deux comptes — créez en A, récupérez en B en attendant 403/404, parcourez les IDs séquentiels, et répétez sur chaque type de ressource, pas juste l'évident.

Interrogez la table : la ligne est là ? Si oui, la couche API filtre ou échoue — vérifiez sa requête et ses permissions. Si non, l'UI montre du cache ou un état local. Un SELECT coupe la stack en deux et vous dit quelle équipe possède le bug.

Les examinateurs demandent ça pour vérifier que le SQL est réel pour vous, pas un certificat de cours. Ayez-en une prête avec un but : « joint les users aux orders pour trouver les comptes avec une commande payée mais sans ligne d'e-mail de confirmation — des données pour un bug de livraison d'e-mail. »

WHERE filtre les lignes avant le regroupement, donc COUNT n'existe pas encore quand il s'exécute. HAVING filtre les groupes après l'agrégation. « WHERE COUNT(*) > 1 » est une erreur de syntaxe — et l'erreur exacte que cette question pêche.

LEFT JOIN users vers orders, puis WHERE orders.id IS NULL. INNER JOIN ne peut pas le faire — il abandonne les lignes non correspondantes, qui sont précisément celles que vous cherchez.

Demandez ce que valent ces 2 % : sur un produit grand public ça peut être des milliers d'utilisateurs, et iOS sur-indexe souvent sur les paiements. Minimum : les flux critiques à chaque release. Abandonner un navigateur est une décision métier à proposer, jamais un saut silencieux.

Cibles tactiles trop petites, interactions au survol sans équivalent tactile, claviers virtuels couvrant les champs, débordement de viewport, et bugs d'état interrompu — rotation, mise en arrière-plan en plein flux, réseaux capricieux. Modèle de saisie différent, classe de bug différente.

Tout ce qui demande du jugement : si le texte alternatif est significatif, si l'ORDRE du focus a du sens, si l'expérience au lecteur d'écran est utilisable, si les erreurs sont annoncées. Un scan vérifie que les attributs existent ; il ne peut pas dire si la page marche les yeux fermés.

Indicateurs de focus invisibles ou manquants ; champs sans labels programmatiques (un placeholder n'est pas un label) ; et le sens par la couleur seule — le point de statut rouge/vert qu'un utilisateur daltonien lit comme identique. Les trois se trouvent en cinq minutes.

Interrogez la ligne et affirmez qu'elle existe avec les valeurs exactes saisies, que les timestamps/défauts sont définis, et qu'aucune table liée n'a été changée à tort. Un « succès » d'UI n'est pas une preuve de persistance.

LEFT JOIN A vers B et filtrez WHERE B.key IS NULL — les lignes de gauche non appariées. C'est le schéma standard « trouver les orphelins » en test de données.

Oui — WHERE réduit d'abord les lignes (disons, les commandes de cette année), puis GROUP BY les agrège, puis HAVING filtre les groupes (clients avec >5 de ces commandes). Ils s'exécutent dans cet ordre.

Non — la réponse peut être construite en mémoire et jamais persistée, ou un trigger/mapping peut changer la valeur à l'écriture. La requête BD est la preuve indépendante, un chemin de code différent de la réponse.

Une contrainte de base de données manquante plus une course — deux requêtes insèrent le « même » enregistrement avant que l'une ou l'autre committe. La requête trouve le symptôme ; le correctif est une contrainte unique, et tester le chemin concurrent.

Dans la suite de test contre une BD amorcée, ou comme requêtes de monitoring en production. Dans les deux cas ce sont des assertions permanentes peu chères qui attrapent la dérive de données que l'UI cache.