DevTools est l’un des outils les plus utiles en QA web. Il révèle ce qui se passe réellement dans le navigateur derrière l’écran : requêtes envoyées, réponses serveur, erreurs JavaScript, cookies et stockage, raisons d’un élément non cliquable et couche recouvrant l’interface.
Beaucoup de débutants n’ouvrent DevTools qu’après une panne. C’est utile, mais le garder ouvert pendant les tests habituels est une meilleure pratique. Vous repérez plus tôt les signaux inhabituels et commencez l’analyse avec davantage de preuves que « cela semble cassé ».
Pourquoi DevTools compte en QA
Son principal intérêt est d’aider rapidement à identifier la couche responsable d’un bug.
Le même symptôme, « le formulaire ne s’enregistre pas », peut signifier des choses très différentes :
- →Le bouton est inactif à cause de l’état du DOM.
- →Un gestionnaire d’événement ne s’est pas exécuté.
- →Aucune requête n’a été envoyée.
- →La requête est partie, mais le serveur a renvoyé une erreur.
- →La réponse indique un succès, mais l’UI ne s’est pas actualisée.
- →Les données sont enregistrées, mais la page affiche un état périmé.
- →Une erreur apparaît dans la console, mais l’utilisateur ne la voit pas.
Sans DevTools, tout ressemble au même défaut. Avec DevTools, un ingénieur QA peut trouver une piste d’analyse en une minute.
Les panneaux les plus utiles en QA
Il n’est pas nécessaire de connaître tous les panneaux avec la même profondeur. Quelques-uns apportent l’essentiel au quotidien.
- →Elements : inspecter DOM, attributs, classes, éléments masqués, états désactivés, disposition et styles.
- →Network : inspecter requêtes, réponses, en-têtes, corps, temps, redirections et cache.
- →Console : repérer erreurs JavaScript, avertissements et problèmes à l’exécution.
- →Application : inspecter cookies, localStorage, sessionStorage, service workers et état applicatif du navigateur.
- →Sources : localiser les échecs dans la logique JavaScript, poser des points d’arrêt ou consulter une source map.
Cet ensemble peut déjà améliorer considérablement les tests web.
Elements : pourquoi un élément existe sans fonctionner
Le panneau Elements montre la structure réelle de la page. Il est particulièrement utile lorsque l’apparence est trompeuse.
Utilisez-le pour vérifier :
- →Si l’élément existe réellement dans le DOM ou semble seulement devoir y être
- →Si le CSS le masque
- →S’il est désactivé
- →Si une autre couche le recouvre
- →S’il est sorti de l’écran
- →Ses classes et attributs réels
- →Si le DOM change après une action utilisateur
C’est particulièrement utile pour formulaires, fenêtres modales, infobulles, menus, tableaux, sections dynamiques et états de chargement, d’erreur ou de contenu vide.
Network : relier l’UI au backend
Si vous ne devez maîtriser qu’un panneau, choisissez presque toujours Network.
Il montre :
- →La requête envoyée
- →L’URL ciblée
- →La méthode utilisée
- →Les en-têtes et le corps envoyés
- →Le statut reçu
- →Le contenu de la réponse
- →La durée de la requête
- →L’existence d’une redirection
- →Les appels dupliqués ou inutiles
- →L’influence du cache sur le résultat
Network aide vite à distinguer UI et backend. Si aucune requête n’est partie, la cause se trouve presque certainement côté frontend. Si le serveur renvoie 403 mais que l’UI affiche « erreur inconnue », le traitement de la réponse est défaillant. Si deux requêtes partent au lieu d’une, examinez les doubles envois, les nouvelles tentatives ou un rendu inutile.
Pour les ingénieurs QA, Network relie l’action utilisateur au comportement technique réel.
Console : les bugs invisibles sur la page
Console est utile lorsque l’interface se comporte étrangement sans afficher d’erreur explicite.
- →Un bouton est cliquable, mais rien ne se passe.
- →Une partie de la page n’est pas rendue à nouveau.
- →Une fenêtre modale ne s’ouvre pas.
- →Un filtre reste bloqué.
- →Un scénario fonctionne, mais un autre échoue de façon inattendue après l’étape précédente.
Une erreur JavaScript est souvent déjà présente dans Console. Cela facilite beaucoup l’analyse : plutôt que « parfois cela ne s’ouvre pas », joignez une erreur d’exécution précise et son contexte au rapport.
Distinguez les signaux utiles du bruit. Un grand projet peut produire beaucoup d’avertissements et de messages tiers. Portez attention aux nouveaux messages apparaissant exactement pendant votre scénario.
Application : l’état utilisateur dans le navigateur
Le panneau Application est particulièrement important pour les scénarios concernant :
- →Les sessions
- →L’autorisation
- →La mémorisation de connexion
- →Le stockage
- →Les fonctionnalités activées par indicateurs
- →Les service workers
- →Le cache et le fonctionnement hors ligne
Utilisez-le pour examiner :
- →Les cookies réellement définis
- →Le contenu de localStorage et sessionStorage
- →Ce qui subsiste après déconnexion
- →La persistance d’un ancien état entre sessions
- →L’influence d’un service worker sur l’application
- →L’utilisation d’un cache périmé par la page
De nombreux bugs web apparemment inexplicables viennent de l’état client. Sans ce panneau, on peut les prendre pour une instabilité aléatoire.
Bonnes habitudes DevTools en QA
- →Ouvrir Network avant le scénario.
- →Vider le journal et cibler les requêtes liées à l’action courante.
- →Comparer les scénarios réussis et échoués.
- →Inspecter la réponse et les temps, en plus du statut.
- →Consulter Console après un comportement UI inhabituel.
- →Inspecter Application pour les problèmes de connexion, d’onglets, d’actualisation et de déconnexion.
- →Utiliser Elements lorsqu’un bouton est présent mais ne fonctionne pas.
Ces habitudes simples améliorent souvent rapidement la qualité des tests.
Exemple pratique
Imaginez ce bug : l’utilisateur clique sur « Payer » et l’écran reste en chargement.
Vérifications utiles avec DevTools :
- →Dans Network, vérifier qu’une requête a réellement été envoyée.
- →Si oui, inspecter son statut, sa réponse et ses temps.
- →Dans Console, vérifier si le frontend a échoué après réception.
- →Dans Elements, vérifier si une couche de chargement bloque définitivement l’interface.
- →Dans Application, vérifier si la session est incohérente ou si des données nécessaires ont disparu.
Sans DevTools, on pourrait signaler « parfois cela bloque ». DevTools aide à distinguer délai backend expiré, erreur JavaScript, requête dupliquée, état périmé ou couche de chargement défaillante.
Points essentiels pour les ingénieurs QA
- →DevTools montre le comportement réel du navigateur, en plus du résultat visuel.
- →Les panneaux les plus utiles en QA sont Elements, Network, Console et Application.
- →La plupart des bugs web sont plus faciles à localiser en examinant DOM, requêtes, erreurs et état du navigateur avec l’écran.
- →Ouvrez DevTools pendant les tests habituels, pas seulement en cas de panne.
- →Plus vous maîtrisez DevTools, plus vous distinguez rapidement les problèmes frontend et backend et rédigez des rapports précis.
Lectures complémentaires
- →Dans cette base de connaissances : cookies, SessionStorage et LocalStorage
- →Dans cette base de connaissances : HTTP et HTTPS
- →Ressource externe : Documentation Chrome DevTools
- →Ressource externe : Présentation de Chrome DevTools
- →Ressource externe : Documentation utilisateur Firefox DevTools