Checklist de test d’un site web

Une checklist de test web permet des vérifications systématiques ; elle ne promet pas de trouver tous les défauts. Son intérêt est que l’équipe comprenne le périmètre, les résultats attendus et les risques restants. Une même liste ne peut pas convenir également à un site d’actualités, un portail bancaire et une administration interne.

Adaptez les points au produit et à la livraison avant l’exécution. Modifier un formulaire de commande demande une profondeur différente d’une correction de texte en pied de page. Les vérifications suivantes sont une base : retenez les points pertinents et ajoutez les risques propres au changement.

Préparer le contexte des tests

Consignez le build, l’environnement, les zones modifiées, les rôles, les données de test et les navigateurs pris en charge. Identifiez le parcours critique : quel résultat attire les utilisateurs et quel échec coûterait particulièrement cher ?

Chaque point exige un résultat et des preuves. Utilisez les statuts « réussi », « défaut », « bloqué », « non testé » et « non applicable », avec explication. Un test omis ne compte pas comme réussi. Préparez un environnement et des données sûrs pour les paiements, e-mails et suppressions de test.

→Ouvrir directement la page d’accueil et les pages clés par URL : le contenu attendu et les ressources nécessaires se chargent.
→Actualiser une page imbriquée : serveur et client conservent le bon chemin sans erreur inattendue.
→Naviguer en arrière et en avant : l’UI restaure un état cohérent sans répéter accidentellement une action.
→Ouvrir une adresse inexistante : une page d’erreur claire permet de continuer, et la réponse HTTP correspond à la nature de la ressource.
→Vérifier menus, liens internes et navigation vers les services externes : aucune impasse, aucun domaine erroné ni boucle de redirection.

Tenez compte des sessions neuves et existantes. Un site fraîchement ouvert et un onglet ancien peuvent recevoir des versions différentes des ressources et de l’état.

Vérifier le scénario métier principal

Suivez le parcours complet depuis son entrée jusqu’au résultat, puis vérifiez que celui-ci a réellement été enregistré. Un message de succès seul ne confirme pas un changement de données.

Pour une boutique : trouver un produit, utiliser le panier, payer et consulter la commande. Pour une base de connaissances : trouver et lire un article, consulter des contenus liés et obtenir une URL correcte à partager. Utilisez des rôles et données réalistes : un administrateur peut éviter des restrictions rencontrées par les utilisateurs ordinaires.

Vérifier les formulaires et les données

→Les valeurs vides, ordinaires et aux limites sont traitées selon le contrat ; les erreurs aident à corriger la saisie.
→Le bouton et Entrée déclenchent un envoi cohérent ; les clics répétés ne dupliquent pas l’opération.
→Après un refus serveur, les valeurs valides restent présentes et une nouvelle tentative est clairement possible.
→Textes longs, cyrillique, langues et formats de date ne corrompent pas les données.
→Téléversements et téléchargements respectent les exigences de type, taille, nom et accès.

Comparez saisie, requête, réponse et état relu ensuite. Cette chaîne aide à détecter une perte de précision ou une normalisation passée inaperçue.

Vérifier connexion, rôles et sessions

Confirmez que connexion, déconnexion, expiration de session et réauthentification respectent la politique du produit. Testez une URL protégée sans connexion et une opération avec un rôle dépourvu du droit nécessaire.

Avec des comptes préparés, vérifiez l’accès à l’objet de test d’un autre utilisateur via l’UI et l’API. Masquer un bouton ne remplace pas le contrôle serveur. Après changement de compte, l’application ne doit pas montrer les données précédentes depuis son état ou un cache mal utilisé.

Vérifier erreurs, réseau et reprise

Ralentissez le réseau, interrompez une requête, provoquez une erreur serveur prévue et renvoyez une réponse vide. Attendez un état clair, un indicateur de chargement qui s’arrête et une façon définie de continuer.

Le résultat incertain est crucial : le serveur peut avoir enregistré une commande sans que le client reçoive la réponse. Une nouvelle tentative ne doit pas en créer silencieusement une seconde. Vérifiez la cohérence serveur et la protection prévue contre les doublons. Console et Network aident au diagnostic ; évaluez le résultat d’après le comportement du produit et les données.

Vérifier présentation et accessibilité

Choisissez navigateurs et dimensions selon la matrice de prise en charge. Effectuez l’action critique dans une fenêtre étroite, avec du contenu long et un zoom accru. Les panneaux fixes et le clavier ne doivent pas masquer les actions nécessaires.

Suivez le parcours au clavier ; vérifiez focus visible, libellés, erreurs compréhensibles et noms accessibles des boutons. Utilisez un lecteur d’écran si nécessaire. Les contrôles automatiques apportent des indices supplémentaires sans établir l’accessibilité de tous les processus.

Vérifier visibilité publique et configuration de livraison

Pour un site public, vérifiez title, description, canonical, règles robots, sitemap et redirections prévues. Pour un service privé, la justesse des restrictions d’accès compte davantage. N’appliquez pas les exigences d’indexation aux espaces personnels privés.

Vérifiez la configuration de production : domaines API, liens, ressources et absence de simulations de test ou de secrets de diagnostic. Après déploiement, effectuez un court test smoke avec des données autorisées. Réservez les tests de charge et destructifs à l’environnement désigné et au périmètre convenu à l’avance.

Exemple pratique : livraison du parcours de commande

Supposons une modification du formulaire d’adresse et du calcul de livraison. Priorisez la finalisation de commande, les limites d’adresse, le changement de mode de livraison et la nouvelle tentative après expiration du délai.

1.Créez une commande de test avec une adresse ordinaire. Attendez un seul enregistrement avec la bonne adresse, le bon montant et le bon mode de livraison.
2.Saisissez une longue adresse sur téléphone et corrigez une erreur. Les messages et le bouton doivent rester accessibles avec le clavier ouvert.
3.Modifiez l’adresse avant la fin du calcul. Le dernier choix doit s’appliquer, pas une réponse retardée.
4.Répétez la confirmation après un échec simulé de réponse. Attendez un statut cohérent sans doublon.
5.Vérifiez la consultation de la commande avec un autre rôle de test. Les droits d’accès doivent être respectés.

Choisissez les autres points selon les dépendances affectées et l’historique des défauts, plutôt que pour cocher toute la liste.

Terminer l’exécution

Dans le rapport, reliez les défauts aux points de la checklist et indiquez les environnements couverts, les blocages et les zones non testées. Distinguez « aucun défaut connu détecté » de « aucun risque » : les tests ne peuvent pas démontrer la seconde affirmation.

Les erreurs fréquentes sont une profondeur identique pour toutes les livraisons, l’absence de résultats attendus et des tests bloqués marqués en vert. Une bonne checklist aide à décider de livrer à partir de preuves et de limites explicites.

Lectures complémentaires

Une fiche de livraison web fondée sur des preuves

Utilisez une tâche concrète, comme l’envoi d’un formulaire de contact fictif. Convenez des règles des champs, du comportement de succès et des navigateurs pris en charge. Les lignes suivantes définissent des observations : il s’agit d’une fiche compacte de livraison, pas d’un audit complet de sécurité ou d’accessibilité. Consignez séparément les résultats réels et attendus.

plain text

Domaine	Action	Observation attendue	Preuve à recueillir
Fonctionnement	Envoyer un formulaire valide	Un seul envoi accepté et une confirmation claire	ID de requête + UI
Validation	Envoyer sans l’adresse e-mail obligatoire	Erreur précise ; aucun succès ; requête invalide traitée selon le contrat	UI + journal des requêtes
Clavier	Effectuer la tâche avec Tab/Shift+Tab/Enter	Focus visible ; contrôles accessibles ; aucun piège clavier	Vidéo
Libellés	Inspecter les noms accessibles des champs	Nom décrivant l’objectif ; erreur associée au bon champ	Arbre d’accessibilité
Adaptation à l’écran	Utiliser les largeurs étroites/larges convenues	Aucun contrôle tronqué ; contenu utilisable	Dimensions + capture d’écran
SEO	Récupérer le HTML de la page publique	Langue, titre, canonical et politique d’indexation corrects	En-têtes + extrait HTML
Réseau	Interrompre avant/après l’envoi	Aucun faux succès ; reprise sûre sans envoi en double	Trace réseau
Données	Relire les données acceptées	Valeurs enregistrées conformes à la saisie et à la politique d’accès	Preuve de l’enregistrement sans données sensibles

Observation hypothétique : si le bouton affiche « Envoyé » alors que la requête renvoie une erreur serveur, relevez statut, horodatage et état de l’UI ; ne prétendez pas que le message a été enregistré. Inversement, une expiration du délai ne prouve pas le refus de l’écriture. Déterminez le résultat avant de réessayer.

Les outils QA Hub facilitent certaines preuves : l’analyseur d’URL explique les paramètres, le formateur JSON rend la structure lisible, le comparateur JSON confronte les données attendues et réelles, et les codes HTTP servent de référence. Ils ne décident pas si une exigence produit est satisfaite. Terminez par les échecs connus, le périmètre non testé, les responsables et une décision sur le risque de livraison.