QA avant la mise en ligne : les vérifications qui comptent

1. Définir les parcours à protéger

Listez trois à cinq parcours dont dépend l’utilité du site. Pour un portfolio, ce peut être découvrir une réalisation, comprendre une prestation et envoyer une demande. Pour une application, ajoutez l’inscription, la connexion et l’action principale du produit.

Décrivez un résultat observable pour chacun : après l’envoi du formulaire, la demande apparaît dans la destination prévue et la personne voit une confirmation. Cette précision évite de valider seulement l’apparence du bouton. La documentation Playwright recommande justement de tester les comportements visibles par l’utilisateur.

Références : Playwright : bonnes pratiques de test

2. Essayer aussi les situations qui échouent

Réalisez chaque parcours avec des données de test, dans un environnement prévu pour cela. Essayez ensuite un champ obligatoire vide, une adresse e-mail invalide et une réponse serveur en échec. Vérifiez que le message explique le problème et que les informations déjà saisies restent disponibles lorsque c’est possible.

Testez également un double clic sur l’envoi, un retour à la page précédente et un rafraîchissement. Une demande ne devrait pas être dupliquée sans raison. Une action encore en cours doit rester identifiable. Pour un paiement, utilisez exclusivement le mode de test du prestataire.

3. Vérifier le mobile et la navigation au clavier

Sur un écran étroit, contrôlez le menu, les boutons proches du bord et les formulaires lorsque le clavier virtuel s’ouvre. Essayez au moins un autre navigateur et, si possible, un téléphone réel. Notez les environnements effectivement testés pour rendre les limites de cette vérification explicites.

Parcourez ensuite la page au clavier : l’élément actif doit être visible, les commandes accessibles et l’ordre cohérent. Contrôlez aussi les libellés des champs et l’agrandissement du texte. Le W3C propose ces premiers contrôles d’accessibilité tout en précisant qu’ils ne constituent pas une évaluation complète.

Références : W3C WAI : premiers contrôles d’accessibilité

4. Mesurer et conserver des tests répétables

Observez le chargement, la réactivité et les déplacements du contenu. Les Core Web Vitals associent ces dimensions aux indicateurs LCP, INP et CLS. Un diagnostic en laboratoire aide avant publication ; les mesures auprès des utilisateurs complètent ensuite l’analyse.

Gardez une courte liste de tests à relancer après chaque changement important. Automatisez progressivement les parcours les plus stables, avec des données maîtrisées. Après avoir modifié le menu, rejouez aussi l’accès au contact : une amélioration locale peut toucher un parcours voisin.

Références : web.dev : comprendre les Web Vitals

5. Transformer chaque problème en action

Un signalement exploitable donne la page, les étapes, le résultat attendu, le résultat observé et le navigateur concerné. Ajoutez une capture sans données personnelles. Par exemple : « Sur mobile, ouvrir le menu puis Contact laisse le menu au-dessus du formulaire. »

Classez les problèmes selon leur impact. Un parcours essentiel bloqué mérite une correction avant publication. Une différence d’espacement peut attendre si elle ne gêne pas l’usage. Après correction, rejouez le scénario et conservez la preuve du résultat.