Les formulaires transforment les données utilisateur en actions : inscription, commande, modification du profil ou téléversement de fichier. Les tester dépasse la saisie de combinaisons de caractères. Suivez le parcours depuis l’entrée jusqu’aux données enregistrées et à un résultat clair à l’écran.
Une bonne validation aide à corriger les erreurs et préserve l’intégrité des données. Une mauvaise validation frustre les utilisateurs tout en laissant passer des requêtes invalides : elle peut refuser un nom de famille légitime dans l’UI, mais autoriser un enregistrement via API sans consentement obligatoire.
Clarifier d’abord les règles
Documentez le contrat de chaque champ : caractère obligatoire, valeurs autorisées, plage de longueur, format, normalisation, dépendances et moment de validation. Identifiez séparément les règles métier : unicité, disponibilité d’une offre, validité des dates et restrictions de rôle.
La normalisation convertit une entrée dans une forme convenue, par exemple en supprimant les espaces aux extrémités. Ne l’inventez pas dans un test. Les espaces peuvent compter dans un nom ; changer la casse ou les caractères Unicode d’un mot de passe peut modifier le secret. Traitez les ambiguïtés comme des questions d’exigences plutôt que comme des défauts fondés sur vos préférences.
Séparer les vérifications client et serveur
La validation côté client fournit un retour rapide avant l’envoi. La validation serveur décide définitivement si l’opération est autorisée. Les attributs HTML et le JavaScript du navigateur peuvent être contournés : un refus dans l’UI ne prouve pas la protection des données du backend.
Testez la même entrée invalide via le formulaire et une requête directe dans un environnement de test. Attendez le refus serveur convenu, l’absence de nouvel enregistrement et une bonne gestion de l’erreur dans l’UI. Le contrat API définit le statut HTTP exact ; aucun statut ne convient universellement à tous les formulaires.
Choisir les données systématiquement
Utilisez les classes d’équivalence : groupes d’entrées censées se comporter de façon similaire. Pour une longueur de 2 à 50, vérifiez l’entrée vide, 1, 2, 50 et 51 caractères, plus une valeur ordinaire dans l’intervalle. La couverture des limites devient explicable.
- →Nombres : minimum, maximum, voisins, valeurs négatives, fractions et séparateur invalide.
- →Dates : dates inexistantes, jours des années bissextiles, limites de périodes, règles de langue et de fuseau horaire.
- →Texte : espaces, retours à la ligne, cyrillique, caractères Unicode composés, collage et valeurs longues.
- →Sélections : absence de sélection, valeurs indisponibles et modification des listes dépendantes après changement du champ parent.
Précisez l’unité de longueur. Caractères visibles, points de code, unités UTF-16 et octets peuvent produire des décomptes différents, notamment avec les emoji.
Tester la saisie comme une interaction
Les utilisateurs tapent, collent, remplissent automatiquement, modifient le milieu d’une chaîne et suppriment des sélections. Un masque téléphonique fonctionnant seulement caractère par caractère peut corrompre les valeurs collées. Un calendrier peut accepter une date via son widget, mais traiter différemment la saisie manuelle.
Vérifiez aussi l’envoi par bouton et par Entrée, la navigation avec Tab, la conservation des valeurs après erreur et les claviers mobiles appropriés. Les placeholders donnent des exemples mais disparaissent pendant la saisie : ils ne remplacent pas des libellés permanents.
Les erreurs doivent aider à se corriger
Les messages doivent expliquer le problème et sa correction. Associez-les au bon champ, rendez-les compréhensibles sans la couleur et laissez le temps de les lire. Plusieurs erreurs nécessitent un accès clair à chacune.
Vérifiez l’ordre du focus, les noms accessibles des champs et l’annonce des erreurs par les lecteurs d’écran. Un message global « données invalides » peut être insuffisant pour une adresse de livraison. À l’inverse, révéler l’existence d’un compte dans un message de connexion peut violer les exigences de sécurité. Le contexte compte.
Vérifications asynchrones et courses concurrentes
La disponibilité d’un identifiant, les calculs de prix et les suggestions d’adresse arrivent après les actions utilisateur. Saisissez A, remplacez-le vite par B et retardez la réponse pour A. L’ancienne réponse ne doit pas écraser le résultat courant.
Pendant l’envoi, affichez l’état convenu. Les clics répétés, Entrée et les nouvelles tentatives réseau ne doivent pas créer d’opérations métier supplémentaires. Désactiver un bouton réduit le risque, mais vérifiez la protection définitive contre les doublons au niveau de l’opération et du serveur.
Exemple pratique : inscription
Supposons que le contrat exige une adresse e-mail et un mot de passe de 12 à 64 caractères, en conservant les espaces du mot de passe. Le compte est créé lorsque le traitement serveur réussit ; perdre la réponse ne signifie pas qu’aucun enregistrement n’existe.
- 1.Saisissez des données valides et envoyez. Attendez un seul nouvel enregistrement et une prochaine étape claire, par exemple la confirmation par e-mail.
- 2.Testez des mots de passe de 11, 12, 64 et 65 caractères via l’UI et l’API. Attendez des limites cohérentes et aucun enregistrement invalide.
- 3.Utilisez une adresse e-mail existante. Attendez le refus prévu par le contrat et la conservation des autres champs valides, sauf si la politique impose d’effacer les secrets.
- 4.Simulez une expiration du délai après l’envoi, puis réessayez. Attendez un résultat défini sans second compte ni chargement infini.
- 5.Corrigez un envoi échoué avec un clavier et un lecteur d’écran. L’erreur doit être repérable et corrigeable sans souris.
Fichiers et données sensibles
Pour les formulaires de fichiers, vérifiez les tailles et types prévus, les fichiers vides, les transferts interrompus et les envois répétés. L’attribut accept guide le choix ; le serveur doit valider indépendamment le contenu et les limites.
Excluez les vrais mots de passe, jetons et documents personnels des diagnostics. Démontrez les défauts avec des données de test préparées et des requêtes sans données sensibles.
Erreurs fréquentes et enseignements
Les erreurs courantes sont de vérifier seulement les champs obligatoires, de considérer un masque comme preuve de validité et d’inspecter les messages sans vérifier les données réelles. Des formats arbitrairement restrictifs de noms ou d’e-mails sans exigence produit sont aussi risqués.
Un test systématique des formulaires relie contrats, limites, modes de saisie, décisions serveur et correction des erreurs. Évaluez tout le parcours utilisateur plutôt que le nombre de chaînes saisies.
Lectures complémentaires
- →MDN : validation des formulaires côté client
- →W3C WAI : vérifications simples, formulaires et erreurs
- →OWASP : guide de test de la sécurité web
Une règle et une matrice d’entrées concrète
Règle pédagogique : le pseudonyme doit contenir de 3 à 12 lettres ASCII. Les espaces sont refusés, pas supprimés silencieusement ; les lettres Unicode sont exclues de cet exercice volontairement limité. Le formulaire HTML fourni fonctionne uniquement côté client et n’envoie aucune requête. L’environnement API valide séparément la même règle sur le nom.
Entrée Résultat attendu
(vide) Refuser
ab Refuser : longueur 2
abc Accepter : longueur 3
abcdefghijkl Accepter : longueur 12
abcdefghijklm Refuser : longueur 13
abc Refuser : espace initial
абв Refuser : caractères non ASCII selon cette règlePour les valeurs refusées, vérifiez une erreur visible, aria-invalid=true et le focus sur le champ invalide. L’erreur est reliée au champ par aria-describedby. Pour les valeurs acceptées, exigez un statut de succès et une erreur vide. Ne généralisez pas cette règle ASCII aux vrais noms ni aux produits internationaux.
Les vérifications client améliorent le retour utilisateur, mais peuvent être contournées. Envoyez directement du JSON invalide à l’API locale et exigez son refus. Le formulaire et l’API sont deux tests distincts ; cette démonstration ne prétend pas tester un envoi de bout en bout du navigateur à l’API.