Le test d'application web (web application testing) désigne la vérification systématique des applications qui s'exécutent dans le navigateur — back-offices SaaS, systèmes e-commerce, outils en ligne — selon huit dimensions : logique fonctionnelle, validation des formulaires, compatibilité multi-navigateurs, responsive design, performance, sécurité et accessibilité. Cet article propose une checklist prête à copier, avec plus de 40 points de contrôle, pour la recette avant mise en production, la régression de versions et le smoke test des nouvelles builds.
Test d'application web ≠ test de site web
| Dimension | Test de site web | Test d'application web |
|---|---|---|
| Objet typique | Site vitrine, landing pages, blog | Systèmes SaaS, back-offices d'administration, éditeurs en ligne |
| Profondeur d'interaction | Navigation et soumission de formulaires | Sessions connectées, flux d'états complexes, droits, concurrence |
| Focus des tests | Contenu, SEO, visuel, parcours de conversion | Logique métier, exactitude des données, gestion des erreurs |
| Complexité d'état | Faible (quasi sans état) | Élevée (sessions, cache, rôles multiples) |
Si votre cible est un site vitrine, cette checklist est trop lourde : utilisez plutôt la Website QA Checklist. Cet article s'adresse aux « applications » avec authentification et logique métier.
Préparer les tests
- Définir le périmètre et la version (consigner le hash de commit ou le numéro de build)
- Préparer une matrice d'environnements : au moins 1 environnement de staging + un environnement de pré-vérification proche de la production
- Préparer une matrice de comptes : utilisateur standard / administrateur / déconnecté, au moins 1 compte chacun
- Préparer les données de test : valeurs normales + valeurs limites (chaînes très longues, caractères spéciaux, valeurs vides, fichiers volumineux)
- Choisir l'outil et la règle de consignation (modèle de bug : test case template)
La checklist de test d'application web
A. Tests fonctionnels (flux métier principaux)
- Dérouler tout le parcours inscription → vérification e-mail → connexion
- Réinitialiser un mot de passe oublié puis se connecter avec le nouveau
- Parcourir une fois le chemin nominal de chaque flux métier (commander, créer, enregistrer)
- Tester les branches d'exception de chaque flux : annulation en cours, double soumission, reprise après coupure réseau
- Vérifier l'isolation des droits : un utilisateur standard n'accède pas aux fonctions admin (en saisissant l'URL directement)
- Contrôler la cohérence des données : listes, fiches détail et compteurs se mettent à jour de façon synchrone
- S'assurer que les pages protégées sont inaccessibles après déconnexion (le bouton retour ne contourne pas l'authentification)
B. Validation des formulaires et des saisies
- Afficher un message clair et bloquer l'envoi si un champ obligatoire est vide
- Valider les formats : e-mail, téléphone, date, plages numériques
- Tester les valeurs limites : longueur maximale, valeur minimale, 0, négatifs, saisies très longues (1000+ caractères)
- Vérifier que les caractères spéciaux et les scripts (
<script>, emoji, fragments SQL) sont traités sans risque - Prévenir les doubles soumissions : un double-clic rapide ne crée qu'un seul enregistrement
- Tester l'upload de fichiers : restrictions de type, fichiers trop gros, fichiers de 0 octet, uploads interrompus
- Vérifier l'état du formulaire après les boutons précédent/suivant du navigateur
C. Compatibilité multi-navigateurs
- Chrome (dernière version)
- Firefox (dernière version)
- Safari (macOS + iOS)
- Edge (dernière version)
- Surveiller les points de divergence : sélecteurs de date, téléchargements, comportement du scroll, mise en page CSS
D. Responsive et mobile
- Passer en revue les breakpoints : largeurs 1920 / 1366 / 768 / 375
- Utiliser navigation, fenêtres modales et tableaux sur mobile (sans débordement horizontal)
- Garantir des cibles tactiles assez grandes et des alternatives au survol (hover) sur écran tactile
- Basculer entre mode portrait et paysage (si applicable)
- Vérifier que les champs restent visibles quand le clavier virtuel s'ouvre
E. API et gestion des erreurs
- Ouvrir les panneaux Console et Network des DevTools, dérouler les flux principaux : aucune erreur en rouge
- Afficher un message compréhensible (pas d'écran blanc ni de blocage) quand un appel échoue (hors ligne/500)
- Afficher un état de chargement sur les appels lents ; débouncer ou annuler les requêtes en double
- Guider clairement l'utilisateur à l'expiration de la session (rediriger vers la connexion plutôt qu'un échec silencieux)
- Garder une console sans exception non capturée (Uncaught Error)
F. Performance
- Atteindre les objectifs de chargement initial (recommandé < 3s, LCP < 2.5s)
- Éviter les ralentissements sur les grandes listes / gros volumes (tester avec des données réalistes)
- Compresser les images et activer le lazy loading
- Traquer les fuites mémoire (ralentissement net après un usage prolongé)
G. Bases de la sécurité
- Rendre les ressources protégées inaccessibles par URL ou API sans session ni droits suffisants
- Transporter les données sensibles en HTTPS sur tout le site
- Ne jamais réafficher les mots de passe en clair
- Garder les tokens sensibles hors des URL (ou les masquer et les faire expirer)
- Ne pas exposer de stack trace ni de détails techniques à l'utilisateur final dans les messages d'erreur
H. Accessibilité et détails
- Réaliser les actions clés au clavier seul (ordre de tabulation, Entrée pour valider)
- Ajouter un texte alt aux images et associer un label aux champs de formulaire
- Maintenir un contraste au moins conforme à WCAG AA (4.5:1)
- Concevoir les états vide, chargement et erreur (jamais un écran blanc)
Consigner et suivre les résultats de test
| Pratique | Ce que ça signifie |
|---|---|
| Joindre une preuve à chaque défaut | Annoter une capture pour marquer le point de reproduction ; filmer les problèmes d'interaction |
| Capturer le contexte technique automatiquement | Laisser un outil relever les erreurs Console/Network (ex. BugCapturer) au lieu de les recopier à la main |
| Archiver de façon structurée | Exporter la liste des défauts en Excel (n°/module/étapes/attendu/observé/gravité/statut) |
| Rendre les résultats partageables | Générer un lien de partage plutôt que d'envoyer des fichiers quand d'autres équipes doivent valider |
La fonction diagnostic de BugCapturer résout d'un coup les trois points du milieu : pendant la capture d'écran ou l'enregistrement vidéo, elle relève automatiquement les erreurs Console et Network, exporte un Excel de 12 colonnes en un clic et génère des liens de partage sans installation pour les développeurs ou les clients. Détails sur la page de la fonction diagnostic ; la structure complète du rapport est décrite dans How to Export Bug Reports to Excel.
Pour la validation finale avant mise en production, organisez une recette utilisateur en suivant le UAT Complete Guide, avec cette checklist comme support d'exécution.
FAQ
Combien de temps prend le test d'une application web ?
Cela dépend du périmètre : 0,5–1 jour pour le smoke test d'une nouvelle version, 2–5 jours pour une régression complète ; un gros release prévoit généralement 1 à 2 semaines (vérification des correctifs comprise). Parcourir les 8 groupes de cette checklist demande environ 1 à 2 jours-homme.
Comment répartir tests manuels et automatisés ?
Règle empirique : couvrez d'abord A/B/C/D manuellement (surtout pour une première mise en production), puis automatisez les chemins de régression fréquents (connexion, flux principaux) une fois stabilisés. Le groupe E (vérification Console/Network) peut être outillé ; la sécurité (G) gagne à être complétée par des scanners spécialisés et des revues de code.
Quel lien entre cette checklist et un plan de test ?
La checklist répond à « quoi tester » ; le Test Plan Template répond à « qui teste, dans quel environnement, quand et selon quels critères de passage ». Définissez d'abord le plan, puis exécutez la checklist : les deux documents vont ensemble.
Comment utiliser cette checklist sans équipe QA ?
Répartissez : les développeurs auto-testent A/B/E (le technique), le product owner recette A/D (métier et expérience), et avant la release, tout le monde fait un bug bash de 2 heures (méthode dans le Bug Bash Guide). Consignez avec un modèle incluant captures et infos de diagnostic pour réduire les allers-retours.
Conclusion
L'essentiel du test d'application web n'est pas « tester très fort », mais couvrir toutes les dimensions et rendre chaque résultat traçable : avancez sur les huit dimensions — fonctionnel, formulaires, compatibilité, responsive, erreurs, performance, sécurité, accessibilité — et archivez chaque constat sous la forme « capture annotée + diagnostic Console/Network + entrée structurée ». Copiez cette checklist telle quelle dans votre plan de test comme support d'exécution.
Pour aller plus loin : Website QA Checklist · Test Plan Template · UAT Complete Guide